smcameron/gaseous-giganticus

This program procedurally generates gas giant cubemap textures for the game Space Nerds In Space. https://www.patreon.com/smcameron

Gaseous Giganticus

This program is used to create procedurally generated gas giant planet cubemap textures for the game Space Nerds In Space. Of course it can be used to create assets for other games, e.g. Kerbal Space Program.

Sample Output

The output of gaseous-giganticus consists of six square images that can be used as a cubemap to texture a sphere. Here the output is viewed with "mesh_viewer", from the space-nerds-in-space repository.

Getting Started

1. clone the project
2. Type "make"
3. run "./gaseous-giganticus --help" and do what it says.
4. See also: output of "nroff -man < gaseous-giganticus.1 | more"

The program requires one PNG input image, which should ideally be about 200 pixels wide and about 1200 pixels tall, and blurred. It outputs 6 square images that can be thought of as the faces of a cube, which you can imagine being overinflated until it is a sphere. The layout of those six output images is as follows:

        +------+
        |  4   |
        |      |
        +------+------+------+------+
        |  0   |  1   |  2   |  3   |
        |      |      |      |      |
        +------+------+------+------+
        |  5   |
        |      |
        +------+

If you wish to watch the progress of the program while it works, you'll need to compile and run "mesh_viewer", which is part of Space Nerds In Space.

Here is a video demoing the gaseous-giganticus and mesh_viewer. This video is a bit old, and I should probably make a new one, but it will have to suffice for now.

Prerequisites

1. libpng

Coding style

1. Run "git diff | ./checkpatch.pl -". It will tell you what you did wrong.

TLDR: Tabs, not spaces, snake_case, not CamelCase.

Contributing

To gain an understanding of how the program works, see this slideshow. Use arrow keys to navigate. That slideshow does not work well on mobile, so find a real computer.

If you're looking for a challenge, it would be really cool to do a more proper fluid simulation. This could probably be done by advecting the velocity field and then eliminating divergence from it, something like what is described here, except done on the surface of a sphere instead of on a plane. The velocity field is contained in the vf structure. Some framework code is already in place, we "just" need to implement the body of the functions advect_velocity_field() and remove_divergences().

Please read CONTRIBUTING.md

Authors

• Stephen M. Cameron
• Tobias Simon (initial author of quaternion library)
• Jeremy Van Grinsven (many additions to quaternion library)

License

GNU GPL v. 2

Notes

On Sunday, October 21, 2018, this code was split off from the Space Nerds In Space repository at https://github.com/smcameron/space-nerds-in-space where the code was originally developed.

An effort was made to preserve the history (git log, etc), and this effort was 99.9% successful, but there are a few small differences from the original history. Most significantly, the Makefile does not exist for most of the history in this repository because the Makefile used in Space Nerds In Space would have been broken anyway and would have contained tons of irrelevant cruft. The Makefile in this repository was added only after the entire gaseous-giganticus history was imported. Less significantly, a few commits were made out-of-order, and although the original dates were preserved in the log, checking out a particular sha you may find some small differences if you compare with what was in the Space Nerds In Space repository at a corresponding time. At the time the Makefile was added to this repository, all source files present here were identical to those also present in the Space Nerds In Space repository, meaning those small differences were resolved eventually.

gaseous-giganticus's Issues

Fails to produce sensible images with very large dimensions

Setting DIM to 4096 and VFDIM to 8192 yields strange results.

The first output image looks like this:

Some other images are completely transparent, and some are similarly messed up.

--output does not respect the user provided output_file_prefix

save_output_images() prepends a period character into the PNG path making output options such as "-o /tmp/out-" impossible to use. Here's a patch:

diff --git a/gaseous-giganticus.c b/gaseous-giganticus.c
index 87aa80c..1c659fc 100644
--- a/gaseous-giganticus.c
+++ b/gaseous-giganticus.c
@@ -1232,5 +1232,5 @@ static void save_output_images(char *output_file_prefix, int sequence_number, un
                if (sequence_number < 0)
-                       sprintf(filename[i], ".%s%d.png", output_file_prefix, i);
+                       sprintf(filename[i], "%s%d.png", output_file_prefix, i);
                else
-                       sprintf(filename[i], ".%s%04d-%d.png", output_file_prefix, i, sequence_number);
+                       sprintf(filename[i], "%s%04d-%d.png", output_file_prefix, i, sequence_number);
                if (png_utils_write_png_image(filename[i], image[i], DIM, DIM, has_alpha, 0)) {

Possibility to vary band sizes

There is the band count, but could it be possible to have some larger and some smaller bands, to set a random factor to how much they can vary in size?

(Awesome program btw., I am having to much fun with it :)

Would be nice if this did real fluid dynamics

In order to do so we need to fill in the advect_velocity_field() and remove_divergences() functions which currently do nothing. There are comments in the code describing roughly what they should do. And it's possible that what they describe isn't correct or won't work for whatever reason.

I'll need help for this one as it is beyond me. Might never get done.

Windows patches

Here a couple of patches to get gaseous-giganticus to run on Windows (built using MSYS2).
https://gist.github.com/logzero/9655eb67e39b036aad4a95f2b672c442

Crash if no --dump-flowmap is not used.

If --dump-flowmap is not used, the program crashes. The program runs fine if I use the --dump-flowmap option. I believe the error is at gaseous-giganticus.c: 1915. If I'm reading it correctly, the program tries to save a flowmap even when there is no flowmap image to save.

Possible to export images in spherical format

Is it possible for the program to export in a spherical format rather than a cube map format?

Color mixing is done with floats, and is a bottleneck

Color blending is done by converting bytes to floats, mixing, then converting floats back to bytes. Additionally, color blending is a bottleneck in the program.

I have a strong suspicion this could all be speeded up a little bit by using fixed point arithmetic to do the blending, perhaps something like this: https://www.reddit.com/r/GraphicsProgramming/comments/qczmbi/can_someone_walk_me_through_why_this_blender_works/

uint32 blend(uint32 color1, uint32 color2, uint8 alpha) {
    uint32 rb = color1 & 0xff00ff;
    uint32 g  = color1 & 0x00ff00;
    rb += ((color2 & 0xff00ff) - rb) * alpha >> 8;
    g  += ((color2 & 0x00ff00) -  g) * alpha >> 8;
    return (rb & 0xff00ff) | (g & 0xff00);
}

I have not tried the above code, but I have tried this, below:

static struct color combine_color(struct color *oc, struct color *c)
{
        unsigned int alpha = oc->a + 1;
        unsigned int inv_alpha = 256 - alpha;

        struct color nc;

        nc.a = (c->a + oc->a * (256 - c->a)) >> 8;
        nc.r = (unsigned char) (alpha * oc->r + inv_alpha * c->r) >> 8;
        nc.g = (unsigned char) (alpha * oc->g + inv_alpha * c->g) >> 8;
        nc.b = (unsigned char) (alpha * oc->b + inv_alpha * c->b) >> 8;
        return nc;
}

but so far have not got anything working. In theory, using fixed point math for the color mixing rather than floating point should be an easy win.

[Enhancement] Output velocity field as a flow map

In some shaders, a flow map can be used to animate a texture. These are commonly used for liquids and, more importantly, gas giants.

From my understanding, the velocity field dictates the direction in which a particle will be moved in. It would be useful if the velocity field could be output as a texture along with the texture that is normally saved. This would allow for a shader that can utilize a flowmap to shine with this program.

A flowmap without movement defaults to grey (0.5, 0.5, 0.5). Movement in the X direction is indicated by a change in red pixel intensity. Movement in the Y direction is indicated by a change in green pixel intensity. The blue channel is unused.

I feel as if this would be a useful addition to the program.

Enchanced output methods

I am not sure what it would entail or it's possible, but it would be cool to get dynamic range TIF output to use in other programs to modulate the files further without colour burning/banding.