Procedural volumetric stars

Started by Denis Sirenko, April 24, 2018, 06:46:48 AM

Previous topic - Next topic

Denis Sirenko

I'm here to start a new topic, so as not to clog the topic of WASasquatch's (https://planetside.co.uk/forums/index.php/topic,24336.0.html). There we discussed the procedural generation of stars in the 3D Terragen (not on background) space.

[attachimg=1]

There was a problem with how the stars are rendered. Each new render of the same scene led to a different arrangement of the stars.

Quote from: Oshyan on April 23, 2018, 05:45:38 PM
I'm honestly not sure how your cloud-based star method works, so I can't say exactly what the issue might be. I guess your clouds are luminous though?
- Oshyan

Yes, Oshyan, here's the scene. Clouds luminous through the ambient light modulator input.


N-drju

So if it's based on stationary clouds, how come the stars turned up in different locations on each render?

This is a very interesting solution. The night skies have finally been freed from the tyranny of the background sphere. ;)
"This year - a factory of semiconductors. Next year - a factory of whole conductors!"

Dune

Interesting indeed. Never thought of this (never needed to either), but these are real 3D stars, whereas the background dots are merely background dots. I wonder how fast/slow they are to render though.
Thanks for sharing, Denis!

Kadri


I think the main problem is the jittering setting in the cloud.
But in case that i have changed other things and if it works or not, have a look for yourself.

WAS

#4
Quote from: Kadri on April 24, 2018, 12:20:24 PM

I think the main problem is the jittering setting in the cloud.
But in case that i have changed other things and if it works or not, have a look for yourself.

It's interesting that render time on this is about 111% over my setup, even if my setup has "millions" of stars and individual star colours. I'm wondering why. Even cloud quality is 0.1xx over my 0.45

There is even half the polygons at the same quality settings, with more stars (and cloud layer quality bumped up much higher).

Added another render with no jitter which seems to add 10s to the render time.

No jitter is seeming to solve to per-render star position issue. Haven't tried shifting positioning yet.

WAS

Just to ensure there was no variation in the no jitter result I did a difference comparison in photoshop, and this is what we get! (Solid black is good, means there is no difference between he two renders AT ALL)

Oshyan

Unfortunately, although disabling Jitter will fix it for a still frame (because the sample positions are no longer randomized), it will probably still not work for *Animation* because the sample positions move with the camera/view/render area, and thus become "random" relative to the star positions. The underlying problem is still *undersampling* - very small points of very bright light that are difficult to sample consistently, and so show up essentially randomly.

I would say a couple things regarding the test file attached above. First, v3 clouds are probably not needed here, and may even be a problem because they use the voxel buffer (and you can't turn it off), which could add further per-frame variability. They also take longer to render and since their primary advantage is in shading of external light within the volume, you basically lose all benefit when your cloud is *emissive* (luminous). At least as far as I know. So you'll get faster and perhaps even more consistent results with v2 cloud.

That being said, although this is an interesting solution to volumetric "stars", I'm not sure it will ever quite work the way you want it to. But to determine that I'd suggest starting with much bigger luminous shapes in the cloud and see if you can get *those* to render consistently, even in animation. Once you have that "stable" (i.e. consistent between frames), then you can work on smaller and smaller shapes, until you find the point where they start to sample inconsistently as they do now. Hopefully you can get small enough shapes before this happens, but I think it will be difficult to find out by starting with these sub-pixel (very small) shapes and increasing size until you can sample them well. This is because we don't even know if really large shapes (relative to camera space) would sample consistently with your settings (some of which are quite extreme, such as the glow).

- Oshyan

WAS

#7
For me, it's about creating still stars since I cannot animate, however I still want to tackle the issue for everyone else, cause it does seem like with this approach, with fine tuning, it's possible to create a star field "above" clouds and what not, for planets, and for scenes like Denise's.

I've created a new test starting at a scale of 1000m and reduced coverage from there, and applied to cameras, one shifted by 5k meters, will see if star positions seem "Familiar".

Unfortunately even at super large scales they seem to move about. This is a -5000 shift comparison on the Z axis, with the camera centered in on the source cloud. You can see where the new stars are similar to their original positions, but have shifted, and new stars created.

Will try one more test knocking up the map 5-10x in scale.

WAS

#8
Alright, so I  raised my coverage reduction from -50 to -45 (with a contrast of 100). I did not change the stars altitude so they are larger in appearance, however with this setup, the stars appropriately tilt as seen in this example gif.

Anti-Aliasing is still a concern when working with these volumetric stars between quality settings (lower = less stars).

Matt

This isn't a good way to render small points. Clouds are rendered using ray marching, which is great for slowly changing functions such as clouds but very bad for searching out tiny points of light in a vast volume of emptiness. It would be much better to use a populator to scatter luminous objects. If you're trying this volumetric approach to try to work around limitations of casting light from the populator, then you need to know that those limiations will also apply to a cloud-based star function.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

Do they need to be scattered in 3D or do you just need a starry background? If the latter, why not use the background sphere?

Matt
Just because milk is white doesn't mean that clouds are made of milk.

WAS

#11
Quote from: Matt on April 25, 2018, 02:47:30 AM
This isn't a good way to render small points. Clouds are rendered using ray marching, which is great for slowly changing functions such as clouds but very bad for searching out tiny points of light in a vast volume of emptiness. It would be much better to use a populator to scatter luminous objects. If you're trying this volumetric approach to try to work around limitations of casting light from the populator, then you need to know that those limiations will also apply to a cloud-based star function.

Matt

As discussed in the luminous surfaces topic I made just recently, objects and surfaces giving off light pretty much break Terragen and are of no use at all. Needs much work. At the lighting scales (since there is no light distance control) you have to break TG with intensity before the look you want even starts showing (under the broken diffused pixels). Also, the light casting was either "On" or "Off" when playing with the intensity, which, when "on" was just ridiculous bright and the light distance goes on forever (that you can see). Additionally, ramping up luminosity to scales that produce good glows that cast, cause the object to turn solid white.

This approach, however, gives off glowing light without creating a million scattered pixels and weird lighting artifacts.

These aren't really tiny points of light, they are in fact clouds, that also glow (density plus ambient/modulator). And they're pretty large, and can get larger. The point of using this is using actual stars to light nebula cloud forms, or galaxies, etc, or in a testing project, an actual "star layer" well above planets and their atmospheres. Simulating stars in the sky on a small scale. Doesn't look half bad if only there was light dampening, when light sources are not as luminous as another, they don't shine basically (like our own sky and stars disappearing during the day)

Denise has shown us that Terragen can create near perfect (to the eye) nebulas compared to any other program I have seen, where nebulas come of surreal or just plain fake. Improving it with volumetric stars you can pan around would be awesome, both in animation and just stills.

Matt

#12
That all makes sense.

You're getting some results here. But I don't think it's because you switched to using a cloud, so I want to make sure you don't avoid using luminous objects for the wrong reason. Bear with me...

In Terragen, light cast from a glowing cloud layer to a receiving cloud layer is calculated using the same method as light cast from glowing objects to a receiving cloud layer. And in both cases it's very difficult to get an artefact-free result for small bright stars. It might work well if you make an invisible set of stars that are much larger than the visible stars, but then you can do that with objects too - that's why I am questioning the cloud method.

I noticed you have bloom and atmo bloom enabled in the render node (maybe from Denis's opening post?), and that's giving you a nice glow. But this works just as well for glowing objects as it does for glowing bright cloud points.

To make sure I'm not crazy, I took your scene file "Stars Offset Example.tgd" and added a Cloud Layer V3 to receive light from the stars, and also added a Rock population for comparison. The lighting effect on the receiving cloud works similarly in both cases (some voxels receive light and others don't), but you have some nice colour variation in your stars. And I do like the idea of using a volumetric function to define star density and colour.

Whichever method you use (cloud or objects), you need the stars to be quite large to produce smooth blotch-free lighting. Much larger than they are in this scene. That means you probably need to have one invisible layer/population for casting light (secondary rays) and another layer/population which is visible but does not affect secondary rays. Or just use bloom and/or atmo bloom which works well with very small points.

I've attached some .tgd files:

tgd #1 is just a simple comparison between glowing clouds and glowing rocks, showing that there are similar problems in both cases (higher cloud GI settings and voxel settings might be able to turn this into a much better render).

tgd #2 uses two rock populations. Invisible rocks are much larger so that the cloud layer finds it easier to sample them for lighting. The visible rocks are smaller and have "visible to other rays" turned off so that they don't create blotchy lighting problems.

The best way to handle this in some future version of Terragen  8) will be with light populations (which you asked for in the other thread, and I'm pretty sure we'll add that some day).

Matt
Just because milk is white doesn't mean that clouds are made of milk.

WAS

#13
They may act the same way at the base code level, but what is iterated through each element is a totally different effect. We have already added stars to our nebulas/galaxies via clouds, and they work, actually very well. Light being cast doesn't go on forever at appropriate intensities, etc. With your example, you can plainly see the graining discussed, as well as the actual lighting artifacts. It also appears your light sources aren't actually coming from the objects in the first example.

Overall, it's just not an appropriate method or look (was even told so in topic trying to use them), where clouds are. I understand you want to declare it a method that isn't appropriate due to how things function, but for final results, it's the only method appropriate besides manual light source placement. I haven't played with GI much, I did with my first stars and literally no adjustments fixed seams, but those stars were absolutely tiny, and not 10+ meters from 1000m scales.  A populator would be amazing. And for still work, which frankly, most people do in TG, it's amazing. Though as shone with my offset example, the stars positions remain true even at a offset of 5000m.

Additionally, you can use this method for global volumetric clouds, an actual cloud layer above your planet. Similar to using the background object but actually luminous and positions vary based on your position on the planet (though in the real world these variations would be much smaller. Probably obtainable with super huge scales or a very thin depth to prevent "depth".

The second example looks promising. But, unfortunately, the methodology just doesn't translate well. It still creates pixelation out of the clouds, and playing with GI on a per-project basis was always a turn off for me. The stars themselves do not look good, and are not varied in size appropriately, leading one to insert many populations masked for appropriate procedural stars, as well as many more for depth. I see you used the terrain node to create some depth but this doesn't seem to be working well? Especially for a cloud depth of 20000m (ramping up the displacement multiplier didn't get them throughout the clouds, and just pushed the whole population away). Rock populations at this point would be adding 10x the work, in place of something that seems to be working despite the debate. Couple of the stars literally inside the nebula seem to do no close range glowing, it's all one solid carpet of luminosity at it's max distance to the the upper most drop-off.

In the preview, despite ramping and playing with displacement, the stars are still relatively a plane, and only illuminate about 10% of the nebula. Though we don't want it all illuminated, we definitely don't want a cross-section. Ramping up luminosity to get some more effect out of smaller cloud forms pushes the lighting back into the broken range. 

Matt

#14
Hi WAS,

My goal is to give everyone a better understanding of how TG works. So I want to separate what's better about glowing clouds from what's actually the same as with glowing objects.

Quote from: WASasquatch on April 25, 2018, 02:19:12 PM
They may act the same way at the base code level, but what is iterated through each element is a totally different effect.

Perhaps we are talking about different things. I was just talking about how light from the stars affects any surrounding cloud using GI, not the shape of the stars themselves. Are we talking about the same thing?

GI isn't good enough to light the surrounding cloud at very short ranges, but at longer distances away from a big star or a cluster of bright stars it could be useful, and that's what I thought you were trying to do. If so, it really is the same whether you use a glowing cloud or a rock population. It may seem different in my example because I didn't spend time making the rock population look the same as your cloud. Generally 'matt 01' and 'matt 02' are not good scenes for demonstrating how well this GI method could work, because with 'matt 01' I was trying to demonstrate that the GI is of similar quality regardless of whether you use clouds or rocks.

Quote
We have already added stars to our nebulas/galaxies via clouds, and they work, actually very well. Light being cast doesn't go on forever at appropriate intensities, etc. With your example, you can plainly see the graining discussed, as well as the actual lighting artifacts. It also appears your light sources aren't actually coming from the objects in the first example.

Yes, that's true. In 'matt 01' I used a blue-ish cloud to demonstrate the problem that I thought you were talking about. I agree it doesn't look good. You can clearly see that some voxels are not receiving light, and the voxels are too big to ever make this look good. I was trying to demonstrate that it's the same problem in both cases. If you render 'matt 01' with the cloud-based stars enabled instead of the rocks, you will see the same blocky lighting as with the rocks.

But now I think I understand that you weren't trying to generate GI at all, is that correct? Maybe I was sent in the wrong direction because previously you were trying to do this with tiny glowing rocks.

For short range lighting, you either need real light sources or you need to simulate the correct inverse square falloff with the ambient light modulator, similar to what you and Denis are doing in this thread. I think your technique could be built upon to create a more realistic inverse square falloff at each point. Nearby clouds won't have proper shadow-casting or self-shadowing this way, but you probably don't need that very often.

Quote
Overall, it's just not an appropriate method or look, where clouds are.

Yeah, that's true at short ranges. Voxel cache-based GI doesn't give you a sharp inverse square falloff close to the stars, whereas you could do this with a glow function.

Quote
I understand you want to declare [glowing clouds] a method that isn't appropriate due to how things function, but for final results, it's the only method appropriate besides manual light source placement.

I think I understand what you're trying to do now. Until recently you were using tiny points of light much smaller than a pixel, so I thought you were just trying to create something for the GI engine to pick up on (hence my trying to show you that rocks do exactly the same job - and I promise you they do). But if you guys are using the glow to simulate the light falloff around the star, then I completely understand and I think you have a good idea.

Quote
I haven't played with GI much, I did with my first stars and literally no adjustments fixed seams, but those stars were absolutely tiny, and not 10+ meters from 1000m scales.

Yeah, it doesn't work well.

Quote
A populator would be amazing. And for still work, which frankly, most people do in TG, it's amazing. Though as shone with my offset example, the stars positions remain true even at a offset of 5000m.

Additionally, you can use this method for global volumetric clouds, an actual cloud layer above your planet. Similar to using the background object but actually luminous and positions vary based on your position on the planet (though in the real world these variations would be much smaller. Probably obtainable with super huge scales or a very thin depth to prevent "depth".

Yeah there are some advantages related to how you position the stars that might be more cumbersome with a populator.

BTW, the background sphere can be made luminous - just throwing that out there in case you didn't know, and I see a lot of people mapping images onto the background without knowing how to make it luminous. You just need a Default Shader and plug into the luminosity function or the luminosity image.

Quote
The second example looks promising. But, unfortunately, the methodology just doesn't translate well. It still creates pixelation out of the clouds, and playing with GI on a per-project basis was always a turn off for me.

Yeah.

Quote
The stars themselves do not look good, and are not varied in size appropriately, leading one to insert many populations masked for appropriate procedural stars, as well as many more for depth. I see you used the terrain node to create some depth but this doesn't seem to be working well?

I didn't spend any time trying to make them look good, but with a few minutes work their density, brightness and colour could all be modulated using fractals and lots of other interesting ways.

Quote
Especially for a cloud depth of 20000m. Rock populations at this point would be adding 10x the work, in place of something that seems to be working despite the debate. Couple of the stars literally inside the nebula seem to do no close range glowing, it's all one solid carpet of luminosity at it's max distance on the the upper most drop-off.

Yeah, it lacks proper fall off at close ranges. At long ranges it should be correct.

Matt
Just because milk is white doesn't mean that clouds are made of milk.