I don't know if anyone is interested in what precisely I've been up to of late, but I do know that I get frequently asked why the reflection (bump, you name it) effect isn't yet working in atmospheric light scattering, so this is sort of an answer to that. Well, I also sort of wanted to write that up, to illustrate what kind of problems shader code produces. I'm guessing Fred &Co. know that rather well...
So. it all started with me being unhappy with some visuals of clouds in sunset conditions, and I decided I have to use some data. I spent a few hours measuring (rgb) values of a time series of sunset photographs I had recently taken, in addition I measured light and shadow contrasts from a variety of other sunset pictures. This gave me the clue to at least one source of my unhappiness - unlike implemented in the FG default rendering scheme from where my current light curves are basically taken, ambient light never gets red. Regardless of the rgb value of an illuminated cloud, all shaded parts fall into a very narrow range of blue-grey hue with varying intensity. That's good news as such, because having to compute just the intensity saves two expensive light computations in the shader. So the project was to update the ambient light to a more plausible value everywhere. In computer science textbooks, one does things like Emilian suggested once here, writes a general light and fog scheme which is referenced by all effects and just updates it. Unfortunately, in reality... let's see. I have a scheme which does light correctly for the terrain. This is based on computing light based on the relative location of a vertex to the terminator (the light/shadow line drawn by the sun), and I can compute light and fogging for all positions. I can't simply take the scheme over to the skydome, because the skydome has no 'real' geometry like the terrain. A skydome vertex may return me some position, but that is not a *real* position which would actually tell me how light and fog are there. Instead, the light and fog scheme needs to be adapted to the pseudo-geometry of the skydome where angles more meaningful than distances. I've once tried to take over the scheme to cloud rendering. That, unfortunately, results in very nice still images of beautifully fogged and illuminated clouds at a rate of 1 fps or so. It's way too slow to treat the clouds in a light/fog scheme that works for the terrain. So - clouds need some much faster suitable approximation. For instance, clouds don't even see the ambient light channel - they're just shaded at the bottom/back. So the trick is to make the color of that shade match the ambient light. And that means that shade of clouds isn't just an intensity multiplier, it corresponds to a hue/saturation trafo to the ambient light color. The terrain scheme doesn't work for the water sine shader either, because... that doesn't probe separate ambient light either but is based on the specular light channel. So to get ambient light here, the specular light needs to be post-processed to match up with the ambient light elsewhere if the water is in shade. Unfortunately, as I discovered, a hue/sat rotation becomes numerically unstable if the input color is solid black (as the specular light at midnight is set to be) - so I got this amazing effect where suddenly the water was brightly blue-green illuminated around pitch black islands (I know there's glowing algae bloom in some locations - we can do this...). Some extra code needs to be inserted to prevent this from happening. The default terrain scheme doesn't work for trees either... The reason is rather subtle - in low light, fog is not a device to make the horizon match up, but it becomes largely the object you render. Looking against a hill with the sun behind, you will notice that the hill is dark. We tend to thing that this is because there's only ambient light, so naturally it's dark, but that's in many cases a minor correction to the actual effect, which is that the hill shades the fog between it and the eye, and hence you see the hill through shaded fog, thus it is dark. Regardless of what you do with ambinent and diffuse light, unless the visibility is extremely high, the hill does not appear dark if you do not shade the fog. Of course we can't actually render volumetric shadows in fog, so... we fake it by making the fog color in a semi-clever way dependent on the dot product of light direction and terrain normal, which looks plausible enough. But we don't know the terrain slope for tree rendering, the slope of the tree model is way too steep, so we don't really want to have that effect for trees which don't shade fog appreciably in reality, and thus some additional cleverness is needed. For the urban effect, the default terrain scheme doesn't work either (you probably guessed this at this point, right) - the reason is that the urban effect before atmospheric light uses up too many varying slots already, so it's impossible to squeeze the exact scheme in. But we can use the fact that urban terrain should not be steep slopes (in reality that is), so it's actually okay to drop the fog shading correction if we know we're rendering urban terrain. The good news is - I think the terrain scheme would actually work for the crop effect. In reality things are quite a bit more messy than in the textbook, and lots of work goes into making some things not show up in the final result - if the shader works well, you never notice all the subtle points - which the eye would immediately key on if they'd come out wrong. Unfortunately, the whole framework is also beginning to show complex system dynamics with unexpected cross-repercussions all over the place. Which makes for really interesting bugs. I discovered one which shows up only well after dusk, only if trees are on and only if the dust effect is used. The background is that if the dust effect is used on terrain, it must be used on vegetation as well, otherwise the outcome looks silly, you can't have bright green trees with dust all over everything else. But I implemented dust for trees in a wrong way so that dust color was mixed after part of the light was already done, and so when the light disappeared, a residual of the dust color remained and the trees lost their texture and did not fade into the really dark terrain. Took a while to track it down... At this point, I'm almost through plowing through all the shaders, doing the improved ambient light and color rotations in shade, including the self-shading of clouds and adding moonlight where it makes sense. The results are sort of rewarding... http://www.flightgear.org/forums/viewtopic.php?f=19&t=18325 So, going full circle to for instance reflection shaders - people tend to think of that as something which is simply attached to the surface of the model, so what's the big deal in making it work? The big defal of course it to specify what and when it reflects. Water reflections should gradually change color and intensity as the cloud cover grows. Beyond a certain point, specular reflection dies. It should recognize correctly if the vertex is below or above a cloud layer and usually not reflect below a layer, except of course when in low light the sun is illuminating the layer from below and there is in fact direct light available. But it should not do so if a mountain at the horizon is blocking the direct light. Unfortunately, specular highlights are attention grabbers, so if you have a wrong reflection in the scene, you immediately notice it. Hence it's from a perception perspective safer to have no reflections at all than to have a scheme which gets them 90% right, because the 10% are really going to bite hard. It's doable to compute all these things for your current position - but unfortunatey there's MP and AI traffic, and it really needs to work everywhere, regardless of where the vertex is located. And to come up with a scheme which tells you this runtime is a challenge. Rembrandt is a limited solution - it does the job very well for cases like many limited-intensity light sources, but it can't treat major players like light absorption in clouds or fog self-shading out of the box, and the shadow map is not really large enough to cover things which happen at the horizon. So, that's why I haven't simply taken popular aircraft effects and implemented them with 'just' different light and fog. Cheers, * Thorsten ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
