-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fails to produce sensible images with very large dimensions #10
Comments
Alright, so I believe the problem here is that with 4096x4096x6 pixels to fill, but with only 8000000 particles by default, only about 8% of the surface area is covered, and with the "cache aware particle placement", (see -K option), these relatively few particles compared to the area to be covered become concentrated, leaving much of the surface uncovered. If you use "-K 0.0" option (0% "cache-aware particle placement" and 100% random particle placement), things look more "normal" though the default number of particles is too low with such large textures. (See -p option to set number of particles.) I think, with -K 0.0 and with sufficiently large number of particles (and sufficient RAM to hold them all), it should be workable to produce 4096x4096 images, though I haven't verified it myself. There may still be a bug here though, as the "cache aware particle placement" does try to spread the particles around, but perhaps in situations where the total number of particles is small compared to the area to be covered, something breaks down there. In any case, to produce acceptable images of this size, a lot more than the default number of particles will be required. Here is a picture of a planet with 4096x4096x6 textures generated by "./gaseous-giganticus -K 0.0 -i i0.png -o testbig2 --noise-scale 2.5 --velocity-factor 1300 --bands 10", with 8000000 particles with "-K 0.0" option. The noise scale probably needs to be adjusted for such large textures as well. |
Brilliant, thanks Stephen. I produce similar results with the default particle count, velocity factor and noise scale, but will definitely have a play around with the different settings and report back. Personally not so worried about compute time - I am assuming computation is via CPU? |
Yeah, it's all done on the CPU. Doing this on the GPU is too difficult for me to wrap my head around, so far. I did notice this not too long ago: https://www.wedesoft.de/software/2023/03/20/procedural-global-cloud-cover/ which uses a similar method, but done on the GPU, though I think it's more for cloud cover on terrestrial planets than gas giant texture generation, it might be adaptable, by someone smart enough (which is to say, probably not me.) |
BTW, if you do make something cool, please do post a pic or two here, if you can, I'm always curious to see what people make with help from my little program, sometimes they make some pretty cool stuff. |
Success. I was able to produce great results with essentially the default values, but with a K of 0.0 and particle count of 96m. This was sufficient to mostly remove the dimming at the tile seams. I also ran it at -c 200 as higher values were wiping out some of the nicer swirls. Render times were not too bad, mostly less than 10 mins on my 3900x. Unfortunately my Virtual Ubuntu session (running in Win 10) has crashed so I can't go back through and document my findings, but from memory:
Thanks for your help and when I get another chance I will do some more testing! I would like to try one of your techniques where you generate small swirls, then feed the result back through to generate the larger swirls |
Beautiful! |
When VFDIM is say, 8192, and cache aware particle placement is used, strange things can result. See: #10 We should at the very least, warn, and prescibe a workaround. Signed-off-by: Stephen M. Cameron <stephenmcameron@gmail.com>
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.
The text was updated successfully, but these errors were encountered: