Thanks for that description, Misho.
Sorry to belabor the subject, but I'm trying to better understand and clarify the actual methods you used to achieve "Volume Shadows" versus "Self-Shadowing" in the user aircraft as you described in your OP above using both terms, as AFAIK,
these are distinctly separate work-flows ...according to this thread started by FSInsider Owen Hewitt:
http://www.fsdeveloper.com/forum/threads/self-shadowing-on-fsx-aircraft-the-secret-is-revealed.2942/
"
Well, I couldn't resist not knowing anymore about self-shadows on aircraft, and I wrote to Adrian Woods (aka ACES' "
Torgo 3000")
for the answer. Here is what he wrote:
"If you’re working with aircraft, we are using a different method of self-shadowing (shadow mapping) that doesn’t require manifold objects. It’s not quite as high fidelity as the volume shadows, but it works for aircraft and doesn’t require the thousands of extra polygons that are needed to manifold the geometry. I’m not sure how you toggle between the two. I’ll have to check on that."
I remember having a conversation with Peter Zahn, also an ACES developer, about this several months back. He was hoping for shadow mapping to become a reality, as he was having a lot of trouble getting good results with manifold volume shadowing on complex aircraft such as the Goose."
...and later in that thread:
"
ACES artists had originally wanted all aircraft objects to require volumetric shadowing, or essentially what you've described above as (stencil) shadows, but they found that very complex objects were not being rendered properly, so the development team incorporated shadow maps to allow the artists some relaxation with regard to polygon counts. Some default aircraft do use volumetric though - the C172 I believe exhibits this.
So, you do not have to have closed objects to have shadows. I do not believe we will see self-shadows in the VC due to it being a huge performance hit."
One might wonder whether, in addition to being
separate work-flows, "Volume Shadows" versus "Self-Shadowing" in the user aircraft are also
mutually-exclusive, meaning one must use either "Volume Shadows"
OR "Self-Shadowing" ...but
NOT both ?
Thanks in advance for any further clarification you may share with us as to how precisely you have implemented "Volume Shadows" versus "Self-Shadowing" in the user aircraft which you described as a "
correct volume shadow (shadow that object casts on itself)" in the OP above.
Perhaps the FS Developer Community might gain some additional insights as to how one may utilize the FS SDK options for such 3D MDL display attributes as cited in:
https://msdn.microsoft.com/en-us/library/cc526973.aspx
FYI: This thread cites the requirements for VC Shadows:
http://www.aerodynamika.com/cgi-bin/yabb2/YaBB.pl?num=1211131092
...and also mentions a Blog article by ACES team member Sebastien St-Laurent (aka "Sebby"):
https://blogs.msdn.microsoft.com/sebby1234/2007/10/08/fsx-dx10-self-shadowing-vcs/
https://blogs.msdn.microsoft.com/se...x-dx10-self-shadowing-vcs-dx9-vs-dx10-update/
...and Fr. Bill Leaming's FSDeveloper wiki on the subject of Manifold objects required for implementing same:
http://www.fsdeveloper.com/wiki/index.php?title=Manifold_geometry
ACES' Phil Taylor posted in his Blog regarding differences in how Shadow Mapping is implemented (and IIUC, how it may be modified as to display attributes
independent of MDL material settings):
https://blogs.msdn.microsoft.com/ptaylor/2008/06/23/yaft/
[
EDITED]
Some related links on Shadow Mapping:
https://en.wikipedia.org/wiki/Shadow_mapping
https://en.wikipedia.org/wiki/Orthographic_projection
https://en.wikipedia.org/wiki/Orthographic_projection_in_cartography
...
also:
https://msdn.microsoft.com/en-us/library/bb975671(v=xnagamestudio.31).aspx
https://msdn.microsoft.com/en-us/library/bb976072(v=xnagamestudio.31).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416324(v=vs.85).aspx
http://learnopengl.com/#!Advanced-Lighting/Shadows/Shadow-Mapping
ftp://download.nvidia.com/developer/presentations/2004/GPU_Jackpot/Shadow_Mapping.pdf
http://roar11.com/2015/05/dealing-with-shadow-map-artifacts/
http://www.stevestreeting.com/2009/01/04/depth-shadow-mapping-dx9-depth-range-gotchas/
"
So Why Doesn’t It Work?
That’s a bit of a generalization, but in many cases people will find this just doesn’t work as they’d expect - either no shadows, or large blocks of shadow where there should be none. There are several reasons why this can be the case, but the most common problem I’ve seen is to do with DirectX 9 and the clear colour of the shadow texture view-port.
You see, the problem is that DirectX 9 can only clear a view-port to a 32-bit number. When clearing a floating-point surface, it has to map this simple integer range onto a floating point range, and it effectively does it by dividing each channel clear colour by 255. This means it can’t clear floating point textures to any number higher than 1.0! When clearing the frame buffer for a shadow texture that stores depths, you need to initialize it to the highest depth value possible so that rendered objects will update it to be ‘closer’. If you’re storing raw unscaled depth, that value needs to be the light’s attenuation range or some other far scene distance. You simply can’t do that in Dx9, so what you find is that your texture contains all 1.0’s in initialized areas. You might think this isn’t so bad, since provided at least one thing is rendered at any particular point, the floating point buffer will be right. That’s true, except that if you have any single-sided geometry (terrain or a ground plane), and you use the default ‘render back faces to shadow texture’ option (highly recommended to make biasing much simpler), you can have significant problems.
Note that the 1.0 clear limit does not exist on GL or Dx10 - on those render systems you can set any floating point values in your Ogre::Colour as the clear colour and they will be respected.
So, how to deal with the 1.0 clear limit in Dx9, and write your shadowing system in a portable way? There are a number of approaches..."
...See also the links in this post (with regard to depth bias):
http://www.fsdeveloper.com/forum/threads/gpw-error-when-adding-specular.437920/#post-750482
[
END_EDIT]
BTW: 'Some' of the above FS web site links suggest that one must use "FSX Materials" to implement "Volume Shadows" versus "Self-Shadowing"; yet curiously, the tutorial linked below cites these terms ...in the context of working with FS9 3D objects:
http://windowlight.co.nz/store/index.php?main_page=page&id=24&chapter=1
My goal here is to see if there is an end-user work-around for the '
offset at high Altitude AGL' that might be currently utilized pending any possible "fix" of purported bugs by DTG in FSX_SE or their FS-derived "FSvNext".
Perhaps if one knows the 3D geometry and material mapping / display Altitude-related behavior relative to the FS "Quad Matrix Grid", one may be able to compute corrections for UVW mapping and/or "
shadow mapping" during 3D modeling, or via an external FS utility (
ex: MCX).
Who knows, maybe we can find a fix for MDL AttachPoint
Effect / other attached object '
offset at high Altitude AGL' too !
Incidentally, here's an interesting option to 'force' use of shadow mapping with user aircraft interior versus exterior MDLs by the use of an undocumented parameter value in FSX.Cfg:
https://stevesfsxanalysis.wordpress.com/2014/10/23/new-fsx-setting-forcevcshadowmap/
All bets are off, though, as to how this may display with the P3D "work-in-progress" code base:
http://www.prepar3d.com/forum/viewtopic.php?t=14165
GaryGB
