[Enhancement] Output velocity field as a flow map

[Gameslinx]

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.

[smcameron]

Good idea!

[smcameron]

Hmm, so the velocity field is actually a 3D field of vectors that are constrained to be tangent to the surface of a sphere. I suppose I could transform to tangent space, similar to how normal maps work?

[Gameslinx]

That should hopefully work - A flow map only needs an X and a Y direction so transforming to tangent space would allow for this.
This is a flow map which indicates a vortex around the centre of the image:

There are no examples of a gas giant flow map that I could find, but the output should look similar to that above

[smcameron]

Thanks for the example image, had done some google image searches for flow maps, but wasn't sure what I was looking at. Now just have to remember/relearn about tangent space, ha. (May take a little while.)

[smcameron]

Looky what I made:

I can't believe that worked the first time. Zero debugging. Which probably means that it didn't actually work and there's something wrong with it, but I don't really know how to tell if it's right. It looks plausible that it's right (except for the lack of any need to debug anything.)

I'll commit this, and you can see if you can do anything with it, or if the field is all wrong in some way.

[smcameron]

Committed as:

• f5c1299 Allow exporting velocity field as flow-field png files

To use it, just add command line flag "--dump-flow-field filename-prefix"

It will dump out six png files named "filename-prefix-X.png" where X is 0 thru 5.

Let me know if it works for you, and if you do something cool with it, I wouldn't mind seeing it.

[smcameron]

Hmm, the way those bands shift from red to green on opposite sides of the sphere make me think maybe something's subtly wrong. There are counter rotating bands, which makes me think that it should look more like alternating red and green bands, not alternating half-red, half-green bands. But... not really sure.

[smcameron]

Added another commit to at least warn that the flow field is not calculated correctly, and comments indicating why I think it's wrong.

• 177a738

I think calculating the flow field is a bit of a hard problem (at least it is for me.)

I knew that quick first seeming success was way too easy.

[Gameslinx]

I generated a gas giant and previewed it with the flow map shader and the current results aren't amazing. I may have a solution, though. Here's what the result looked like:
https://www.youtube.com/watch?v=dEv7s45-c0I

My solution may be simpler:

1. Get position of the current particle (I believe this is stored in the Pos variable)
2. Get position of the particle after it has moved (Pos_1)
3. Directional 2D vector "Vec" = ((Pos_1.x - Pos.x), (Pos_1.y - Pos.y))
4. Normalize this by dividing Vec.x and Vec.y by the magnitude of the vector (sqrt(Vec.x^2 + Vec.y^2)) to get the X and Y values between -1 and 1
5. Red colour (X direction) is (127 + (127 * X)): range from 0 to 255
6. Green colour (Y direction) is (127 + (127 * y)): range from 0 to 255

This should produce a map that lines up correctly with the Gaseous Giganticus output. Hopefully, it is also easier to calculate and does not require a transformation into tangent space if you calculate the vectors from pixel coordinates

[smcameron]

Thanks. That might work. Can't get to it today. Hopefully within a week or so I can give it a try though.

[smcameron]

Ok, I made another attempt... but it doesn't seem to be working. Not sure why not.

If you want to try it, apply the following patches.

• 1-revert-erroneous-flowmap-calculation.txt
• 2-clean-up-memory-allocations.txt
• 3-make-another-attempt-at-flowmap-calculation.txt

I don't think your step 4 above is correct (normalizing the 2d velocity vectors). You want the flowmap to contain velocities that are not 1.0, and zero velocity areas (centers of vortices) would end up with NaNs.) You do want to scale the velocities. What I tried was finding the max velocity, and dividing by that. However, there were some very large velocities that ended up scaling almost everything to zero. So I tried ignoring large velocities to get a reasonable scaling factor... still the output doesn't look right at all. So... something's screwy, but I don't know what.

[smcameron]

I think many of the high velocities are coming from particles that traverse from one face of the cubemap to another. Such particles should be handled specially (e.g. ignored is the easiest special handling. I don't know what "correct" special handling would be.) There are other problems besides that though.

[Gameslinx]

I don't think your step 4 above is correct (normalizing the 2d velocity vectors). You want the flowmap to contain velocities that are not 1.0, and zero velocity areas (centers of vortices) would end up with NaNs.)

Normalizing the vectors is necessary, as a vector (1,0) indicates movement only in the X axis which will correlate to RGB(255, 127, 0). The vector (1, -1) would be RGB(255, -255, 0) which is a movement in the positive X and negative Y direction. If a pixel moves (4, 6) and this value is not normalized, the RGB value would be out of bounds.

In the shader, the map is multiplied by a scalar to get the maximum displacement from the flow map. Normalizing the vector is required for this, and it could be why the map doesn't look right.

I'll need to try this, as I have not yet. Will update the issue once I get it working

Edit: Getting "segmentation fault" error when running the command ./gaseous-giganticus --input input/input01.png --dump-flowmap filename-prefix

[smcameron]

Normalizing the vectors is necessary,

I don't agree with this. This would mean every vector has a magnitude of exactly 1.0.

I do agree the vectors need to be scaled. But not normalized.

There are going to be parts of the vector field where things are slow (i.e. magnitude much less than 1.0.) My idea is scan through all the vectors, find the biggest one, and compute a global scale factor such that that biggest vector gets scaled to magnitude 1.0. (First problem with this is vectors spanning edges got huge velocities, causing everything else to get scaled to effectively 0. But solved that for the time being by ignoring such big vectors. Still other problems remain.)