v1.6.4 Conditional Visibility bug

#1
I believe there's a bug in the conditional visibility where if you do the shorthand placement (i.e. multiple placement entries in one simobject entry), environmental data probe-based objects do not react to the changing conditions. If you remove all but one placement without changing anything else, it works perfectly, and if you change it to a non-environmental data probe object, it again works perfectly.
 
#4
I have now created a little test case here with 1 EDP and 4 windsocks placed using the shorthand notation.
They all react to changes in wind speed and direction...
 
#5
Wonder if I'm doing it wrong - please could you post your test XML?

Thanks

EDIT: This is a sample of my XML. Like this, the lighting will come on and remain on, even though the wind speed is only between 30-40kts and the in-sim wind speed is 0kts. However making each of the 4 lights have its own condition works fine:

XML:
<SODE>
    <!-- Data Probe serving its clients -->
    <SimObject Name="XXXX">
        <Placement Lat="0.12345" Lon="0.12345" Alt="500" Hdg="0.0"/>
        <Model SimTitle="12bPilot_SODE_Environmental_Data_Probe">
            <EnvironmentalDataProbe ClientList="RwyLighting"/>
        </Model>
    </SimObject>
    <Group Name="RwyLighting">
        <ConditionalVisibility Variable="WindSpeed" Value="30-40" />
        <SimObject Name="white">
            <Placement Lat="0.56789" Lon="0.56789" Alt="0#AGL" Hdg="0"/>
            <Placement Lat="0.56788" Lon="0.56788" Alt="0#AGL" Hdg="0"/>
            <Placement Lat="0.56787" Lon="0.56787" Alt="0#AGL" Hdg="0"/>
            <Placement Lat="0.56786" Lon="0.56786" Alt="0#AGL" Hdg="0"/>
            <Model SimTitle="runwaylightwhitelight">
                <VariableDrivenRotation Variable="UserAircraftPosition" Mode="TURN"/>
            </Model>
        </SimObject>
    </Group>
</SODE>
Replacing the conditionalvisibility with a non-envprobe variable, for instance "<ConditionalVisibility Variable="TimeOfDay" Value="DUSK;NIGHT;DAWN" />" displays at the correct times of the day.
 
Last edited:
#6
Well, you've hit a limitation of the current SODE, which is the combination of the EnvironmentalDataProbe with grouped, multi-placed SimObjects. It just can't resolve the individual objects to hook them up to the data probe.

I have fixed that now for the next version, but you can overcome this by avoiding the group node. Just pull the CondVis tag into the SimObject's Model tag.

On a side note, I would not try to create the runway lighting like that for performance reasons. Placing each and every light like that (using the computation heavy VarDrivenRotation based in UserAircraftPosition -> evaluated every second frame!) will bring performance down for sure.

Always think of injecting an AI aircraft into the sim, so 100 individual lights means 100 AI aircraft basically, since that is what the SimConnect API offers -> injection of SimulatedObjects = AI objects.
It is much better to build a single model for all those lights. You can make the lights omnidirectional by using crossed polygons.
 
#8
I have fixed that now for the next version.
Thanks, do you know when the next release will be available or if there's a beta that I could take part in?

Placing each and every light like that (using the computation heavy VarDrivenRotation based in UserAircraftPosition -> evaluated every second frame!) will bring performance down for sure..
I'm running on an Intel i7 2600k (OC'd to 4.4GHz) and a NVidia 970 GTX (both of which I would consider old hardware now) with no framerate loss running at around 60FPS, all scenery sliders up max. The specific reason for doing them the way I have is due to the comination of using LODs and texture mipmaps to ensure visibility from miles out. When normal planes are used which don't follow the user, there's a flash of light at exactly 90 degrees when facing it due to the large plane used for the mip'd texture. I might try it as a flat "box" object so that the edges can still be mapped to the transparent part of the texture, but as I said there's no FPS loss on the 48 rotational-driven and additional 256-and-counting static objects being placed with SODE. Maybe I'm just lucky so far and it's going to run out soon?!
 
Last edited:
#9
Good to hear that there's not a huge FPS loss, I was just imagining a scenario with hundreds of such individual lights which is more computation heavy than a single model with hundreds of light polygons.

When normal planes are used which don't follow the user, there's a flash of light at exactly 90 degrees when facing it due to the large plane used for the mip'd texture
There is a solution to this: Fresnel Ramp. It is described in the Modeling SDK (FSX Materials). It's a small texture with an alpha channel that is added to your light material. In this case, you'd want to have the Fresnel map to affect the Diffuse map of your material.

fresnel.png


So when you are approaching the 90 degrees angle towards your flat light polygon, the polygon will get more and more transparent. This way, there will be no "flash" anymore when you are perpendicular to the light polygon. Also, this replicates somehow a real directional light, where the intensity falls off when you go "off axis".

I have attached my example Fresnel ramp map below. It's in PSD (Photoshop) format, feel free to modify it to your liking. It works pretty nice for lights already.

Now you can model your entire airfield lighting within gmax/max using that modified light material (incl. Fresnel Ramp) and use SODE to inject the single MDL.
 

Attachments

#10
Thanks Jeffrey, I'll give this a go!

I can also confirm that removing the grouping and putting the conditions on the model with multiple placements works perfectly.
 
#11
Ok the Fresnel ramp worked as expected...on the white part of the light. I had to change how I textured the lamps to take into account the Fresnel transparency, but on doing so, the red part of the light now has a white halo around it. My previous method of doing the lamps, using One/One had no such issue, but of course means no Fresnel ramp. I've spent about an hour checking the texture alpha channel for any abnormalities, the texture is DXT5 and there's a gradient fade out, but instead of going red->transparent, it goes red->white->transparent.

If anyone knows how to get rid of this white bit that'd be great, otherwise my box method with One/One will have to do.

EDIT: The box idea gives the same result of the "flash". Need to get the transparencies working.

EDIT2: Got the transparencies working. It was down to the Bloom settings in GMAX. So for my records and to help anyone else, this is for daytime and night-time lighting:

Diffuse and Self-Illumination - choose textures
Specular: White colour
Specular Level: 85
FresnelRamp: Choose texture and assign to Diffuse
Blend diffuse by diffuse alpha
Untick Allow Bloom and tick Allow emissive bloom
Set Default Transparent
Emissive Mode: Additive
Tick No shadow
All other options: defaults

The texture itself needs to be 2-bit alpha however (i.e. black or white). I've not yet got it working with 8-bit alpha as it still produces a white halo around the colour, but not to the extent with Bloom enabled. It also cannot be double sided!
 
Last edited:
Top