Planetside Software Forums

General => Image Sharing => Topic started by: Denis Sirenko on April 24, 2018, 06:46:48 AM

Title: Procedural volumetric stars
Post by: Denis Sirenko on April 24, 2018, 06:46:48 AM
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.

Title: Re: Procedural volumetric stars
Post by: N-drju on April 24, 2018, 07:02:02 AM
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. ;)
Title: Re: Procedural volumetric stars
Post by: Dune on April 24, 2018, 07:44:48 AM
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!
Title: Re: Procedural volumetric stars
Post by: 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.
Title: Re: Procedural volumetric stars
Post by: WAS on April 24, 2018, 03:03:59 PM
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.
Title: Re: Procedural volumetric stars
Post by: WAS on April 24, 2018, 03:32:43 PM
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)
Title: Re: Procedural volumetric stars
Post by: Oshyan on April 24, 2018, 08:25:27 PM
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
Title: Re: Procedural volumetric stars
Post by: WAS on April 24, 2018, 11:09:05 PM
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.
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 02:20:09 AM
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).
Title: Re: Procedural volumetric stars
Post by: 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
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 02:50:52 AM
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
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 03:55:21 AM
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 (https://planetside.co.uk/forums/index.php/topic,24308.0.html) 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.
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 05:21:01 AM
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
Title: Re: Procedural volumetric stars
Post by: WAS 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. 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. 
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 04:19:20 PM
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
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 04:31:23 PM
Talking about inverse square falloff using functions - I used that technique here, but along a line instead of a point:

http://www.artofvfx.com/TRONLEGACY/TRONLEGACY_PF_VFX_06.jpg

(EDIT: for a line it would just be inverse rather than inverse-square)

Matt
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 04:38:19 PM
Quote from: Matt on April 25, 2018, 04:31:23 PM
Talking about inverse square falloff using functions - I used that technique here, but along a line instead of a point:

http://www.artofvfx.com/TRONLEGACY/TRONLEGACY_PF_VFX_06.jpg

Matt
l
Honestly haven't even ever thought of that approach. So far I've been using the modulator just to give the stars their individual colours via a extreme contrast mask. I'm curious where one would start?

I have done luminous background stars, they work pretty decent, though I've had numerous issues with camera positions and stars not appearing right. I don't know if that's the curve/angles of the background object or what. This method also is of no help for nebulas/galaxies.

I'm still tinkering with an object population and some PFs to see if I can get an actual volumentric looking population with some decent lighting, but so far it's all just a headache and not even remotely as simple as a cloud setup. Which works much better in final result. I know you say the light is working the same, but somehow clouds (not being a solid object or what, my cloud at least not not totally solid, meaning light is being produced by semi transparency) and clouds capturing this works differently than an object. It's plainly visible.
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 04:44:34 PM
I'm curious what the actual luminosity of the Ambient slider is. For example. What is "1" on the ambient slider compared to "1" on the Luminous slider? Cause They also yield different results, adding to the concept that what TG is interpreting the two instances differently.

On a side note I'm finding it crazy how my assumptions on films are starting to pan out with TG use. I also thought Tron was using TG clouds. There's a Star Trek game in development where the guy has used TG to create his sky boxes instead of using TrueSky. Right off the bat I knew it was TG. I'm not sure if that means I'm recognizing true realism or some sort of surrealism, but it's really interesting to discover.
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 04:52:50 PM
Quote from: WASasquatch on April 25, 2018, 04:38:19 PM
l
Honestly haven't even ever thought of that approach. So far I've been using the modulator just to give the stars their individual colours via a extreme contrast mask. I'm curious where one would start?

For an individual point you calculate the distance from the point (using either function nodes or a distance shader) and then divide by that distance (or by the square of that distance). For many procedurally generated points you might need to use a technique similar to how people have rendered craters using a Voronoi function. I haven't tried it though.

Quote
I'm still tinkering with an object population and some PFs to see if I can get an actual volumentric looking population with some decent lighting, but so far it's all just a headache and not even remotely as simple as a cloud setup.

Quote
Which works much better in final result. I know you say the light is working the same, but somehow clouds (not being a solid object or what) and clouds capturing this works differently than an object. It's plainly visible.

I have not seen that difference demonstrated. I want to understand what difference you're talking about, but I understand that you have a technique that works for you and that's really what counts.

Matt
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 05:02:40 PM
Quote from: WASasquatch on April 25, 2018, 04:44:34 PM
I'm curious what the actual luminosity of the Ambient slider is. For example. What is "1" on the ambient slider compared to "1" on the Luminous slider? Cause They also yield different results, adding to the concept that what TG is interpreting the two instances differently.

Ambient is multiplied by the colour of the cloud (and also by density at each point). If the cloud colour is black, ambient will not make it any brighter. If the cloud is red, then white ambient will make the cloud a brighter red. It's like shining light onto the cloud, except it has no direction, it's just "there". The amount of ambient light you see depends on how much the cloud can reflect back to you according to its colour and density.

Luminosity (also known as emission) is different in that it works even if a surface or cloud is black. It simply emits light regardless of any other reflection characteristics of the surface. If the cloud layer had a luminosity control (it doesn't yet because most needs are covered by the ambient control), then it would be completely independent of the cloud colour. However, just like with ambient, the amount of light you see would still be affected by cloud density.

Matt
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 05:03:32 PM
Quote from: Matt on April 25, 2018, 04:52:50 PM
For many procedurally generated points you might need to use a technique similar to how people have rendered craters using a Voronoi function. I haven't tried it though.

I actually was thinking of using that very voronoi setup in general for the original mask, as it creates more varied (further apart) points, which are also perfectly round, and can be clamped in to desired points.

Quote from: Matt on April 25, 2018, 04:52:50 PM
I have not seen that difference demonstrated. I want to understand what difference you're talking about, but I understand that you have a technique that works for you and that's really what counts.

Matt

Basically, I'm asking what the calculations are on the sliders for luminosity. When I setup two instances, one a pop, and one clouds, at the same "supposed" luminosity, they act different whether their emitted light.

I'm wondering if this is because the Ambient Slider is not the same as the Luminous slider, or maybe because our clouds are not solid objects. They're transparent objects with opacity, and their own internal scattering before emission?
Title: Re: Procedural volumetric stars
Post by: WAS on April 25, 2018, 05:04:59 PM
Quote from: Matt on April 25, 2018, 05:02:40 PM
Quote from: WASasquatch on April 25, 2018, 04:44:34 PM
I'm curious what the actual luminosity of the Ambient slider is. For example. What is "1" on the ambient slider compared to "1" on the Luminous slider? Cause They also yield different results, adding to the concept that what TG is interpreting the two instances differently.

Ambient is multiplied by the colour of the cloud (and also by density at each point). If the cloud colour is black, ambient will not make it any brighter. If the cloud is red, then white ambient will make the cloud a brighter red. It's like shining light onto the cloud, except it has no direction, it's just "there". The amount of ambient light you see depends on how much the cloud can reflect back to you according to its colour and density.

Luminosity (also known as emission) is different in that it works even if a surface or cloud is black. It simply emits light regardless of any other reflection characteristics of the surface. If the cloud layer had a luminosity control (it doesn't yet because most needs are covered by the ambient control), then it would be completely independent of the cloud colour. However, just like with ambient, the amount of light you see would still be affected by cloud density.

Matt

This seems to shed some real light on why interactions are different with the two setups.
Title: Re: Procedural volumetric stars
Post by: Matt on April 25, 2018, 05:15:30 PM
I see what you did there  ;D
Title: Re: Procedural volumetric stars
Post by: pclavett on April 26, 2018, 09:55:52 PM
Love your experimenting with the nebulas and stars !
I just love space scenes but using pictures for background has its issues.
Love the  fact that some of you are experimenting into procedural generation of these items.....will follow closely.....not sure i will understand though !
Thanks for sharing !
Paul