FSXA 3D Landing Lights?

[Heretic]

Thanks, Bill!

I didn't like any of the "Beacon" .fx files, so I wrote my own controller script for the Beacon which allows me to "illuminate" the glass cover and the "light bulb" nicely:

I'll be right back; modeling a beacon...

 

[n4gix]

Just be clear, I use the script I posted earlier to control:

1. visible "glass cover"
2. visible "light bulb"
3. some "nav red" .fx file

 

[lionheart]

Goodness......!

You two have really taken this to the very far next step, lololol...

 

[n4gix]

Goodness......!

You two have really taken this to the very far next step, lololol...

Wait until the C310R is released. How about continuously variable, zoned 3d gauge backlighting, controlled by a simple 64x64pixel XML "gauge!"

 

[Heretic]

Just be clear, I use the script I posted earlier to control:

1. visible "glass cover"
2. visible "light bulb"
3. some "nav red" .fx file

Ah. I thought you didn't use a .fx file at all.

Still thinking about the best way to MODEL the beacon effect.

Goodness......!

You two have really taken this to the very far next step, lololol...

With FSX, my impression is that there's no "if"s...just "how"s.

 

[n4gix]

Ah. I thought you didn't use a .fx file at all.

Still thinking about the best way to MODEL the beacon effect.

Re-read what I actually wrote. I've never found a beacon .fx file that I liked. What I did do is create a clone of the glass cover and the light bulb, added a red bit of texture, self-illuminated with the same texture and a bit of transparency, then control it with my XML visibility script.

I liked the result, but still wanted just a tiny bit of the "starburst rays," so I created a custom navred_smallbeacon.fx file to add that tiny bit more...

I've also created custom nav and strobe .fx files that include a "ground splash" for use only when the a/c is on the ground. When airborne, the "ground splash" instantly disappears...

 

[Heretic]

Re-read what I actually wrote. I've never found a beacon .fx file that I liked. What I did do is create a clone of the glass cover and the light bulb, added a red bit of texture, self-illuminated with the same texture and a bit of transparency, then control it with my XML visibility script.

I liked the result, but still wanted just a tiny bit of the "starburst rays," so I created a custom navred_smallbeacon.fx file to add that tiny bit more...

I've also created custom nav and strobe .fx files that include a "ground splash" for use only when the a/c is on the ground. When airborne, the "ground splash" instantly disappears...

Okay, that sounds good.

Now I need to learn doing .fx files. Hopefully the SDK document can help me in that regard.

 

[Heretic]

Lesson learned while doing other stuff: Never ever attach an attachpoint dummy to something.

My customized beacon.fx and the stock one now show up properly.

The glass effect with Bill's XML code works as well.



- Edit: Why do effects attached in Max/GMax lose their "illuminating" abilities?

- Edit: Just for clarification, Bill...did you use two separate .fx files for the beacon, say one for the "super nova" and one for the ground splash?

 

[n4gix]

- Edit: Just for clarification, Bill...did you use two separate .fx files for the beacon, say one for the "super nova" and one for the ground splash?

I've done it both ways, but honestly it's actually easier to simply draw the "ground splash" (GS) as the last [Emitter.n] section in the .fx file. Obviously, the same technique will apply to nav lights as well as the beacon. By having two versions of the same .fx file (one with GS and the other without) means you have an easier time with on/off ground control!

Here's the GS entry for the strobeGS.fx file. Note the [Particle.n] entries in red below.

The X Scale= and Y Scale= entries define the diameter of the GS.

The Ground Normal=1 entry "flattens the effect to be parallel to the ground"

The Y Offset= entry is set to offset the "GS" to be just barely above the ground. This needs to be just high enough that it won't sink into the ground when the a/c is fully loaded to the max pax and fuel!

[Emitter.5]
Lifetime=0.00, 0.00
Delay=0.30, 0.30
Bounce=0.00
No Interpolate=1
Rate=0.50, 0.50
X Emitter Velocity=0.00, 0.00
Y Emitter Velocity=0.00, 0.00
Z Emitter Velocity=0.00, 0.00
Drag=0.00, 0.00
X Particle Velocity=0.00, 0.00
Y Particle Velocity=0.00, 0.00
Z Particle Velocity=0.00, 0.00
X Rotation=0.00, 0.00
Y Rotation=0.00, 0.00
Z Rotation=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=0.00, 0.00
Z Offset=0.00, 0.00
Pitch=0.00, 0.00
Bank=0.00, 0.00
Heading=0.00, 0.00

[Particle.5]
Lifetime=0.01, 0.01
Type=19
X Scale=1.50, 1.50
Y Scale=1.50, 1.50
Z Scale=0.00, 0.00
X Scale Rate=0.00, 0.00
Y Scale Rate=0.00, 0.00
Z Scale Rate=0.00, 0.00
Drag=0.00, 0.00
Color Rate=0.00, 0.00
X Offset=0.00, 0.00
Y Offset=-1.70, -1.70
Z Offset=0.00, 0.00
Fade In=0.00, 0.00
Fade Out=0.00, 0.00
Rotation=0.00, 0.00
Ground Normal=1
Static=1
Face=0, 0, 0

[ParticleAttributes.5]
Blend Mode=2
Texture=fx_2.bmp
Bounce=0.00
Color Start=40, 40, 40, 200
Color End=45, 45, 45, 0
Jitter Distance=0.00
Jitter Time=0.00
uv1=0.00, 0.00
uv2=0.50, 0.50
X Scale Goal=0.00
Y Scale Goal=0.00
Z Scale Goal=0.00
Extrude Length=0.00
Extrude Pitch Max=0.00
Extrude Heading Max=0.00

 

[Heretic]

Thanks for the code. I got a ground splash .fx working last night already, but I couldn't get it to show up on the model yet.

I've spent the major part of last night trying to get the beacon effect to flash synchronously with the "glass". It wasn't until I shut off the PC that I realized that you can just make the effect itself static and use your XML code to make it flash instead of painfully trying to sync the the "rate" and "lifetime" values of the .fx to the flashing glass.

Oh well, at least the effect is working properly now...


Next thing on the list is the taxi lights. I'm in for ton of fun there, since the light splashes will have to work exactly like the ones from the landing light (counter roll, pitch and account for distance) and aditionally have get switched off once the nose gear extends/retracts as well as moving along with the nose lights. Jon said in his lights tutorial that the pitch and roll thingies have to be at the root level of the hierarchy. Could that be a problem?

Also, I want to make my light beams dependent on the time of day, say full intensity at night and partial or none at dusk/dawn. This means a LOT of new XML code, which brings me to my next (rhetorical) question...

You can remove unused entries from the modeldef.xml, right?

 

[n4gix]

...I realized that you can just make the effect itself static and use your XML code to make it flash instead of painfully trying to sync the the "rate" and "lifetime" values of the .fx to the flashing glass.

Oh well, at least the effect is working properly now...

Well, I did mention that I used a version of the navred.fx file instead of one of the beacon.fx file(s).

Next thing on the list is the taxi lights. I'm in for ton of fun there, since the light splashes will have to work exactly like the ones from the landing light (counter roll, pitch and account for distance) and aditionally have get switched off once the nose gear extends/retracts as well as moving along with the nose lights. Jon said in his lights tutorial that the pitch and roll thingies have to be at the root level of the hierarchy. Could that be a problem?

Honestly, after a LOT of thought, I realized that the "pitch and roll thingies" aren't at all necessary nor particularly desirable. After all, the sealed beam sources are fixed in place and don't change pitch or roll with the aircraft, so why on earth would the ground splashes do so?

Also, in real life one simply cannot "see" the landing or taxi lights on the ground at much above 1500' so what use is there to make it more complicated than necessary?

Regarding the taxi light "steering with the nosewheel," here's a tip on that. Create a clone of your animated c_wheel node just for the taxi lights and do not Link it in with the gear retraction! Instead Link that node to the fuselage or some other non-animated object. It will still "rotate" with the nosegear, but won't have it's animation screwed up...

I found that trying it that way caused the "taxi light poly(s)" to race ahead of the "landing light poly(s)" at roughly twice the speed... IOW, having them Linked to the c_gear node FUBARed the bone animation track...

Also, I want to make my light beams dependent on the time of day, say full intensity at night and partial or none at dusk/dawn. This means a LOT of new XML code, which brings me to my next (rhetorical) question...

You can remove unused entries from the modeldef.xml, right?

Of course. Actually, I think for my next project I'm going to take an entirely new approach to modeldef.xml...

I'll rename my current modeldef.xml file to ORG_modeldef.xml, and then create an "empty" modeldef.xml file and only copy/paste from ORG_modeldef.xml what I need for the current project. My current modeldef.xml is really too long and clumsy with some 58,000+ lines of script!

When I've finished up the model, I'll rename the file to MyProjectName_modeldef.xml and zip it up with the final .max or .gmax files and master PSD files for archival purposes...

 

[Heretic]

Well, I did mention that I used a version of the navred.fx file instead of one of the beacon.fx file(s).

Ah. Well, I'll have to investigate.

Honestly, after a LOT of thought, I realized that the "pitch and roll thingies" aren't at all necessary nor particularly desirable. After all, the sealed beam sources are fixed in place and don't change pitch or roll with the aircraft, so why on earth would the ground splashes do so?

Maybe to account for the "cylindrical" light splashes?

Granted, the compensation effect is subtle at best, yet I say it becomes all the more necessary the farther the lights are away from the COG. While nose gear mounted taxi lights won't have to account for roll, they'll have to account for pitch and vice versa for wing mounted landing lights.

The MD-8x is a good example for mounting lights way off center.

I'll probably leave the roll compensation out for the taxi lights.

Also, in real life one simply cannot "see" the landing or taxi lights on the ground at much above 1500' so what use is there to make it more complicated than necessary?

I calculated really well then I guess. My landing lights become visible at 1600ft.

Regarding the taxi light "steering with the nosewheel," here's a tip on that. Create a clone of your animated c_wheel node just for the taxi lights and do not Link it in with the gear retraction! Instead Link that node to the fuselage or some other non-animated object. It will still "rotate" with the nosegear, but won't have it's animation screwed up...

I found that trying it that way caused the "taxi light poly(s)" to race ahead of the "landing light poly(s)" at roughly twice the speed... IOW, having them Linked to the c_gear node FUBARed the bone animation track...

Do you mean directly linked to c_gear or linked to c_wheel (which is a child of c_gear, at least on my model)?

I'll keep that in mind 'though.

Of course. Actually, I think for my next project I'm going to take an entirely new approach to modeldef.xml...

I'll rename my current modeldef.xml file to ORG_modeldef.xml, and then create an "empty" modeldef.xml file and only copy/paste from ORG_modeldef.xml what I need for the current project. My current modeldef.xml is really too long and clumsy with some 58,000+ lines of script!

When I've finished up the model, I'll rename the file to MyProjectName_modeldef.xml and zip it up with the final .max or .gmax files and master PSD files for archival purposes...

After some 30 painful minutes of editing and reverting last night I've settled for some comment lines and more empty lines in my modeldef.xml.

Actually, regarding the actual simplicity of adding new stuff to the modeldef, a small editing tool would be handy.
You'd just have to fill in a name for the entry, check whether you want to have an animation or visibility entry or both, enter the animation length into a small box and your code in the appropraite fields and choose an animation group.
The tool then generates a new GUID for the animation all on its own, puts the entry into the desired group and writes them into the new modeldef.

*Sigh*...life would be so much simpler...

Maybe Arno has got a few hours to spare...

 

[n4gix]

I have two c_wheel nodes, one is Linked to c_gear as normal and all the usual stuff is also Linked in that hierarchy.

The second c_wheel_01 node is Linked to the fuselage and simply provides a pivot for the Linked bones of the 3d taxi lights. This allows the 3d polys to turn with the wheel, without the animation of the c_gear screwing up the bone's animation.

On reflection, I can see some benefit to the anti-roll animation for larger aircraft. For the C310 though it would have been overkill...

 

[Heretic]

*Bump*

Thanks Bill, your method for the nose gear node works perfectly! The NLG lights now turn with the wheels *and* pitch gets accounted for.


Now my next achieverment...the beacon light splash on the ground.
With my incredible XML coding skills (haha!) I've managed to put the airplane weight into the mix, so the splash always stays on the ground, no matter how heavy (well, MTOW is the limit) or light it is.

MTOW:


Empty:


If there's interest in the XML code, I'll gladly post it.

 

[Jakes]

Anyways, I found Bill L.'s "illuminate stuff" (ramp)lights a seemingly easier solution.

Where can I find this?

 

[Flying Officer Jevans]

Look in the 33MO Leaming Field WIP in the showroom forum.

 

[Jakes]

Look in the 33MO Leaming Field WIP in the showroom forum.

Thank you very much!

 

[n4gix]

*Bump*

Thanks Bill, your method for the nose gear node works perfectly! The NLG lights now turn with the wheels *and* pitch gets accounted for.

Now my next achieverment...the beacon light splash on the ground.
With my incredible XML coding skills (haha!) I've managed to put the airplane weight into the mix, so the splash always stays on the ground, no matter how heavy (well, MTOW is the limit) or light it is.
If there's interest in the XML code, I'll gladly post it.

You are most welcome!

Since my "ground splashes" are part of the Attach pointed .fx files, they automatically follow the a/c's weight-compression, but I am always interested in new ideas! Post away!

It might just be that it finds a permanent home in FFDS's "Working XML..." forum.

 

[Heretic]

Since my "ground splashes" are part of the Attach pointed .fx files, they automatically follow the a/c's weight-compression, but I am always interested in new ideas! Post away!

You know about my luck with the "attachpoint .fx" method...

It might just be that it finds a permanent home in FFDS's "Working XML..." forum.

I was thinking about just that, but I think it's rather useless without the material recipe.

Anyways, here it is. The "visibility" part might look familiar to you, Bill.

  <PartInfo>
    <Name>[Whatever you want to name this]</Name>
    <AnimLength>[Depends on what you've calculated; see below]</AnimLength>
     <Animation>
      <Parameter>
       <Code>
       (A:TOTAL WEIGHT, pounds)[COLOR="Red"] 1000 / 20 - 10 *[/COLOR] near (A:SIM ON GROUND,bool) *
       </Code>
      </Parameter>
     </Animation>
    <Visibility>
    <Parameter>
        <Code>(A:LIGHT BEACON,bool) 0 &gt; (A:ELECTRICAL MASTER BATTERY,bool)
          and (A:SIM ON GROUND,bool) 0 &gt; and (P:ABSOLUTE TIME,seconds) 1 % 0.6 > and if{ 1 } els{ 0 }
          </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

Note: You *will* have to adjust the computation formula marked in red so that you'll get an appropriate keyframe range. For my 328, I've trimmed the computation so that I'll get a number near zero at empty weight and near 100 at MTOW. I then positioned the splash according to those numbers. Trial and error your way around to position of the splash (I've experienced that adjusting it to gear height does not work neccessarily).

Material recipe:

Diffuse: 32,32,32 RGB
Specular: 32,32,32 RGB

Diffuse map: Your effects texture (white alpha).
Specular color: "
Self-illumination: "

Fresnel ramp: Texture with 32,32,32 RGB (?)
Tick "Specular"

Special Functionality: Blend Diffuse by inverse of specular map alpha

Specular power scale: 256

Allow Bloom

Source Blend: Src Color
Destination Blend: InvSrc Alpha

Emissive Mode: Additive

Tick: "No Shadow" and "Double Sided"

The mesh itself is a simple uvw-mapped plane; the effects texture looks similar to "fx2.bmp" (in colour) in my case.

 

[Heretic]

Just realized that my beacon has absolutely nothing to do with the thread title, lol.


Well, I think I'm done with those landing lights now. I finally want to implement the remaining, secondary lights (cockpit, cabin, wing inspection, logo, etc...).

I've managed to implement some kind of gradual intensity depending on the time of day.

If you look closely, you can see the difference at day. One of the sets of bones will *always* be active respecively once the taxi and landing lights are switched on.





At dusk, you'll get 'em in bright yellow at half or two thirds intensity for the landing and taxi lights respecively (which still makes for a powerful display):



At night, you'll get them in full glory:




The whole system is also applied to the landing light beams.

None at daytime.


One third intensity at dusk...


..and full intensity at night.



The landing light splashes may look weird but quite plausible if you keep the shape and setup of the 328's landing lights in mind.




Just for the record, the taxi lights. The beams look a bit weird from above.





And just for showing off, the red nav, white nav and stobes (and again, the beacon splash). All created in lengthy trail-and-error sessions to find the perfect method for having them bright in the day and at night.