2D shadow on ground

[Thorsten]

Cub is ysim, c172p is jsbsim, does this effect work with jsbsim?

It works with anything that sets a property how far the gear is off the ground - it works with your home-made Nasal FDM if you like...

I've just ever tested the ec130, but your analysis seems plausible enough. I assumed that the properties would be fairly universal, but apparently they're not. A simple property rule aircraft-side should do the trick then... Alternatively, you can try how badly things look if we use /position/altitude-agl-ft in all cases (I assume that's universal???)

[wlbragg]

Alternatively, you can try how badly things look if we use /position/altitude-agl-ft in all cases

I came to the same conclusion and tried it, but it's not working, I am missing something.

Here is what I did.

shadow.eff

Code: Select all

//existing parameter
<alt_agl><use>/position/gear-agl-m</use></alt_agl>

//added parameter below
<jsb_alt_agl><use>/position/altitude-agl-ft</use></jsb_alt_agl>

 <uniform>
   <name>jsb_alt_agl</name>
   <type>float</type>
   <value><use>jsb_alt_agl</use></value>
  </uniform>


shadow-ALS.vert

Code: Select all

//I left the original uniform
uniform float alt_agl;

//added the new uniform
uniform float jsb_alt_agl;


I was going to try to use an if statement in the vert, but I wasn't sure of the syntax of catching a null uniform.
I wasn't sure if I could use something like if (!alt_agl) or (alt_agl==NULL)
My idea was to do something like

Code: Select all

//original was
pos.z-=0.95 * alt_agl-0.1;
pos.xy -= lightFull.xy * 0.95* alt_agl/lightFull.z;

//I was thinking something like this
float agl = alt_agl;
if (agl == NULL || agl == 0 || !agl) {
   agl = jsb_alt_agl*0.3048;
}
pos.z-=0.95 * agl-0.1;
pos.xy -= lightFull.xy * 0.95* agl/lightFull.z;


because I didn't get the results I expected I decided to try it on the Cub that I know was working using alt_agl. I used the most straightforward, simplistic way to make sure I was passing date correctly through the pipe.
That was simply

Code: Select all

uniform float jsb_alt_agl;

//and
pos.z-=0.95 * (jsb_alt_agl*0.3048)-0.1;
    pos.xy -= lightFull.xy * 0.95* (jsb_alt_agl*0.3048)/lightFull.z;


But this didn't put the shadow on the ground either. It stayed at the wheel base.

[wlbragg]

A simple property rule aircraft-side should do the trick then

After looking at how slow altitude-agl-ft update is, I don't think it would work very well anyway. I'll try the "property rule".

But now I am curious why I couldn't get altitude-agl-ft to work at all?

[wlbragg]

This can be fun when it works.

Here is how I did it. I used an Autopilot configuration I guess, bare in mind this is a first for me.

In c172p-detailed-set.xml I added

Code: Select all

<autopilot>
      <path>Aircraft/c172p/Systems/gearAGL.xml</path>
</autopilot>


I created gearAGL.xml

Code: Select all

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


If there is a better more efficient way to do this, please let me know.

The results




Thank you Thorsten for you help.

[AndersG]

After looking at how slow altitude-agl-ft update is, I don't think it would work very well anyway. I'll try the "property rule".

But now I am curious why I couldn't get altitude-agl-ft to work at all?

If altitude-agl-ft seems to update slowly in the property browser it might be a tied property that can't be listened to so instead it is polled at a lower rate - but the property will actually be updated for each frame or FDM iteration.
This might also explain why you have problems getting its value into the effect - the effect system might also rely on listeners to get updates (I don't know).

[Thorsten]

This might also explain why you have problems getting its value into the effect - the effect system might also rely on listeners to get updates (I don't know).

Yes - you can't pass tied properties to effects. Learned that one the hard way (took me a while to figure out...) That's probably the problem here as well. Okay, then we need an aircraft-side property rule in any case.

I plan to write a documentation on how to implement the effect to the wiki eventually, but feel free to beat me on it (should go to the ALS technical notes).

Here is how I did it. I used an Autopilot configuration I guess, bare in mind this is a first for me.

It doesn't need to be AP (they're updated at FDM rate), we only need it at framerate. I vaguely remember there was a catch that you had to give an index to airplane-side property rules to avoid overriding the system-wide which do e.g. weather - there's documentation on the wiki somewhere, I think in the AP howto.

[wlbragg]

It doesn't need to be AP (they're updated at FDM rate), we only need it at framerate. I vaguely remember there was a catch that you had to give an index to airplane-side property rules to avoid overriding the system-wide which do e.g. weather - there's documentation on the wiki somewhere, I think in the AP howto.

Your memory is sound. Yes, the index needs to be 100=+ to avoid overwrite of system reserved. Yes, AP how to wiki explains both methods. I figured the faster the better. I'll try the framerate version today and see if that works as well.

[wlbragg]

it might be a tied property

I think that's it. It's all in the details.
That also explains why I could effectively use the same prop in a property rule.

[wlbragg]

OK, for frame rate level property rule

Aircraft/c172p/c172p-detailed-set.xml (about LINE 120) add

<autopilot>
<path>Aircraft/c172p/Systems/gearAGL.xml</path>
</autopilot>

changes to this (I used n="101" because c172p-detailed-set.xml already has rule using 100)

Code: Select all

<property-rule n="101">
       <name>gear_agl-m</name>
       <path>Aircraft/c172p/Systems/gearAGL.xml</path>
</property-rule>

[wlbragg]

My son caught me working on these "cheap" shadows and informed me of what might be considered the next level up but still relatively cheap.

I guess in Source they use a duplicate 3d model that they flatten and grey out on the fly, projection based on the sun ray angle. It's kind of like what were doing here except because they take the z out of the model on the fly they can get the morphing of the shadow based on the sun angle.
Does that make any sense?
Does it sound practical and cheap enough?

[Thorsten]

I guess in Source they use a duplicate 3d model that they flatten and grey out on the fly, projection based on the sun ray angle. It's kind of like what were doing here except because they take the z out of the model on the fly they can get the morphing of the shadow based on the sun angle.

It hadn't occurred to me to do it that way. If you're willing to send a duplicate model mesh down the line, there's a technique called 'shadow volumes' where you extrude the duplicate mesh to define a volumetric region in which the shadow is and then use stencil buffer passes to check whether a pixel is inside that volume, but I've shied away from that, it requires some C++ work I think.

To simply squish the model and grey it is of course easier (almost trivial given what we have). I think the main advantage for the current way of doing it is that it gets a free ride on the existing attempts to do fake shadows by translation animation (actually, I think you shouldn't comment out the translation, you should make it conditional based on ALS being off), so we're not asking aircraft developers to do yet another thing, but just add a few additional lines.

I have an inkling using a duplicate model can be misused - some of the models are really detailed, so we'd have a lot of additional vertices which we actually don't need and which just drag things down - what would work best would be a simplified 3d model, but that's a lot of work in a way. Not sure it's worth the effort.

[wlbragg]

actually, I think you shouldn't comment out the translation, you should make it conditional based on ALS being off

Good idea. I'll add it to the c172p and change the wiki accordingly.

some of the models are really detailed ........Not sure it's worth the effort.

I agree with that.
I thought it was an interesting concept, but to do it most efficiently I guess it would require some extra effort for the little gain of having a more realistic shaped shadow. It would be interesting to see it in action though.

[wlbragg]

After setting up two separate aircraft with the simplified shadow effect, here is what I found to work best.

Simply put I used a property rule for for both YSim and JSBSim aircraft and override gear-agl-m with a filter passing altitude-agl-ft to gear-agl-m in both aircraft.

The reason for this is to accommodate all the shadow AGL adjustment needed for both ASL-shadows and non-ALS-shadows.

Here is how it worked best.

My Cub has two configurations for tire size and thus two different altitude-agl-ft starting points. The c172p also has its own altitude-agl-ft starting point. I guess they would be dependent upon where and how the model designer created the center point of the aircraft.

To accommodate this variability you need to do an offset in the shadow.xml to place the shadow's AGL where you want it. But when using ALS-shadow method it has a tendency to put it where it thinks it needs to go based on the hard code.
So you use the offset to position the initial shadow.

Code: Select all

<offsets>
   <z-m>1.85</z-m>
</offsets>


Then you use the property rule configuration to position the shadow when ALS method takes control of the shadow's AGL

Code: Select all

   <filter>
   <type>gain</type>
   <gain>0.3048</gain>
   <input>/position/altitude-agl-ft</input>
   <reference>4</reference>
   <output>/position/gear-agl-m</output>
</filter>


Here is what worked for the three different aircraft configurations (one c172p config and two Cub configs)
c172p

Code: Select all

<z-m>1.85</z-m>
and
<reference>4</reference>


Cub

Code: Select all

<z-m>1.85</z-m>
and
<reference>4</reference>


CubOS

Code: Select all

<z-m>1.65</z-m>
<pitch-deg>-3.2</pitch-deg>
and
<reference>4</reference>


The condition for the translate switch between ALS-shadow and non-ALS-shadow is as follows.

Code: Select all

<!--Translate to ground level  -->
  <animation>
   <type>translate</type>
   <object-name>shadow</object-name>
   <condition>
    <equals>
      <property>/sim/rendering/shaders/skydome</property>
      <value>false</value>
    </equals>
   </condition>
   <property>/position/altitude-agl-ft</property>
   <factor>-0.3048</factor>
   <center>
     <x-m>0</x-m>
     <y-m>0</y-m>
     <z-m>0</z-m>
   </center>
   <axis>
     <x>0</x>
     <y>0</y>
     <z>1</z>
   </axis>
 </animation>


This configuration worked equally well on all three aircraft configurations.

LATE EDIT:
The condition also can be configured using "not"

Code: Select all

<condition>
    <not>
      <property>/sim/rendering/shaders/skydome</property>
    </not>
</condition>


this was what I finally ended up using.

[Thorsten]

I think if you want to work from a duplicate model, you'll need to change this

Code: Select all

// project the shadow onto the ground
    vec4 pos = gl_Vertex;
    pos.z-=0.95 * alt_agl-0.1;
    pos.xy -= lightFull.xy * 0.95* alt_agl/lightFull.z;

    // enlargen the shadow for low light
    if (dot(pos.xy, lightHorizon.xy)<0.0)
   {
   pos.xy -= lightFull.xy * gear_clearance/lightFull.z;
   }


into something like this

Code: Select all

   ec4 pos = gl_Vertex;
    pos.z= -0.95 * alt_agl+0.1;
    pos.xy -= lightFull.xy * 0.95* alt_agl/lightFull.z;


and make the model semi-transparent textured (the fragment shader uses the alpha value of the shadow texture to determine where it's dark...) and I suspect it would work.

[wlbragg]

I can report some success in our experiment. Unfortunately I am not a model maker and I am floundering with that portion of the task.
The best I could do was to take the AI Cub model and renamed every object in it "shadow" and made the texture transparent. I got results and was able to tell we are on the right track. But what I really need is a one piece, 3d, low poly model.
So then I tried the c172 AI model and basically did the same to it thinking it was a lower poly count and might work better.
Some screen shots to analyze.
Again, I'm not sure if it's the math or the model giving these results.