2D shadow on ground

[wlbragg]

OSG tries to figure out which transparent objects are in front

Yeah, that make sense.

[LesterBoffo]

Thought I'd just hop in to play Captain Obvious.

The shadow volume .ac for my MF-11 has a smidge of transparency in the material's header, and it uses a 16X16 size, completely black .png texture. (RGB set 0/0/0. The polys are all set to '2 sided' in AC3D.

I'm reminded of a situation we had with the shadow volumes in FS-WWI. When imported into the .sm file, the '.lod's' (exported singly from the .ac's objects) had to be manually texture/material reference edited by opening the .lod in MS-Wordpad and changing the 'flag' column from whatever it was, to 'f0' If this is even applicable in an .ac in FG. Doing this stopped the terrible z-fighting in SDoE.

Doing this in Blender gives me a migraine, just thinking about it, as we all dreaded doing flag conversions on shadow objects.

[wlbragg]

Thanks for info LesterBoffo.

[LesterBoffo]

If you want to try an experiment, send me your simplest, one object shadow volume and I'll see if I can find the flag index and convert it with Open Plane Studio.

But please no big files, and try and make sure it's got less than 200~300 polys

[Thorsten]

Whether this is a "feature" or a "bug", that is for Thorsten to evaluate, but for now it seems to work that way.

Let's call it a quirk. Keep in mind that the 3d shadow technique started out as a spinoff of the 2d technique - I originally thought they could share all code, turned out to be less than expected, but I got them to share the fragment shader. Which may not be optimal.

Admittedly aircraft shadows aren't very close to my heart. This was technically interesting (i.e. the math was cool to work out), but it's not been a feature I've been designing from scratch thinking every aspect through.

I got decent results with the MF-11 though...

[wlbragg]

The shadow volume .ac for my MF-11 has a smidge of transparency in the material's header,

I am pretty sure the transparency setting is a requirement in the current state of the shader. I can reproduce the behavior I described if I only load the shadow object: no aircraft, no cockpit, no nothing, just one simple object that is assigned to the shadow-vol effect.

It is not the texture. It is the material transparency that is interfering.
If I add just a little bit of transparency to the material that is defined in the shadow object, then the effect gains control and will adjust properly based on weather conditions. If transparency is set to 0.0 however, the shadow is pitch black regardless of whether its raining cats and dogs.
It's worth noting that the amount of transparency that is defined in the material does not affect the result, as long as it is not 0.0. The shadow looks exactly the same given the same environment conditions regardless of whether transparency is set to 0.9 or 0.1.

I finally got back to this and I think this is the correct analysis for my situation. I gave the shadow just a touch of transparency and it is now adjusting to the available light.

[AndersG]

To follow up on the projected shadow:

How are the windows done (i.e. is this a depth-sorting issue)? And what are the issues on the ground - z-fighting?

The windows are transparent and double sided (or there are two separate sides, I don't remember) so that problem can certainly be a depth sorting issue. Though, I did try moving my view point outside the window once or twice and could not see the shadow reappear. Switching to an external view would show the shadow.

The other problem is that I don't seem to be able to displace the shadow from the model origin on the z-axis in a consistent way. The shadow object and the aircraft have the same origin so there should be no problem there but the shadow (even over flat ground) seem to change altitude with aircraft pitch and roll. This is odd since my portable patch of water (FlightGear-MTB_20m at my github place) which uses a similar displacement method was consistently at ground level despite the aircraft orientation (but the water is always directly below the aircraft).

There is also some view point or view direction related clipping that cuts part of the shadow at times (in an external view while rotating around the stationary aircraft). This could be some graphics card related GLSL issue - I have an old GeForce 9800GT.

The Nordstern shadow is not yet in FGAddon, but I have committed a very similar setup for ZLT-NT. It has the same issues.

Relevant parts of the instantiation for Nordstern follow below:

Models/shadow.xml which controls the shadow object, it is loaded with the same origin (the nose) as the main model:

Code: Select all

<?xml version="1.0"?>
<PropertyList>

 <path>shadow.ac</path>
 <offsets>
  <!-- x/y/z == back/right/up -->
  <x-m> 0.0 </x-m>
  <y-m> 0.0 </y-m>
  <z-m> 0.0 </z-m>
 </offsets>

 <effect>
  <inherits-from>Effects/shadow-vol</inherits-from>
  <object-name>shadow.object</object-name>
 </effect>

 <!-- pitch -->
 <animation>
  <type>rotate</type>
  <property>orientation/pitch-deg</property>
  <factor>-1.0</factor>
  <center>
   <x-m>0</x-m>
   <y-m>0</y-m>
   <z-m>0</z-m>
  </center>
  <axis>
   <x>0</x>
   <y>1</y>
   <z>0</z>
  </axis>
 </animation>

 <!-- roll -->
 <animation>
  <type>rotate</type>
  <property>orientation/roll-deg</property>
  <factor>1.0</factor>
  <center>
   <x-m>0</x-m>
   <y-m>0</y-m>
   <z-m>0</z-m>
  </center>
  <axis>
   <x>1</x>
   <y>0</y>
   <z>0</z>
  </axis>
 </animation>

 <animation>
  <type>select</type>
  <condition>
   <and>
    <property>/sim/rendering/shaders/skydome</property>
    <!-- Having the altitude property here deselects the shadow for MP/AI models. -->
    <property>position/altitude-agl-m</property>
    <not>
     <property>/sim/rendering/rembrandt/enabled</property>
    </not>
   </and>
  </condition>
 </animation>

</PropertyList>


Systems/shadow-pr.xml, reference was set by trial and error - I suppose it offsets the zero-point of the gain filter but the response in the shadow effect didn't seem to agree:

Code: Select all

<?xml version="1.0"?>
<PropertyList>
 <filter>
  <type>gain</type>
  <gain>0.3048</gain>
  <input>/position/altitude-agl-ft</input>
  <reference>-20.0</reference>
  <output>/position/altitude-agl-m</output>
 </filter>
</PropertyList>


I can add more information and screenshots on request. (My daughter has run out of patience now, will be back later.)

[wlbragg]

(My daughter has run out of patience now, will be back later.)

Been there, just about every day!

What's sad is remembering back to when they used to ask YOU all the questions!

[Thorsten]

I can't spot anything obvious... Does the property itself (altitude-agl-m) change if you change pitch or roll but leave the CoG location in the same place (i.e. is the problem the property rule or what the shader does with it later)?

[AndersG]

I can't spot anything obvious... Does the property itself (altitude-agl-m) change if you change pitch or roll but leave the CoG location in the same place (i.e. is the problem the property rule or what the shader does with it later)?

In this aircraft altitude-agl-m, like altitude-agl-ft, is for the nose cone, as that is where the origin of the aircraft (FDM, 3d model, sound etc. subsystems) is.
The locally computed altitude-agl-m seemed to change "in tune" with the native altitude-agl-ft property.
[EDIT]My assumption about which point on the airframe the altitude-agl property represents is apparently not true - it appears to be the CG and not the origin. Will investigate this closer.[/EDIT]

Would it make the effect easier if the origin of the shadow model was already at the aircraft local ground level?
I do that for my portable patch of water (see http://github.com/andgi/FlightGear-MTB_20m).

Here is the sequence of animations I use for the water:

Code: Select all

 <animation>
  <type>translate</type>
  <object-name>Water</object-name>
  <property>fdm/jsbsim/hydro/height-agl-ft</property>
  <factor>-0.3048</factor>
  <axis>
   <x>0.0</x>
   <y>0.0</y>
   <z>1.0</z>
  </axis>
 </animation>

 <animation>
  <type>rotate</type>
  <object-name>Water</object-name>
  <property>orientation/roll-deg</property>
  <offset-deg>0.0</offset-deg>
  <factor>1.0</factor>
  <center>
   <x-m>0.00</x-m>
   <y-m>0.00</y-m>
   <z-m>0.00</z-m>
  </center>
  <axis>
   <x>1.0</x>
   <y>0.0</y>
   <z>0.0</z>
  </axis>
 </animation>

 <animation>
  <type>rotate</type>
  <object-name>Water</object-name>
  <property>orientation/pitch-deg</property>
  <offset-deg>0.0</offset-deg>
  <factor>-1.0</factor>
  <center>
   <x-m>0.00</x-m>
   <y-m>0.00</y-m>
   <z-m>0.00</z-m>
  </center>
  <axis>
   <x>0.0</x>
   <y>1.0</y>
   <z>0.0</z>
  </axis>
 </animation>
 <animation>
  <type>rotate</type>
  <object-name>Water</object-name>
  <property>orientation/heading-deg</property>
  <offset-deg>0.0</offset-deg>
  <factor>1.0</factor>
  <center>
   <x-m>0.00</x-m>
   <y-m>0.00</y-m>
   <z-m>0.00</z-m>
  </center>
  <axis>
   <x>0.0</x>
   <y>0.0</y>
   <z>1.0</z>
  </axis>
 </animation>

 <animation>
  <type>select</type>
  <condition>
   <and>
    <property>/sim/rendering/shaders/water</property>
    <greater-than>
     <property>environment/waves/amplitude-ft</property>
     <value>0.00</value>
    </greater-than>
    <less-than>
     <property>position/altitude-agl-ft</property>
     <value>100.00</value>
    </less-than>
   </and>
  </condition>
 </animation>



And, now that I copied them here I notice that I have the opposite order for the pitch and roll rotate animations than in the shadow.xml file.
I think that may well explain some part of the problem - I got the animations in shadow.xml from the ALS wiki page.
I'll change the order and try again.

[AndersG]

What's sad is remembering back to when they used to ask YOU all the questions!

Mine hasn't started to ask me questions yet, at least not spoken questions, but that time is probably not that far off.. :)

[AndersG]

OK, not much luck so far. That /position/altitude-agl-ft presumably is for the CG is a bit of a set back as that is a dynamic position and hence not a good reference point for animations (or shader effects, I suppose). Since (AFAIK[*]) the geographical position properties apply to the origin/FDM VRP it is odd that the altitude-agl property doesn't.

Using a variant of the JSBSim-side computation I used to compute the altitude offset for my water patch I think I at least got a consistent elevation of the shadow - with no offset the shadow is close to the ground (but still not intersecting it?). It computes the altitude above ground at the origin of the JSBSim structural frame, which for my aircraft is also the origin for the other FG frames of reference (and of the 3d shadow object).
(It should be possible and for this use preferable to do this with a property rule but I'm much less familiar with their syntax.)

What does the shader do with this altitude information? It must be used for computing the vertical and lateral displacement - but what is its default expectation w.r.t. the shadow object?

Code: Select all

<?xml version="1.0"?>
<system name="shadow">

 <channel name="shadow">

  <fcs_function name="tmp/shadow/height-agl-m">
   <documentation>
    Distance between the visual reference point and the ground surface.
    Possibly not completely correctly computed yet.
   </documentation>
   <function>
    <product>
     <value>0.3048</value>
     <sum>
      <property>position/h-agl-ft</property>
      <product>
       <value>-0.083333333</value>
       <difference>
        <value>0.00</value>
        <property>inertia/cg-x-in</property>
       </difference>
       <sin>
        <property>attitude/pitch-rad</property>
       </sin>
      </product>
      <product>
       <value>0.083333333</value>
       <difference>
        <value>0.00</value>
        <property>inertia/cg-z-in</property>
       </difference>
       <cos>
        <property>attitude/pitch-rad</property>
       </cos>
      </product>
     </sum>
    </product>
   </function>
   <output>/position/altitude-agl-m</output>
  </fcs_function>

 </channel>

</system>


[*] My airship mooring masts would not have worked if they didn't.

[Thorsten]

What does the shader do with this altitude information? It must be used for computing the vertical and lateral displacement - but what is its default expectation w.r.t. the shadow object?

It starts by establishing the 'up' direction relative to the terrain (assumed to be flat) underneath - for this it needs pitch and roll information because otherwise 'up' is always in model coords. Then it squishes the volume down to the given ground level, not quite flat (to avoid z-fighting) but reducing the z-extension quite drastically. Then it does the (xy)-displacement along the light direction. And finally it uses the ModelViewProjectionMatrix to get everything into the screen space used by the fragment shader. Here's the relevant part of shadow-vol-ALS.vert:

Code: Select all

//prepare rotation matrix
   mat4 RotMatPR;

   float _roll = roll;


   if (_roll>90.0 || _roll < -90.0)
   {_roll = -_roll;}
   float cosRx = cos(radians(_roll));
   float sinRx = sin(radians(_roll));
   float cosRy = cos(radians(-pitch));
   float sinRy = sin(radians(-pitch));

   rotationMatrixPR(sinRx, cosRx, sinRy, cosRy, RotMatPR);


    // project the shadow onto the ground
    vec4 vertex =   RotMatPR * gl_Vertex;
    vec4 pos = vertex;
    pos.z = -0.9* alt_agl + 0.05 * vertex.z;


    pos.xy -= lightFull.xy * 0.95* (alt_agl + vertex.z + gear_clearance)/lightFull.z;


   
    gl_Position =  gl_ModelViewProjectionMatrix * pos;

That /position/altitude-agl-ft presumably is for the CG is a bit of a set back as that is a dynamic position and hence not a good reference point for animations (or shader effects, I suppose).

I'm not sure what you mean. The shader doesn't deal with animations right now (because technically they end up in gl_ModelViewProjectionMatrix, and to include the shadow of animations, the computation would have to be done in eye space in which the 'up' direction depends on where you are currently looking at, which makes the math really ugly). But pitch and roll movements should be around the CoG, so if the shadow is supposed to be projected onto the ground regardless of the aircraft's current pitch and roll, then the CoG is the correct reference point, because all others would change with pitch or roll.

I think that's part of the issue, that your visual reference point which you want to forward to the shader is not at the center of the pitch and yaw rotations, which is why you have to use pitch and yaw information in your fcs_function computation.

(It should be possible and for this use preferable to do this with a property rule but I'm much less familiar with their syntax.

Has a fairly similar range of basic operations, but JSBSim is just fine for the job.

Would it make the effect easier if the origin of the shadow model was already at the aircraft local ground level?

[/quote]

Not really... it's just one offset after all.

[AndersG]

That /position/altitude-agl-ft presumably is for the CG is a bit of a set back as that is a dynamic position and hence not a good reference point for animations (or shader effects, I suppose).

I'm not sure what you mean. The shader doesn't deal with animations right now (because technically they end up in gl_ModelViewProjectionMatrix, and to include the shadow of animations, the computation would have to be done in eye space in which the 'up' direction depends on where you are currently looking at, which makes the math really ugly). But pitch and roll movements should be around the CoG, so if the shadow is supposed to be projected onto the ground regardless of the aircraft's current pitch and roll, then the CoG is the correct reference point, because all others would change with pitch or roll.

I think that's part of the issue, that your visual reference point which you want to forward to the shader is not at the center of the pitch and yaw rotations, which is why you have to use pitch and yaw information in your fcs_function computation.

The shadow model has animations to "un-roll" and "un-pitch" it (which I got from the ALS wiki page) and it is (like you also say above) important that these rotations are round the same location as the altitude is reported for - else roll and pitch changes the altitude of the shadow - which was one of the problems I had. It can be solved either by moving the centre of the rotations for the shadow model to the location the altitude is reported for or by computing the altitude for the location where the rotations apply.

Now, since /position/altitude-agl-ft apparently reports the altitude for the CoG it is natural to rotate the shadow object around the CoG, but I had assumed that /position/altitude-* was for the origin of the aircraft for years, since the latitude and longitude properties are for the origin and it seemed natural that all properties in /position/ spoke about the same location in space... :)

But why, IMO, is then the CoG not the best reference point? That's because it is not fixed in the airframe - it moves when the payload and fuel changes (up to 1.5 meters fore-aft for the ZLT-NT and most likely more for Nordstern, but that is still relatively small, though). Consequently the rotations done on the shadow model will only be approximately about the CoG and there will be some small altitude variations for the shadow. It probably doesn't matter in practice.

I think this part of my problems have been solved now.

What remain to figure out are
i) some view point and direction related problems where part of the shadow disappears and reappears based on the view point and direction in external views (helicopter, chase). It could be z-clipping but doesn't quite look like it; and
ii) that the shadow is sometimes (usually in flight) invisible from internal views - and this happens even when the view point is move outside any windows.

The latter could again be related to the view point and direction since these are not the same for internal (look from) and exterior (look at) views. I'll try to create some screenshots that show the problems.

[EDIT]
Here are two sets of screenshots (from KNUQ) showing issues:

i) The shadow is clipped (or not) when rotating the external view: http://www.gidenstam.org/users/anders/FlightGear/screenshots/fgfs-NT-308.jpg and http://www.gidenstam.org/users/anders/FlightGear/screenshots/fgfs-NT-309.jpg. When the view is rotated close to the ground to view the shadow edge on it appears to be well above the ground.

ii) The shadow is visible in the external view but not at all in the internal view (the simulation was paused and I tried to get a similar view direction): http://www.gidenstam.org/users/anders/FlightGear/screenshots/fgfs-NT-312.jpg and http://www.gidenstam.org/users/anders/FlightGear/screenshots/fgfs-NT-313.jpg. I also have one example where the shadow is partially visible from the internal view.
[/EDIT]

[Thorsten]

i) The shadow is clipped (or not) when rotating the external view: http://www.gidenstam.org/users/anders/F ... NT-308.jpg and http://www.gidenstam.org/users/anders/F ... NT-309.jpg. When the view is rotated close to the ground to view the shadow edge on it appears to be well above the ground.

This sure smells like the same problem.

* if you push the shadow too close to the ground, you get distance-dependent z-fighting or simply clipping - at larger distance, numerical accuracy for the z-buffer apparently isn't that great any more. The shader code tries to balance that by increasing the offset from the ground with the altitude used in the projection, but of course there are viewpoints for which this is rather apparent.

* If you offset the shadow too much, it floats too visible above the terrain

* if you squish the shadow too flat, you get z-fighting with itself

So dependent on graphics card (the numerical accuracy is architecture dependent), view position and aircraft altitude you get a different optimum unfortunately.

Consequently the rotations done on the shadow model will only be approximately about the CoG and there will be some small altitude variations for the shadow.

JSBSim knows the CoG position though, so is it not possible to use this point as the center for the rotation animations if the offset is really an issue? Admittedly the airship is much larger than anything I've tested so far.

The latter could again be related to the view point and direction since these are not the same for internal (look from) and exterior (look at) views. I'll try to create some screenshots that show the problems.

The thing is that the shader doesn't know about any of that - it just knows the eye position, the sun position and the vertex position and a couple of matrices to go into eye and screen space. So I can't see how conceptually the shader would recognize an internal view as different from an external view. Must be something else.

Can I pull the current state you used to make the screenshots from FGAddon?