Tag: Gaia Sky

A couple of years ago I wrote about the procedurally generated planets in Gaia Sky. In this post, I provided a more or less detailed technical overview of the process used to procedurally generate planetary surfaces and cloud layers.

Since then, we have used the system to spice up the planets in the planetary systems for which the Gaia satellite could determine reasonable orbits (see the data here, and some Gaia Sky datasets for some of those systems here, including HD81040, Gl876, and more).

However, with the upcoming Gaia DR4, the number of candidate exoplanets is expected to increase significantly, rendering the “one dataset per system” approach unmaintainable. In this post I describe some of the improvements made with regards to exoplanets in Gaia Sky, in both the handling of large numbers of extrasolar systems seamlessly, and in the brand new, improved procedural generation of planetary surfaces and clouds.

Gaia Sky has been using the OpenVR API from SteamVR for the last few years to power its Virtual Reality mode. However, the API is notoriously poorly documented, and it only works with the SteamVR runtime.¹ That leaves out most of the existing VR headsets. Luckily, the main vendors and the community at large joined efforts to come up with an API that would be adopted by all and backed by the Khronos Group: OpenXR. Obviously, since Gaia Sky is actively maintained, it is only natural that a migration to the newer and widely supported API would happen sooner or later. But such a migration is not for free. Both APIs are wildly different, with OpenXR being much more verbose and explicit. In this post, I document the migration process and also offer a bird’s eye view of the layout, structure and components of an OpenXR application for Virtual Reality.

Implementing proper virtual texture support in Gaia Sky has been on my to-do list for many years. And for many years I have feared that very item, as the virtual texture mechanism is notoriously complex and hard to implement. However, once working, they are very cool and bring a lot of value to software like Gaia Sky. In this post, I describe and discuss my implementation of virtual textures in Gaia Sky in detail, and provide a thorough examination of some of its most interesting points. If you are looking for the specifics of how to define or use virtual texture datasets in Gaia Sky, please refer to the official documentation. Here I provide only a general technical description.

In this post, I’m mirroring the Gaia Sky 3 tutorial I wrote for the official Gaia Sky documentation to use as a rough script for the workshop given in a splinter session of the 2021 DPAC consortium online meeting held on March 17 and 18, 2021. You can find the original page here.

It’s been a while since I last talked about new Gaia Sky releases. Today I’m doing a recap of the last four releases, starting with 3.0.0. This very verison came out with Gaia eDR3 on Dec 3, 2020. It was a big jump for Gaia Sky, as it introduced a plethora of new features and QOL improvements along with lots of bug fixes and little tweaks. This post goes over the latest versions from 3.0.0 to 3.0.3, and reflects on what they brought to the table.

Jump to the analysis for each of the versions directly:

• 3.0.0
• 3.0.1
• 3.0.2
• 3.0.3

A while ago Erwan Leroy, a VFX professional and trainer, contacted me with some questions regarding the catalogs in Gaia Sky. Basically, he was trying to decode the binary format used in Gaia Sky to load the stars using a Python script. Of course, my documentation was lacking in that very aspect, so I walked him through the format and then improved the docs.

Today, he has come back to me to share his results. Turns out he was trying to replicate an astrophoto with rotation star trails using his visual effects skills. And he came pretty damn close, I might add. I read the article and liked it, so I am sharing it here: Rendering a plausible night sky.