Category: Programming

Nowadays, makefiles are ubiquitous in software. Most C and C++ projects have used them historically, and still use them as a build system. Nowadays, lots of projects written in other languages which have their own build tools also use them, not to make files, but to store and run commands in an organized manner. If this is you, you are doing it wrong. However, there is a tool designed to do just that: just.

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.

Edit (2023-04-05): Added some suggestions by the author/developer of libvips.

Today I discovered libvips, a command line utility and library to manipulate and process images, and I am impressed. I’ve been using ImageMagick and its fork, GraphicsMagick, for as long as I have had to process images from the CLI, and they work well for moderately-sized images. But lately, I have been preparing virtual texture datasets for Gaia Sky and the sizes of my images have increased exponentially. Right now I’m processing 64K and 128K images on the regular (that is 131072x65536 pixels), and ImageMagick just can’t do it reliably. It uses so much memory that it can’t even split a 64K image in a 32 GB RAM machine without running out of it. Running it with the suggested options to limit memory usage (--limit memory xx mb, etc.) and use a disk cache never works for me. It just produces blank images for some reason. So after implementing a couple of Python scripts based on OpenCV and NumPy to do some basic cropping, I took on the task of finding a proper, capable replacement. And found it I did. Libvips is the perfect tool, it seems. Based on my few first tests, it performs much better than ImageMagick and GraphicsMagick. It is super fast and never seems to use much memory, no matter how big an image I throw at it.

From time to time I profile Gaia Sky to find CPU hot-spots that are hopefully easy to iron out. To do so, I launch my profiler of choice and look at the CPU times for the top offender methods. Today I went through such a process and was surprised to find a forEach() method of the Java streams API among the worst offenders. Was the forEach() slowing things down or was it simply that what’s inside the loop took too long to process? I found conflicting and inconsistent reports in the interwebs, so I set on a quest to provide my own answers.

Edit (2024-07-08): We have written a new post to expand on this one. Check it out here.

Edit (2024-06-26): As of Gaia Sky 3.6.3, the procedural generation process has been moved to the GPU. Even though the base method is the same, a number of things have changed from what is described here. For instance:

• The generation is now almost instantaneous, even with high resolutions.
• Gradval and Value noise are no longer available.
• Voronoi and Curl noise are now available.
• The process takes into account a temperature layer.
• We have introduced terraces, with the respective parametrization.

I have recently implemented a procedural generation system for planetary surfaces into Gaia Sky. In this post, I ponder about different methods and techniques for procedurally generating planets that look just right and explain the process behind it in somewhat detail. This is a rather technical post, so be warned. As a teaser, the following image shows a planet generated using the processes described in this article.

Do you often find yourself using “New feature”, “More” or similar short, useless and generic strings as your git commit messages? I know I did. Until I learned about semantic commit messages, that is. What are they and how can they exponentially improve your commit history and make it actually useful? I’m discussing it in this post.