Self-illuminated, bright, beautiful VC gauges! (FS9 Topic)

[Team_P3DSpacePort 6]

Hi all!I'm not sure if this has been "cracked" already for FS9 and if it has been "fixed" for FSX, but I have found a way to have bright, self-illuminated gauges in FS9's Virtual Cockpit, anytime, all the time, properly lit and as they should look (and the way they look in 2D cockpit, Illuminted at night). This has been a source of many "aaaargh" moments for a lot of designers - the sheer omission by MS of this very important gauge feature. Now, you can have your virtual cockpits lit to your heart's content with lamps, dials, panels, displays - anything you want! This also includes those pesky VC HUDs which have been, so far, turning dim when you turn towards the sun ... well, no more of that!So, in the spirit of Christmas season, go ahead and light up your virtual cockpits, by using the steps in my post #21977 from a while ago, http://forums.avsim.net/dcboard.php?az=sho..._id=21977&page=Follow all the steps as indicated, except, you will be looking for bitmaps that start with "$" (as you should name your Virtual Cockpit Textures, as described in SDK). I always name my VC textures starting with "$VC_" (i.e $VC_texturename.bmp) so I suggest you follow the same procedure.Once you identify the virtual cockpit material, change the 11th, 12th and 13th parameters from 0.00000000 to 1.00000000. The above post talks about only the 11th parameter, but in this case, you need to change 12th and 13th as well. Follow the steps in the post and BINGO - your VC gauge will be permanently bright, no matter what time of day/night or orientation. I have even "draped" the illuminated material to a 3-d lamp indicator, for that "pop-up" lamp look in VC!!! (as opposed to flat, 2-d surface in 3D VC).Merry Christmas, everyone, and I hope you find this little gem useful!

[Guest Patrick_Waugh]

Could you post a picture to show what you mean by VS (not gauge) lighting, and an example. =)

[Team_P3DSpacePort 6]

You are probably confused by the title of my original post:"Self-Illuminated material for VC (NOT gauges!!!)"Originally, that post was to solve the problem of lighting in cockpits that were closed, with small windows. In those cases there was no way that sun would shine on floor panels and foot pedals and such components that were away from the daylight. That post talked about how to "light" the material by texture only, without it being affected by the FS lighting. In this post, I extended the technique to the VC (not VS) GAUGES. They can now be made so that they "glow" all the time with full intensity, not being darkened at night or day (dependent on orientation). Take look at the attached screenshot: This is the part of the 3D Virtual Cockpit instrument console I'm working on (This is not a 2-D panel). You can see how, depending on the time of day, the console itself changes the lighting intensity, but the MFD and one of the buttons that is lit in the right button bank stays bright. Without this technique, the MFD and button would darken along with the rest of the console material.I hope this clears it up!

[n4gix 4,947]

Very interesing, Misho.1) Note that a more controlled technique for nighttime VC gauge illumination was posted over a year ago (December 7, 2005) using a lightmask texture so one can customize the color and intensity of lighting.2) Your technique could be used ideally for daytime VC gauge lighting, and by using embedded XML code in the model, the "daytime polygon set" could be dynamically switched for the "night time emissive set." ;)3) For FSX, all bets are off for either of our techniques. Since there are no more .asm files, your technique becomes INOP.Similarly, since ACES has eliminated the possibility of using lightmaps on $VC Materials, so emissive lightmasking is dead, dead, DEAD... (-: The "new and improved" FSX method forces the entire polygon to which a $VC Material is assigned to "glow in the dark," which is - quite honestly - a giant step backwards IMHO.OTOH, life goes on and I'm confident that others and I will continue to experiment and develop new techniques to work with the "new system." It will however, take some time and a LOT of experimentation... Thanks for sharing!Here are a few of my "night time VC panels" to illustrate:http://img251.imageshack.us/img251/9404/tb...ighted046ro.jpghttp://img100.imageshack.us/img100/6540/ci...compas037ly.jpghttp://img7.imageshack.us/img7/2381/cj1cockpit012ed.jpghttp://img57.imageshack.us/img57/3355/cj1vc6xj.jpg

[Team_P3DSpacePort 6]

Thanks Bill! Great Shots!Actually, for FSX, I think M$ "fixed" the bug for which I now found a workaround in FS9. This technique does precisely what you described: forces the entire polygon to which a $VC Material is assigned to "glow in the dark". I'm not sure why that would be a step backwards - can you please explain what the drawbacks are compared to the lightmask method? I looked into the lightmask method you posted a while ago, but I had an explicit requrement of these gauges working properly in the daytime, coupled with the requirement that those pesky black backgrounds do NOT show up :) (Namely, a proper HUD gauge, which I believe was not possible with the lightmask method). Also - I am not sure if you could apply lightmask method to the vector-drawn gauges.Anyway, I'm in the dark (pun intended LOL ) as to why you think the FSX method is a step backward. Unless I'm missing something important, it seems to me that this method can do everything Lightmap can, plus the proper daytime thing.

[n4gix 4,947]

>Thanks Bill! Great Shots!>>I am not sure if you could apply lightmask method to>the vector-drawn gauges.The first picture above showing the cockpit of the Cirrus SR22's Avidyne PFD/MFD are using GDI+ (vector drawn) gauges... ;)>Anyway, I'm in the dark (pun intended LOL ) as to why you>think the FSX method is a step backward. Unless I'm missing>something important, it seems to me that this method can do>everything Lightmap can, plus the proper daytime thing.Simply because the entire polygon DOES light up, bezels and backgrounds included... A picture is worth a thousand words. Here is a shot of the CJ1 in FSX using the wonderful "new method versus the FS9 Emissive Lightmask method..." :-erks Can anyone possibly call this an "improvement?" :-bang Notice in particular the "subtle lighting" that's possible with the method I perfected! ;)http://img185.imageshack.us/img185/7198/cj...lightingzd1.jpg:-hang

[Team_P3DSpacePort 6]

>The first picture above showing the cockpit of the Cirrus>SR22's Avidyne PFD/MFD are using GDI+ (vector drawn) gauges...>;)I stand corrected! How about that HUD though? ;)>Simply because the entire polygon DOES light up, bezels and>backgrounds included... A picture is worth a thousand words. >Here is a shot of the CJ1 in FSX using the wonderful "new>method versus the FS9 Emissive Lightmask method..." :-erks >I get it now - yes I agree, the subtle lighting looks amazing. RE: the "entire polygon", I have to say that with a proper bitmap design and good masking, the background won't light up... >>>Notice in particular the "subtle lighting" that's possible>with the method I perfected! ;)Again, I absolutely agree. Bottom line: this "fix" is not good for any object that is shined on by light source (as in, a subtle lighting of the analog gauge faces using a recessed bulb, or a small map reading light I see you have in the very first of your original screenshots). However, for any emissive objects such as MFDs or warning lights, it should work just fine, with the XML polygon switching scheme being an option for the daytime/nighttime changes.Thanks for clearing it up!

[n4gix 4,947]

>I stand corrected! How about that HUD though? ;)True enough, emissive backlighting would not work for a HUD because gauge polygons becomes opaque with no masking texture applied...>I get it now - yes I agree, the subtle lighting looks amazing.>RE: the "entire polygon", I have to say that with a proper>bitmap design and good masking, the background won't light>up... As can be seen by the PFD/MFD frames, as well as the radio's "face panel." However, it simply creates more work needlessly.>Again, I absolutely agree. Bottom line: this "fix" is not good>for any object that is shined on by light source (as in, a>subtle lighting of the analog gauge faces using a recessed>bulb, or a small map reading light I see you have in the very>first of your original screenshots). However, for any emissive>objects such as MFDs or warning lights, it should work just>fine, with the XML polygon switching scheme being an option>for the daytime/nighttime changes.>>Thanks for clearing it up!Worse of all, the absolutely uniform light intensity ruins any possibility of subtle touches, such as continuously variable lighting without resorting to additional masking textures in the gauges themselves.I've made a point of planting the seed directly in the ear(s) of the relevant folks at ACES asking that the ability to specify a self-created lightmask be restored either in the promised update, or at least by the time FSXI is being developed.

[dragonflightdesign 98]

Hi BillWhile you're at it, how about getting them to release a gauges.h file that actually works and save me keep chasing my tail? They're quite welcome to 'mine' :) :)-Dai

[n4gix 4,947]

>Hi Bill>>While you're at it, how about getting them to release a>gauges.h file that actually works and save me keep chasing my>tail? They're quite welcome to 'mine' :) :)If you'd be so kind as to let me know precisely what you've found that's incorrect, I'd be happy to make sure that Mike Z. and Susan A. get the information.

[Varmint007 2]

Hi Misho,Thank you for sharing this technique. I was able to apply it, but with one problem; I have two VC textures, I'll call them $VC_1 and $VC_2. I only want $VC_2 to receive the illumination override. Even though they are applied as completely separate GMax materials, the .asm file shows both $VC_1 and $VC_2 sharing the same ID. Therefore both of these materials are affected by the hack.Do you know how to circumvent this? I don't understand how the compiler is assigning materials internally, but apparently it's not tied directly to Gmax materials.--J

[Guest Patrick_Waugh]

gauges.h is correct.You are supposed to compile now in C++ (not C), although you will find it is possible with the version I recently posted (that I modified slightly).

[Team_P3DSpacePort 6]

Hi Jon,Simple easy fix:All the $VC textures are referencing one meaterial, which you can see in the command: (likely different in yours)MATERIAL 11,11 ; <0,0,0,0> $VC_1.BMP;;;First "11" is the Material #, and the second "11" is the texturenumber. If you have MORE than one texture (you have 2, and I have 3), they will always use the same material, so that all the references to the textures will always look like:MATERIAL 11,9 ; <0,0,0,0> $VC_1.BMP;;;....MATERIAL 11,10 ; <0,0,0,0> $VC_2.BMP;;;...MATERIAL 11,11 ; <0,0,0,0> $VC_3.BMP;;;If you look for the material list, "MATERIAL_LIST_BEGIN", you will see that under material 11, the entries 11, 12 and 13 are all set to "1.0000000". This is what "turns on" the emissivity.Well ,a simple fix is: COPY the emissivity material (in this case, material 11 under the MATERIAL_LIST_BEGIN into a new material, material 12, and zero out the entries 11,12 and 13. MATERIAL_DEF 0.000000,0.000000,0.000000,0.000000, 0.392157,0.392157,0.392157, 0.000000,0.000000,0.000000, 1.000000,1.000000,1.000000, 0.000000 ; 11 MATERIAL_DEF 0.000000,0.000000,0.000000,0.000000, 0.392157,0.392157,0.392157, 0.000000,0.000000,0.000000, 0.000000,0.000000,0.000000, 0.000000 ; 12Then, if you want $VC_2.bmp not to be emissive, set MATERIAL line:MATERIAL 11,10 ; <0,0,0,0> $VC_2.BMP;;;to use material 12:MATERIAL 12,10 ; <0,0,0,0> $VC_2.BMP;;;Bingo! I tried it, it works!

[Varmint007 2]

You sir, are a steely-eyed missile man. It worked perfectly!Thanks again,--Jon

[Team_P3DSpacePort 6]

hehe thanks! My pleasure!