2D shadow on ground

[Thorsten]

It's the math... I tried to do it in my head, but I realize I left a term out, so it'd project weird of the sun doesn't come from straight above.

[wlbragg]

It's the math

OK

I figured out how I would implement both the 3d and the flat shadow versions depending on whether or not ALS was enabled.
You still use a condition in an animation statement but now it is in two different select statements.
I combined the flat-shadow and the 3d-shadow models into one model with two different object names, flatshadow and 3dshadow respectively. Then you use the condition of ALS active to select which object name to use in your animation statements.
You have to duplicate animation statements, one for each shadow type unless you can manipulate two object names simultaneously.

Code: Select all

<animation>
    <type>rotate</type>
    <object-name>flatshadow</object-name>
    <object-name>3dshadow</object-name>
    <property>/orientation/pitch-deg</property>
    ...
  </animation>

In the shadow.xml, the flatshadow code has the addition of the translate block, the 3dshadow does not.

Switching between the two in-sim seemed to work well enough.

[wlbragg]

After looking at the vert code and the lines you were concentrating on I think I see what's happening.

When I passed
vec4 pos = gl_Vertex straight to gl_Position as in
"gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;"

or eliminate the suggested change of "pos.z= -0.95 * alt_agl+0.1;"

The "3d" shadow rotates and pitches opposite of the aircraft?

pos.z-=0.95 * alt_agl-0.1;
to
pos.z= -0.95 * alt_agl+0.1;
is flattening shadow vs 3d?

We need gl_Vertex or "pos" to be mirrored to the aircraft?

[LesterBoffo]

Funny what comes around again.

Will's idea for making a volumetric shadow model is how SDoE and Fighter Squadron WWI has been doing their shadow models for SDoE aircraft for many years now..



In the image above of the AVRO-504, you can see a rougher 3D model below the main sim model, and that is the 3D shadow model. It is colored with a flat black texture that has a special channel added to kill the z-fighting with the ground.



Since this is also a OpenGL sim it seems that shadow generation is not a trivial thing in OpenGL.

[Thorsten]

Since this is also a OpenGL sim it seems that shadow generation is not a trivial thing in OpenGL.

In real-time 3d rendering in general. To be very fast, all tasks are parallelized, so the GPU can crunch every vertex and every pixel independent of what the others do. The price for that to work is that you track only the ray from light (L) to object (O) to eye(E), so if that's the relevant geometry, you don't need to know anything else of the scene, you can get all the reflection angles at the object in one go.

To place a shadow, you want to know whether the ray L-O intersects somewhere else before it illuminates, i.e. evaluate L-O-O-E - and that's no longer factorizable - now at one vertex, you need to know all the others. I.e. a GPU can't evaluate this (raytracing still can easily, but that doesn't run in real time...) - which is where we need various tricks.

Which range from very cheap (fake shadows) to very expensive (additional shadow camera or shadow volume creation and stencil buffer passes over the whole scene).

pos.z-=0.95 * alt_agl-0.1;
to
pos.z= -0.95 * alt_agl+0.1;
is flattening shadow vs 3d?

First one is a relative change, i.e. a translation. Since the 2d shadow is flat in the first place and probably at zero coordinates, that should be okay. Second one is an absolute assignment of a z-coordinate which is independent of where the model previously had its z-position, so it squishes the whole model into one plane.

The projection problem is in the (xy)-coordinates though - there needs to be a pos.z dependence on the new coordinates for a correct projection.

[LesterBoffo]

I'm taking from this that the 'real expensive' trick is the one provided by Rembrandt. Since I run a 4:5 ratio monitor I probably gain a little on this, but my GPU card is old enough to not like Rembrandt in FG cranked all the way up. In SDoE on the other hand, even with the 3D shadows I'm running in multiples of 100's frame rates. The only time it really dogs <25 FPS is when there's a major furball with more than 7 aircraft shooting at each other.

This BTW is the sim that uses modified .ac files with internal animation text properties.

[Thorsten]

I'm taking from this that the 'real expensive' trick is the one provided by Rembrandt.

Rembrandt uses the shadow camera pass. The shadow volume technique is, I believe, even more expensive to do on a larger scale. There's about 100 pages of techniques how to generate shadows in my real-time rendering book, you can make this very sophisticated, but most games have only a very small scene to render (since you're on the ground exploring a level or so) and have far more resources left to throw at such things than a flightsim.

[LesterBoffo]

I can imagine in a FPS or swordplay sim with multiple light sources, the debit of multiple shadows gets rather large. I understand what you're saying, we work in a canvas measured in many square miles, especially with excellent visibility and altitude. There would have to be an aggressive LODing of shadows with lesser GPU's.

[wlbragg]

I'm experiencing an erratic behavior with the ALS-shadow. Using a property rule, I use a "reference" value of 0 and the shadow is at the correct AGL. But as soon as I either switch out of ALS and back into it or Debug\Reload Aircraft Model it repositions the shadow below ground level. It turns out to be about 4 "reference" units difference.
In other words, if I start out with reference=4 the shadow starts out around cockpit eye-level, upon Debug\Reload Aircraft Model or Rendering\ALS off then back on, it repositions to approximately the correct level (close to the ground)
I checked the altitude-agl-ft and gear-agl-m values in the prop tree before and after the Debug\Reload and they remained consistent (they weren't changing value, which would have accounted for the AGL change).

Any idea what's going on?

[wlbragg]

More questions on this "erratic behavior" of the ALS-shadow when using a property rule and a Debug\Reload or ALS\off-on condition.

It may have something to do with the property rule and the "Translate to ground level" code conflicting with each other..

If I remove the remove the "Translate to ground level" block completely, then a Debug\Reload or ALS\off-on condition has no effect on the ALS-shadow.

I don't know how to isolate the "Translate to ground level" block in shadow.xml from a Debug\Reload or ALS\off-on condition.

I tried different combinations of conditions on the "reference" in the filter to no avail.

Anyone have any ideas?

[Thorsten]

As we've recently discovered, property changes are no longer transmitted to uniforms after a reset due to a bug - I don't know whether model reload triggers the same / a similar thing.

[wlbragg]

property changes are no longer transmitted to uniforms after a reset due to a bug

OK, I think it may be related. I'll wait for resolution and see if that fixes this problem.
Right now it's only a problem if you use debug model reload or switch out of ALS and then back into it in the same session.

[mhab]

Hello

So I use the EC130, add the described code to the xml file where the shadow is included and try what happens.
(I disabled rembrandt b.t.w)

I get NO error on the console and the shadow is the same as always. It doesn't move with the sun.
If I remove the animations it flies with the heli.

What do I miss out ?

Mike-DE

[wlbragg]

Code: Select all

<effect>
    <inherits-from>Effects/shadow</inherits-from>
    <object-name>shadow_fuselage</object-name>
</effect>

<!-- shadow derived from BO-105 -->
<!-- show only if enabled -->
<animation>

and

Code: Select all

<animation>
    <type>translate</type>
    <name>fu_trans</name>
    <object-name>shadow_fuselage</object-name>
   <!-- For FG versions -=3.2comment out the condition block-->
   <condition>
    <not>
      <property>/sim/rendering/shaders/skydome</property>
    </not>
   </condition>
    <property>position/gear-agl-m</property>
    <axis>
      <x>0</x>
      <y>0</y>
      <z>-1</z>
    </axis>
  </animation>

[wlbragg]

In the select animation I normally would do

Code: Select all

<animation>
    <type>select</type>
    <name>fu_select</name>
    <object-name>shadow_fuselage</object-name>
    <condition>
      <not>
        <property>/sim/rendering/rembrandt/enabled</property>
      </not>
    </condition>
  </animation>

The sun angle condition isn't necessary with ALS, it handles this
<less-than>
<property>/sim/time/sun-angle-rad</property>
<value>1.40</value>
</less-than>

If I have trouble getting the ALS and non-ALS shadows to translate to the ground correctly using these methods, then use the property rule to position the ALS shadow.
Also the property rule is necessary in some JBSim aircraft that aren't reporting position/gear-agl-m.