FlightGear Newsletter March 2014: Difference between revisions

Jump to navigation Jump to search
m
→‎Cloud Shadows: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/E495A106FF5F31448739E79D34138C193C6C523E%40mbs2.ad.jyu.fi/#msg32081328
(→‎Random Buildings: http://forum.flightgear.org/viewtopic.php?f=47&t=22273&hilit=)
m (→‎Cloud Shadows: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/E495A106FF5F31448739E79D34138C193C6C523E%40mbs2.ad.jyu.fi/#msg32081328)
Line 58: Line 58:
https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.
https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.


=== Cloud Shadows ===
=== Cloud Shadows (by Thorsten) ===


Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows... In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.
Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:


In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.




For those interested, here's some details to the technique and why it's implemented the way it is:


I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps.
Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.
So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.
There are still two different ways this could be done:
* the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline
* the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline
In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.
The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.
So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.
I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.


=== Random Buildings ===
=== Random Buildings ===

Navigation menu