Self Illumination and the new service pack

[Guest fbnweoghnwd]

I just installed SP1a, and I can now get objects to self-illuminate correctly, at all times of day. But I still can't get gauges in the VC to do the same. I've got a low fuel warning light and a clutch light - both borrowing the code from the default R-22 - that don't self illuminate when the sun is low in the sky. I tried assigning "Additive" and "User controlled Additive" emmissive modes to the gauge polys, but no dice.-Mick

[n4gix 4,947]

>>I just installed SP1a, and I can now get objects to>self-illuminate correctly, at all times of day. But I still>can't get gauges in the VC to do the same. I've got a low fuel>warning light and a clutch light - both borrowing the code>from the default R-22 - that don't self illuminate when the>sun is low in the sky. I tried assigning "Additive" and "User>controlled Additive" emmissive modes to the gauge polys, but>no dice.>>-MickAdditive Mode is the only one which will provide "backlighting" 24/7 as long as battery power is available.In the gauge itself are the bitmaps flagged to use "BRIGHT"?For all other gauge polys, you can use the new "MultiplyBlend" and/or "MultipyBlendUserControlled" modes and "paint" the illumination on a lightmap (if assigned to the Self-Illumination slot in the Material of course). This is the same technique I described in my seminal paper on "VC Gauge Backlighting Using Emissive Textures).Both AdditiveUserControlled and the two Blend modes will provide a constant bright WHITE backlighting (RGB:255,255,255). This requires one to use the "new FSX method" of providing xxx_night.bmp bitmap resources in the gauges themselves to balance the lighting...ACES should be publishing a new paper on FSX VC Gauge Lighting sometime in the next few days that they asked me to write... ;)

[Guest fbnweoghnwd]

Even with the bitmap set to Bright and the material's emissive mode set to Additive, those two gauges don't self-illuminate in the VC. Not even at night. In the 2D cockpit the self-illum works fine, 24 hrs a day.Here's the code for the low fuel light: (A:Fuel tank center level,percent) + 2 / 10 <Low Fuel Annunciator

[n4gix 4,947]

If the gauge works properly on the 2d panel, but not in the VC, then the problem is with the gauge poly's Material.You are specifying the same $vc.bmp in both the Diffuse Color and Self-Illumination slots, right?You would use a VC_L.bmp texture assignment in the Self-Illumination slot only if you're going to also use MultiplyBlend or MultiplyBlendUserControlled for the emissive mode.

[Guest fbnweoghnwd]

>You are specifying the same $vc.bmp in both the Diffuse>Color and Self-Illumination slots, right?Er...heh-heh...no. Didn't know it was necessary.I just went and tried that, and it's working much better. Much obliged as usual, Bill.Now, assuming I've got everything set up correctly, it seems as though MS made an improvement this time around, but still hasn't gotten it completely right. When the annunciators are lit, they're too bright. It looks as though the additive mode is adding the difuse and self-illumination together. Which is just what the name Additive implies...but it doesn't seem like the way to go here. You just want the color to be displayed exactly as it appears in the bitmap. I tried Multiply/Blend mode, which makes the illuminated light look correct, but then I'm back to that business where it won't light up at certain times, so I went back to Additive.I ended up darkening the texture for the illuminated version and that seems to be a workable fix.

[n4gix 4,947]

>Er...heh-heh...no. Didn't know it was necessary.>>I just went and tried that, and it's working much better. Much>obliged as usual, Bill.Well, it IS shown in the SDK... that's how I learned about it... ;)>Now, assuming I've got everything set up correctly, it seems>as though MS made an improvement this time around, but still>hasn't gotten it completely right. When the annunciators are>lit, they're too bright. It looks as though the additive mode>is adding the difuse and self-illumination together. Which is>just what the name Additive implies...but it doesn't seem like>the way to go here. You just want the color to be displayed>exactly as it appears in the bitmap. I tried Multiply/Blend>mode, which makes the illuminated light look correct, but then>I'm back to that business where it won't light up at certain>times, so I went back to Additive.>>I ended up darkening the texture for the illuminated version>and that seems to be a workable fix.Actually, in the case of a $VC.bmp "dummy texture," this is created by FS at runtime. Since there is no actual "Diffuse Color" or "Alpha channel" in a self-generated bitmap, the "assumed diffuse color" is RGB:255,255,255 - i.e., blinding BRIGHT white! :(I had asked ACES (politely, of course) if they could (would?) allow us to set the actual Diffuse Color based on the Material's property, but unfortunately there wasn't enough time to implement this for SP1.As it happens, the "original attempt" at the "always bright" Additive mode turned out to only illuminate at "Night," so this was simply renamed to "AdditiveNightOnly" mode and a new "Additive" mode was created. ;)Although as you did you can simply "darken" the "lighted bitmap" in the gauge, keep in mind that this may make it too "dark" then for the 2d panel to display properly...As it stands currently, FSX lighting - while greatly improved - still leaves the modeler with too many choices and too many compromises to achieve the desired balance and appearance.

[Guest fbnweoghnwd]

>Although as you did you can simply "darken" the "lighted>bitmap" in the gauge, keep in mind that this may make it too>"dark" then for the 2d panel to display properly...True...you have to find a happy medium that works in all situations.I can't help but think that they're overcomplicating the self illumination thing. In a case like this, all you need is for the poly to display the pixels exactly as they appear in the "lit" version of the bitmap, with no lighting adjustments. Maybe have an emissive mode called "Direct", or whatever.