Bug in VC lighting?

[Simon853]

If you load the Beech Baron and set the time of day to night, with the instrument lights off and battery on, you can see that the left and right alternator annunciators are still lit on the 2D panel. However, they are not lit in the VC.

I've been doing some experiments and it appears that the IMAGE_USE_BRIGHT in C (or the ="Bright" in XML) does not work in virtual cockpits.

Anyone else noticed this?

Si

 

[n4gix]

I've been doing some experiments and it appears that the IMAGE_USE_BRIGHT in C (or the ="Bright" in XML) does not work in virtual cockpits.

Anyone else noticed this?

Si

Oh, the tag works just fine, as long as the vc gauge polygon has an emissive lightmap applied to it in the .mdl file, and there actually is a lightmap in the \texture folder...

...This technique will work for both FS9 and FSX.

For FSX, there is also a completely NEW method that requires that the gauge polys FSX Material have the Additive or AdditiveNightOnly attribute flag enabled in the .mdl file. It also requires all gauges that need lighting to have a set of alternate bitmaps for night lighting use with the suffix _night added to the root filename.

You can read more about this in the paper I wrote for ACES and was posted at http://msdn.microsoft.com/en-us/esp/cc788741.aspx

 

[Simon853]

Thanks Bill.

I'm using C gauges so I guess I'll have to swap the base textures myself (rather than XML doing it for me.)

Si

 

[n4gix]

Thanks Bill.

I'm using C gauges so I guess I'll have to swap the base textures myself (rather than XML doing it for me.)

Si

Night time versions for FSX gauges are simply the same resource number + 40000 (decimal). I discovered this several years ago when I first started digging deep into FSX's new system. I examined the Bell_206B!Attitude gauge, as used by the default C172 in the VC. It is a C style gauge rather than the XML version they used for the 2d panel. I notice that there was a "darker" version of the bitmaps used that were precisely 40000 (dec) higher than the "normal" bitmaps. Eureka!

Using this convention, it works the same as a xxx_night.bmp file does in an XML gauge... automatically!

For example:

Shot at 2008-10-09

.rc
Rec0       BITMAP  DISCARDABLE     "res\\ice_inspect.BMP"
Rec1       BITMAP  DISCARDABLE     "res\\ice_inspect_night.BMP"
Rec2       BITMAP  DISCARDABLE     "res\\ice_inspect_lighted.BMP"

.h
 ////////////////////////////////////////////////////
#define  Rec0             0x1000
#define  Rec1             0xac40
#define  Rec2             0x1010

/* NOTES ///////////////////////////////
Note that the daytime texture is 0x1000
Add 40000 (decimal)              [U]0x9c40[/U] (hex)
The nightime texture is          0xac40

It's critically important to note that no other changes to the C gauge are required. FSX will *automatically* use the "nighttime version" of the background bitmap whenever the panel lights switch is turned on!

Here is a very quick and easy calculator for dec/hex conversions. I use it all the time!

http://flor.nl/dec2hex.html

I've found that a quick way to create the "nightime versions" of bitmaps is to simply add a black (0,0,0) layer over the daytime texture, then set the opacity to ~70% to 80%, then save using the same filename_night.bmp...

 

[Simon853]

Thanks Bill, that's very intersting. I was examining the 206 gauges myself yesterday trying to figure out how the nighttime textures worked.

Do you know how the nightime texture gets the colour (night or luminous) modifier applied as specified in the panel.cfg? (If at all - I don't think it uses luminous as I tried playing with the values to no effect.)

I had wondered whether there's an alpha layer or something specifying the glass reflection (that glows yellow when the lights are on) but it makes sense if it is in fact a separate bitmap altogether. (Seems inefficient though.)

My gauge textures already seem to get darkened automatically at night, but the lighting doesn't work (when panel lights are on) as they then just get drawn using daytime luminocity.

I use Windows calculator to convert between Hex and Decimal.

Thanks,

Si

PS. You don't need to convert to and from hex to add 4000 decimal. The compiler will resolve this:

#define BMP_TORQUE_DIAL_FACE            0x113F
#define BMP_TORQUE_DIAL_FACE_NIGHT      (0x113F + 4000)

 

[n4gix]

The luminous entry in the panel.cfg affects only gauge bitmaps that have the LUMINOUS attribute rather than the BRIGHT attribute applied.

As it happens, I frequently make use of that to provide three-level lighting in a gauge: Off/Dim/Bright.***

Remember that in a VC a gauge MUST have a backlight source that's provided by a model's Material attribute. Think of VC gauge polys like you would an LCD monitor. If the "backlight" in an LCD monitor burns out, you will still see an image on the screen, but it will be very, very dark!

As I explained in my white paper, there are currently three basic modes of backlighting available to the FSX modeler, and each one has very different behaviors!

Additive mode = adds the RGB of the daytime and nightime texture. What is important to understand is that the lightmap ADDS TO the existing daytime texture.

Blend mode = gradually replaces the RGB of the daytime with the RGB of the nightime texture. What is important to understand is that the lightmap’s color and luminosity is BLENDED with the existing daytime texture.

MultiplyBlend = multiplies the RGB of the daytime by the RGB of the nightime texture. What is critical to understand at this juncture is that the first two emissive modes described apply for the most part to the “surface” of the daytime texture, whereas the new emissive mode applies behind the daytime texture, in one word: backlighting!

*** Note: using LUMINOUS/BRIGHT in a set of gauge callbacks for three-level lighting:

//---------------------------------------------------------------------------
FLOAT64 FSAPI asi_needle_hi_cb (PELEMENT_NEEDLE pelement)

{
    lookup_var(&curr_asi);
    asi_ret = curr_asi.var_value.n;
    if ( asi_ret > GAUGE_MAX_AIRSPEED ) asi_ret = GAUGE_MAX_AIRSPEED;
    if ( asi_ret < GAUGE_MIN_AIRSPEED ) asi_ret = GAUGE_MIN_AIRSPEED;
    if (panel_lights == 2)
	{
		SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ;
	}
    else
	{
		HIDE_IMAGE(pelement) ;
	}
    return asi_ret;
}

//---------------------------------------------------------------------------
FLOAT64 FSAPI asi_needle_cb (PELEMENT_NEEDLE pelement)

{
    lookup_var(&curr_asi);
    asi_ret = curr_asi.var_value.n;
    if ( asi_ret > GAUGE_MAX_AIRSPEED ) asi_ret = GAUGE_MAX_AIRSPEED;
    if ( asi_ret < GAUGE_MIN_AIRSPEED ) asi_ret = GAUGE_MIN_AIRSPEED;
    if (panel_lights == 1)
	{
		SHOW_IMAGE(pelement) ; DARKEN_IMAGE(pelement); LUMINOUS_IMAGE(pelement) ;
	}
    else
	{
		DARKEN_IMAGE(pelement); HIDE_IMAGE(pelement) ;
	}
    return asi_ret;
}

//---------------------------------------------------------------------------
FLOAT64 FSAPI asi_needle_off_cb (PELEMENT_NEEDLE pelement)

{
    lookup_var(&curr_asi);
    asi_ret = curr_asi.var_value.n;
    if ( asi_ret > GAUGE_MAX_AIRSPEED ) asi_ret = GAUGE_MAX_AIRSPEED;
    if ( asi_ret < GAUGE_MIN_AIRSPEED ) asi_ret = GAUGE_MIN_AIRSPEED;
    if (panel_lights == 0)
	{
		SHOW_IMAGE(pelement) ;
	}
    else
	{
		HIDE_IMAGE(pelement) ;
	}
    return asi_ret;
}

 

[Simon853]

Thanks Bill.
I already do something like your 3 level lighting, but only using 2 levels. I hadn't considered using luminous as a third because it appeared to be dependent on the panel lights beig on.

I've tried the night bitmap setting its id to:

#define BMP_TORQUE_DIAL_FACE 0x113F
#define BMP_TORQUE_DIAL_FACE_NIGHT 0x20DF

But it doesn't seem to work as expected. The standard day texture is displayed, (darkened by the sim's lighting engine at night) or at full day luminocity when the panel lights are on. The night texture isn't displayed.

This is my gauge's base layer static definition:

MAKE_STATIC
(
	tq_image_static,
	BMP_TORQUE_DIAL_FACE,
	tq_needle_list,
	NULL,
	IMAGE_USE_TRANSPARENCY|IMAGE_BILINEAR_COLOR|IMAGE_USE_ERASE,
	0,
	0,0
)

I know the night image is getting compiled in ok because I can change the BMP_ reference in the above definition and it gets displayed. It just doesn't seem to do so automatically as you describe it should.

Si

Edit: PS. This is 2D panels I'm refering to here. I'll leave sorting the VC out to another day..

 

[n4gix]

I've tried the night bitmap setting its id to:

#define BMP_TORQUE_DIAL_FACE            0x113F
#define BMP_TORQUE_DIAL_FACE_NIGHT      0x20DF

Well, your math is incorrect, so I'm not terribly surprised...

Note that the daytime texture is 0x113F
Add 40000 (decimal)              [U]0x9c40[/U] (hex)
                                 0xad7F

Ah, no wonder. I just noticed your last edit, where you added FOUR THOUSAND instead of FORTY THOUSAND!

PS. You don't need to convert to and from hex to add 4000 decimal. The compiler will resolve this:

Code:
#define BMP_TORQUE_DIAL_FACE            0x113F
#define BMP_TORQUE_DIAL_FACE_NIGHT      (0x113F + 4000)

Nonetheless, that's a great tip! It will make my future work much faster not to have to calculate the new resource number myself...

...as long as I remember to use 40,000 and not 4,000...

 

[n4gix]

Edit: PS. This is 2D panels I'm refering to here. I'll leave sorting the VC out to another day..

Keep in mind that the only reason to bother with this at all is to accomodate the way the new lighting system works in FSX.

However, don't feel that you're locked into using either one or the other systems!

I use both methods in the same model/panel system myself, depending on what I want to achieve, even though it raises the level of complexity quite a bit!

It becomes even more challenging if one is designing a system that will work in both FSX and FS9, since of course FS9 doesn't support the "auto-swap night bitmaps" at all...

...meaning that I have to include code that will detect if the gauge is running in FS9 and manage the bitmap swap myself...

 

[Simon853]

40,000. Ah, sorry. It was late when I tried it..

Si

PS. Actually adding the (+40000) in the #define doesn't work after all. It should compile (i.e. it's perfectly acceptable C), but the resource editor's parser doesn't like it. But there's no reason why you can't just specify all the resource IDs in decimal, making the addition easier anyway.

 

[n4gix]

But there's no reason why you can't just specify all the resource IDs in decimal, making the addition easier anyway.

Actually, there is a very good reason to stick with hex... Only certain ranges of hex numbers should be used to prevent unexpected and bizzare things from occuring... See my Wiki article on "Safe Ranges"...

http://www.fsdeveloper.com/wiki/index.php?title=Gauges:_Resource_Numbering

Trust me, there's a lot of "gottchas" in this crazy quilt "system" from ACES!!!

Of course, you could simply translate the table suggested to decimal if you wished:

256-755 1280-2035 2304-2803

4352-4851 etc.

But, that's a bit tough to remember!

 

[Simon853]

All working now. Thanks Bill.

Si

 

[n4gix]

You are most welcome! Pass it on to the next person then...