Map orientation

[WASasquatch]

I'm confused. went to do a new set of maps, and for some reason, they are ordered and named differently, and I don't have rotated maps corresponding with the cube map pattern. I'm using the same commands I've been using the whole time, even just using the up arrow and changing sample image numbers and paramter settings only.

The images now render as follows:

But was previously outputting like this:

Here is an example of the commands used:

../gaseous-giganticus --noise-scale 2 --velocity-factor 4500 --pole-attenuation 0.8 --bands 16 --vertical-bands 2 --faderate 0.0125 --fbm-falloff 0.3 --input ../Input/Sample12.png --output 4/gas1_

and for the iteration renders

../gaseous-giganticus -e 3 --noise-scale 7 --velocity-factor 2250 --pole-attenuation 0.8 --bands 24 --vertical-bands 2 --faderate 0.0125 --fbm-falloff 0.3 -k 4/gas1_ --output 4/gas2_

[smcameron]

Did you always use the "--vertical-bands" option? I suspect in the first instance, you didn't, and the 2nd you did.

There is a script, here: https://github.com/smcameron/space-nerds-in-space/blob/master/util/turn-cubemap-about-axis

which can use ImageMagick (aka "convert") to rotate the cubemap images about the x, y, or z axis, though it can be surprisingly tricky to figure out what rotation you need to get the thing the way you want it.

There some textures in here: https://github.com/smcameron/space-nerds-in-space/tree/master/share/snis/textures called test0.png through test5.png which you can use to practice rotations to see what will happen. They are specially designed to allow you to easily see which cubemap face is which and which way they are oriented. It can be pretty hard to tell the gas giant textures apart from one another.

[WASasquatch]

Oh, that changes the orientation of the maps? I figured it was just a simulation function.

On Thu, Dec 9, 2021 at 8:22 PM smcameron @.***> wrote:

Did you always use the "--vertical-bands" option? I suspect in the first instance, you didn't, and the 2nd you did, or vice versa.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/smcameron/space-nerds-in-space/issues/317#issuecomment-990605975, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIZEZJZPH4DZ33QQXGPGE3UQF6AFANCNFSM5JYCG5OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Sincerely, Jordan S. C. Thompson

[WASasquatch]

Is there any documentation on what numeric values do to the map orientations in output?

Also, if I haven't said it already, thanks a lot for all the help on Reddit, and here on Github. I'm having a lot of fun with your software, just trying to get the hang of it. It's funy how I always wished for something like this and turns out it existed, just for Linux (which I do like over Windows, but I haven't been using it for years as a main OS).

I also wanted to make one off-topic note: the log output when using wstep is really messed up. Maybe after the initial velocity field computation log entry, it doesn't spit that out anymore, and instead just adds the time to the render log, and maybe adds an "x" where it did a new velocity field (similar to the "o" used currently).

[smcameron]

Is there any documentation on what numeric values do to the map orientations in output?

Uh, not sure what you're asking. I think the only option that affects how the images are laid out is the --vertical-bands one.

There's a man page... if you "make install", you should be able to see it by typing "man gaseous-giganticus", or if you don't want to "make install", you can do "nroff -man < gaseous-giganticus.1 | more". Not that it has much more information than the output of "./gaseous-giganticus --help"

You've got to realize, this program started out as pure experimentation. When I began working on it, I had the idea that it might work, but I really didn't know if it would actually produce anything useful or not. It took about a month of solid work from when I started to when I got something reasonably useful out of it, and luckily it worked way better than I thought it would. A lot of the options are just kind of experiments, trying things, or refinements to attempt to address perceived problems. It's not like I had a grand vision to do A, B, and C, and executed, more like I had a vague idea, and tried a bunch of experiments, and some worked great, and others maybe not so much.

I haven't used the wstep option much, because it causes the velocity field to be recalculated, which takes forever, and I'm not sure that it really produces better results. Feel free to send me a patch to improve the output if it's bugging you though, and if you do get unusually good results using wstep, I'd be happy to know more about that.

Another cool trick you might like to try is to run the program multiple times, using the --cubemap option to make it use it's own output as input. That is, run it as normal for awhile to produce the 6 cubemap images, but then run it a 2nd time, but with different parameters, using the --cubemap option to make it kind of take up where it left off and use the output of the first run as a starting point.

You can get stuff like this, which is a bit different than the usual output:

[WASasquatch]

I have been messing around with the cube map, I like it a lot, except I can't get these results you show. When I do the final stage, to get back some larger shapes, it seems to just muddle out all the low-scape detail altogether. I thought maybe it was just because I needed to stop it earlier (because I wasn't monitoring with mesh_viewer I'm still having issues with), so I stopped it only after the first phase of image saving, and it just smears all the detail way. Which is odd cause I even matched your settings exactly from your experimentation page. So I almost feel like computation on WSL is almost a bit different.

As for the wstep parameter, I think the effect is interesting. It seems features are "incomplete" and more just smears like flows coming off of larger shapes with far less completed curly swhirls. Here is an example of one of the maps currently in progress... for the last 4 hours.

(These are with --wstep 2 )

[smcameron]

You might try making smaller images (1024x1024) instead of (8192x8192), it will go a lot faster. Then when you get the parameters sorted out making something you like, try it bigger.

The first one above looks really nice. The 2nd one has some weird little wavy artifacts. Oh, I notice now that the 2nd one is just an enlargement of a portion of the 1st one. How many particles are you using? Default is 8M, I think. at 8192x8192, I would think you might not get full coverage with 8M particles, as each image would contain 67108864 pixels and there are 6 of them, so 8M particles would be spread pretty thin, covering only about 2% of the area. It must take forever.

I don't exactly remember how I got the image I posted above. I think it was something like the first run was pretty normal, something like:

   ./gaseous-giganticus --noise-scale 2.5 --velocity-factor 1300 --bands 10\
        -i input_image.png -o output_image

Then the 2nd run, I think I used --band-speed-power 3 (or some other small odd integer > 1), and a used a higher noise-scale value to get finer details. Or maybe I did it in the opposite order. But the gist of it was somewhere I used --band-speed-power to make the swirly bands fat and the zones in between the swirly bands narrow, and different noise-scales to get different sizes of swirlyness in the 2 runs.

In case you haven't seen it already, I made a guide for choosing the noise scale here: https://smcameron.github.io/space-nerds-in-space/gaseous-giganticus-noise-scale.html

[smcameron]

I improved the status output when using wstep option:

• Improve status output when using wstep option. commit: c5b8dd82add24f1cb26bb685d5a30977d3d26fe9

[WASasquatch]

Yeah, I noticed a lot of the smearing (wave artefacts over other waves). I figured it was just the bands not aligning right (though they're using all the same bands) so it must be the noise scale.

I am doing a different test, starting with tiny shapes, and then stepping up. One thing I have been noticing is when using --cubemap or -k, it tends to make the image much darker than it's reference. Take these screenshots as an example of the first two iterations. I don't think it can be helped, so I probably just need to edit them in post.

Thanks for pushing the update for the console through. It definitely didn't hurt anything, but certainly effected my OCD. Lol I tried looking over the code but I don't feel confidence enough in C. I come from PHP, and then learned JavaScript, etc, and only know other languages because of those, which are not good references. I should have took programming in school instead of web design. Especially with how saturated the fields are now. M

[WASasquatch]

Oh PS, I did catch your note about resolution and particle numbers on your experimentation post, so I edited the program before compile and changed the default 8m to 16m. Perhaps still not enough. With these end sizes it probably needs even double that, so 32m.

PPS; I am using Topaz Gigapixel to upscale the equirectangular maps to over 32k in resolution, which also applies AI interpretation which gets rid of a lot of particle artefacts, but not all. I am hoping these huge maps I can get seriously large poster quality shots of some gas giants.

[smcameron]

The darkening is because of the fadeout probably. You might try --no-fade option. But it might make other differences. When you try 8192x8192 are you just changing DIM? or also VFDIM? I've been going by the rule that VFDIM should be 2x DIM, but I don't quite remember why, and it might not be true. I've never tried 8192x8192, I don't have patience for that.

[WASasquatch]

Yeah, that's what I am doing. Right now I am outputting 4k with 8k VFDIM.

I'll try no fade; but I am also realizing that if it's using a rasterized un-altered cubemap it's also interpreting the space betwen particles as part of the particle field, so producing darker particles sampled from between particle lanes. Which of course than get faded, and pushed about and lose intensity during simulation too as things mix about. So I think that's further adding to the darkness.

[smcameron]

For the same ratio of coverage of 8M particles against six 2048x2048 textures, scaling up to 4096x4096 would need about 32M particles.

[WASasquatch]

So I am still having map orientation issues. I dropped the vertical bands, to do the same settings as before that I was able to map them to equirectangular with Hugin, but now that maps are out of sync for the project file I got from here: http://www.cs.umd.edu/hcil/ARDN/HuginAdjusts/

It worked fine before, but now when I line up the images in Photoshop, my up and down are aligning to the back, not the face. So basically now in Hugin the maps don't align in equirectangular. I am sure there is a way to rotate maps but this program seems so complicated, and when I alter images they just blank out black in the panoramic preview.

Here is an example of two runs, with the same command structure minus velocity speed. The new runs the top and bottom don't align with the front face, but with the back face suddenly.

../gaseous-giganticus --noise-scale 1.5 --velocity-factor 8000 --pole-attenuation 0.8 --band
s 12 --count 500 --particles 64000000 --input ../Input/Sample14.png -o 8/gas1_

Not right:

../gaseous-giganticus --noise-scale 1.5 --velocity-factor 1500 --pole-attenuation 0.8 --band
s 12 --input ../Input/Sample8png -o 2/gas1_

Right:

The only difference I see is the particles and reducing iterations to 500.

[WASasquatch]

PS I notice too that my map orientations never actually match the example cubemap style too on the github, they are always left first at 0, minus the attempts with vertical bands.

[smcameron]

Are you SURE? This make NO sense to me. The simplest theory to explain this is that you are mistaken somehow. I don't have another theory at the moment. (of course it's possible you've found some really weird bug... but, I'm having trouble imagining how such a bug could even work.)

[smcameron]

Can you reproduce with smaller dimensions and fewer particles? (Sorry, I'm not doing 8192x8192x6 x 64M particles, time is worth more than that.)

[smcameron]

BTW, out of curiousity, why are you making such big textures anyway? What are you going to do with them? Decoded in memory as RGB, they will occupy 1.2Gb of video memory (and that's ignoring mipmapping).

[smcameron]

PS I notice too that my map orientations never actually match the example cubemap style too on the github, they are always left first at 0, minus the attempts with vertical bands.

Possible. Looked into this, here's what I find.

In mesh_viewer.c, there's this:

        return graph_dev_load_cubemap_texture(is_inside, linear_colorspace,
                        maybe_replace_asset(filename[1]),
                        maybe_replace_asset(filename[3]),
                        maybe_replace_asset(filename[4]),
                        maybe_replace_asset(filename[5]),
                        maybe_replace_asset(filename[0]),
                        maybe_replace_asset(filename[2]));

Notice the weird order, 1, 3, 4, 5, 0, 2 -- those correspond to the images gaseous-giganticus produces.

In graph_dev_opengl.c, there's this:

        static const GLint tex_pos[] = {
                GL_TEXTURE_CUBE_MAP_POSITIVE_X, GL_TEXTURE_CUBE_MAP_NEGATIVE_X,
                GL_TEXTURE_CUBE_MAP_POSITIVE_Y, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y,
                GL_TEXTURE_CUBE_MAP_POSITIVE_Z, GL_TEXTURE_CUBE_MAP_NEGATIVE_Z };

So, images 1, 3, 4, 5, 0, 2 correspond to +x, -x, +y, -y, +z, and -z, respectively.

The coordinate system is like so:

       +Y
       ^
       |
       |
       |
       |
       |
       |____________> +X
      /
     /
    /
   /
  +Z

And with that mapping of 1, 3, 4, 5, 0, 2 to +x, -x, +y, -y, +z, -z and that coordinate system, we get a cube like this:

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

And that can be unfolded to match this:

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

So I think the github page is right. Note that there are other ways to unfold that cube too though.

[WASasquatch]

EDIT: This is to your last post, I just got your most recent post.

I'm not previewing it so it's not using any video memory. It uses RAM and CPU. So I have plenty to spare there. But I use them in Terragen which is a 3D environmental rendering software. I render planets in it at real-world scales. Anything under 8k viewed up close will look seriously bad. For cinematic shots like venturing to a planet and setting up a close orbit, I need seriously big maps. For my HD mars, the maps are in 44k and 32k. Even that really isn't enough detail (straight from NASA) to get me the detail I need so from there I use fractal warping and stuff to bring in fictional detail. Terragen simulates a very accurate realistic atmosphere system down to clouds.

I am not sure what I am doing wrong. I can't align the maps like I did before in photoshop. Not even flipping them vertically. They only align at the end with the bottom texture.

I'll do some more tests. It has me just as confused as you are. I see no reason why the program would be spitting out different orientation maps.

At the same time it would be cool if you could explicitly name each face map. Something maybe like

--back back.png --front front.png --left left.png --right right.png --bottom bottom.png --top top.png

and just define a output dir. That way there is no confusion to what map is what. Though I realize this is just an experimentation for your interesting game, and quite old. Still truly thankful for it in general. Just not sure what I did.

[smcameron]

I think opengl had the better naming convention, +x, -x, +y, -y, +z, -z. You still have to know if it's a left- or right-handed coordinate system though.

[WASasquatch]

I'm so confused. Even following the exact numbering you provided (which is the order Hugin asks for) it's still not aligning right any more. I think I'm going to recompile.

[WASasquatch]

It's specifically the Bottom and Top images which are not aligning. It looks like they need to be flipped/rotated (in Hugin's end).

[smcameron]

Interesting. I will continue poking at it, but I don't have any good ideas at the moment.

[smcameron]

Lol, you made me try DIM 8192 and VFDIM (8192*2), and it immediately segfaults in clone(2). I'm guessing malloc() returns a pointer to address space, but due to overcommit, it's getting clobbered when it tries to actually use that memory. I guess 8Gb RAM isn't enough.

[WASasquatch]

Oh jeez, yeah probably not. I have 32gb on this machine and 64gb on the server (I believe, been awhile since I leased it)

[WASasquatch]

By the way I am currently doing 4096 DIM and 8192 VFDIM, so not that high.

[WASasquatch]

I can use Topaz Gigapixel to safely upscale these, and the AI actually helps improve texture in some cases.

[smcameron]

Here's a thought.... the order of the images is different in opengl cubemaps depending on if it's for a skybox or a planet, e.g. whether you're inside the box, or outside the box. It occurs to me Hugin is meant for panoramas and such, so maybe, inside the box. That order is 3, 1, 4, 5, 0, 2 instead of 1, 3, 4, 5, 0, 2. (kind of a wild guess though.) On the other hand, I use a completely different program for creating skyboxes, so that could account for the different order. (this is all code I haven't looked at very much since 2014 or so my memory is a bit hazy.)

If you get it working, I'd be interested to see whatever project this stuff ends up going into.

[smcameron]

You might also look at the images in share/snis/textures/test[0-6].png

In here: https://github.com/smcameron/space-nerds-in-space/tree/master/share/snis/textures

You can see they also conform to the cube unfolding I described above, and look right in mesh_viewer, you can try upscaling those and running them through hugin to verify your process. We made those test images specifically to debug cubemapping problems.

[WASasquatch]

Welp It was just me. I just randomly went dyslexic on the order. For Gaseous Giganticus -> Hugin it is 2 1 3 1 5 4 (Back, Front, Left, Right, Bottom, Top) using the project file from Adjusting and Creating 360° Equirectangular Images with Hugin (Project file located here: http://www.cs.umd.edu/hcil/ARDN/HuginAdjusts/CubeDraw.pto)

[smcameron]

Cool! Glad you got it sorted! Like I said, I'd be interested to see what you come up with using these giant textures.

[smcameron]

2 1 3 1 5 4

That can't be right, 1 is listed twice. You probably meant 2 0 3 1 5 4

[WASasquatch]

That can't be right, 1 is listed twice. You probably meant 2 0 3 1 5 4

Jesus. There's that dyslexia again. I am really dyslexic, and have dyscalculia. It's a wonder I can even function online. Lol You are correct.