Visibility conditions in scenery objects (FSX)

#1
Hello,

I am trying to design a couple of night lights that produce a visible light beam at night for FSX. The light beam is made simply as a textured cone with alpha transparency.

My problem is to make the beam disappear during the daytime.

I tried to add a visibility condition via ModelDefs.xml first:

Code:
(E:TIME OF DAY,enum) 2 >= if{ 1 } els{ 0 }
However, it doesn't seem to work when I put the object into the scenery - the part is always visible. The visibility condition works correctly if I use the same MDL file as an aircraft model - so I don't think it is a mistake on my part.

Another thing I tried was to use a fully transparent texture for the beam and then illuminate it at night using a lightmap. But it appears that lightmaps do not illuminate transparent parts of the main texture. In other words, the alpha channel from the lightmap is ignored.

If I compile the object in the FS9 format, I can get conditions to work, but the light cone is not illuminated at night in the DirectX 10 mode (I understand this is a common problem with all FS9 models).

Is there any other way to make a part appear only during a certain time of the day, maybe using BGLCOMP? Or am I doing something wrong?

Help please!
Thanks!!!
 

n4gix

Resource contributor
#2
If you are designing strictly for FSX, check out my "33MO - Leaming Field" threads in the Showcase forum, which has a mini-tutorial for a helo/ramp 3d light. You will find the "recipie" for the FSX Materials described in detail.
 
#3
Works like a charm, thanks!!!

For the bright light beam in the air, I changed the source blend from DestColor to SrcColor, since DestColor tended to exaggerate details behind the beam.

One question: Does the color of the diffuse bitmap affect anything? Your tutorial mentioned it affecting the color of the lightsplash, but I didn't see any effect on it (I could change the color of the lightsplash by modifying the color of the specular/self-illumination bitmap).
 

n4gix

Resource contributor
#4
Works like a charm, thanks!!!

For the bright light beam in the air, I changed the source blend from DestColor to SrcColor, since DestColor tended to exaggerate details behind the beam.

One question: Does the color of the diffuse bitmap affect anything? Your tutorial mentioned it affecting the color of the lightsplash, but I didn't see any effect on it (I could change the color of the lightsplash by modifying the color of the specular/self-illumination bitmap).
Well, it used to change the color. Now it actually seems to do nothing at all except occupy a slot in the FSX Material editor to keep the compiler happy... I'm not sure what may have changed in the 'recipie' at this point... :eek:

I'm still experimenting myself to get the most out of this method. I'll have to try changing the source blend myself.

BTW, one trick I've found that will minimize the gradient banding is to treat the entire light wash to a bit of Texturizing using of all things the absolute minimum of "sandstone" (Scaling 50%, Relief 1%)
 
#5
Well, it used to change the color. Now it actually seems to do nothing at all except occupy a slot in the FSX Material editor to keep the compiler happy... I'm not sure what may have changed in the 'recipie' at this point... :eek:
Could it be that it only changed the color before you introduced the specular bitmap?

My understanding of how the recipe works is this:

First of all, the diffuse texture is applied. Because of the Blend diffuse by inverse of the specular map alpha setting, the alpha channel gets completely transparent.

Next, the specular texture is applied. Since you used an entirely black Fresnel map, there are no specular effects and nothing shows up. The only reason to have a specular texture is to use its alpha channel to hide the diffuse texture.

Finally (at night) the lightmap texture is applied. It is probably added to the darkened diffuse texture. This results in a relatively bright texture, but still with a completely transparent alpha channel.

The resulting textured polygon is drawn by combining its texture with the pixels "under" it according to the blend modes.

The source blend determines what happens to the pixels of the texture. DestColor means the pixels will be multiplied by the pixels already in the frame buffer - in this case, the unlit apron.

The destination blend determines what happens to the pixels already in the frame buffer (the unlit apron under our textured polygon). InvSrcAlpha means their value will be multiplied with the inverse of our texture's alpha channel. Since our alpha channel is transparent, its inverse is 1 and so original pixel values are kept.

The results of the source and destination blend are added together and written back to the frame buffer. For white pixels in our lightmap, both the source and destination blend produce the pixel value already in the framebuffer (unlit apron). So the combination will be twice as bright as the original unlit apron.

For black pixels in our lightmap, the source blend produces black pixels too (pixels in the framebuffer get multiplied by zero). The destination blend produces pixels already in the framebuffer, and so nothing changes.

During the day, the lightmap is not applied. This results in a black transparent texture which does not change anything when applied.

When you use SrcColor instead of DestColor for the source blend, existing pixel values are not multiplied by 2, but pixel values from the lightmap are added to them instead. This results in more brightness, but less contrast than the first method.
 

n4gix

Resource contributor
#6
That sounds reasonable. At one time the diffuse color was blended with the specular RGB, but I've likely turned it off somewhere while trying different combinations... :stirthepo :wizard:

There is one thing I've noticed and that is from >3000' altitude, there is some "flashing" of the specular occuring, even though it is supposed to be not only off, but invisible!

Here is my new tower at night, using my "Porch Light" for the ground light splash, as well as the overhead fixture (lighted of course). The wall splash of light is done in Photoshop for the lightmap texture.

Note the subtle lighting of the consoles, as well as the radar repeater overhead... :D

 
Last edited:
#7
There is one thing I've noticed and that is from >3000' altitude, there is some "flashing" of the specular occuring, even though it is supposed to be not only off, but invisible!
I see it too, during daytime. I think this has nothing to do with the specular, but with the blend mode destColor being used. It seems to write something into the framebuffer during the day that causes the flashing.

When using the blend mode srcColor, no such flashing occurs, but the surface in illuminated areas at night has less contrast (with this blend mode, you should use dark shades of gray for illuminated areas, and not full white).

There is also some flashing at night when viewed from a distance. It is caused by the limited z-buffer resolution and can be solved by raising illuminated areas a little. Maybe it would make sense to add two LODs to illimination objects - one for viewing from a distance, with a slightly raised polygon (to prevent flashing), and a different one for viewing when close, without the lighted area "floating" in the air.

I managed to get rid of the specular texture and the Fresnel ramp altogether. My new recipe has a fully black diffuse texture with a completely transparent alpha everywhere, and the same lightmap as before.

My new settings are:

  • Specify just a diffuse and a self-illumination texture.
  • Disable shadow.
  • Disable z-write (prevents airplane wheels from looking "sunk" into the light spot.
  • Blend diffuse with diffuse alpha (instead of inverse of specular map alpha before).
  • Same source and destination blend modes as before.

For me, it works exactly like before both at day and during the night.
 

n4gix

Resource contributor
#8
Thanks for the report back and the new "recipie." I'll give that a try myself and see what results are for me.

Actually, all of my "ground splash" polys are 0.25" above the ground to prevent z-fighting.

I've never been able to get LODs to work when compiling with XtoMDL.exe. AFAIK, LODs are "broken" in FSX. Likewise, conditional visibility via embedded XML doesn't work either...

...otherwise I could use "Time of Day" to switch the light polygons on/off as desired.

When using the blend mode srcColor, no such flashing occurs, but the surface in illuminated areas at night has less contrast (with this blend mode, you should use dark shades of gray for illuminated areas, and not full white).
...or, use fewer (perhaps no) stacked polygons. The only reason why I had two to three polys was to increase the brightness/contrast anyway.
 
Last edited:
#9
Never tried LODs with scenery objects, but they work just fine with aircraft MDLs. I know for a fact that most of the default scenery objects do have several LODs, but I never checked if they indeed work.

Conditional visibility doesn't work indeed.

Theoretically, you can add conditional polygons as special effects (they allow specifying the time of day), but effects are a PITA to install and there is a limit on the total number of effects active at the same time (IIRC, it is 200 effects with the Special Effects Low setting and 1000 effects with the Medium setting).
 

n4gix

Resource contributor
#10
Never tried LODs with scenery objects, but they work just fine with aircraft MDLs. I know for a fact that most of the default scenery objects do have several LODs, but I never checked if they indeed work.
Well, I'll be darned! I managed to get LODs to work!

Using:

Code:
HeloRamp_LOD_40
....HeloRampHousing
........Cone01
........Cone02
........Plane01
........Plane02
........Plane03
HeloRamp_LOD_10
....HeloRampHousing_01
The "ground splashes" disappear ~3500' AGL, which is about when they begin z buffer fighting with the ground polys.

It also takes care of them showing up during the daytime!

The trick I discovered is that -before LODs will work- one must "Populate the LODs" using the silly button on the "LOD Name Tool..."

...which of course isn't mentioned at all in the SDK... <sigh> :banghead:

I changed the "in air beam" to a 1/2 cone, which I very carefully shaped, scaled, and UVW Mapped. Here's a shot from the tower to the NE Ramp at 33MO... :wizard:

 

n4gix

Resource contributor
#12
Wow... love that light cone!
Thanks! The diagonal "square box" just wasn't cutting it. The straight edges couldn't be masked and/or feathered very well.

I've got a few more ideas I'm going to try out later today to see if I can't sweeten it up a bit more, but I really need to move on to some other parts of 33MO that still need the "loving touch..." :idea:
 
Top