Idiot proofing emissive textures

[Guest Vorlin]

Hi all,Ok, I've got a good idea of how this is supposed to work except for one little detail that is driving me nuts. I understand the adjustment formula for luminosity and the logic behind it, including that it uses the alpha channel to key off of when it applies the colors specified in the panel.cfgOne thing that the SDK and many posts about this didn't cover is how all the various bmp files interact. IE:A VC can have something like the following:file=MyImage.bmp Background_color=0,0,0 size_mm=512,512visible=0pixel_size=512,512texture=$AuthorsImageDay=255,255,255Night=50,100,225Luminous=255,50,50We have:1) The author's $ bmp that was used as a place holder. By assigning a custom bmp that name, we can have it render into the VC as if it were hard coded.2) The bmp specified in "file=" which gets laid right over the $ bmp... why? I have no idea. It seems a bad waste of resources to map an image to the same poly twice and I usually leave this line out of my panel.cfg if I'm using a $ bmp.3) The gauge bmp's themselves.4) The _L bmp that acts as a light mask.5) The Day / Night / Luminosity factors that get added in via the formula depending on Day / Night / Lights on or off.Now, we're supposed to use the "Luminous=" line to control what color the luminous lights are. We're also to use the alpha channel to control where the luminous color is applied to and in what strength. I have also noticed that by using a colored _L image that I can have colored lights. So, now there are two questions:1) When the lights are on, is the luminous color being worked into the color that we have in the _L and the mix of the two being shown or is the _L totally controlling the color of the light?2) We use the alpha channel to determine what light bus is triggering this whole thing. What I don't see anywhere is that we're to use the alpha channel of WHICH image???????I was working with the _L's alpha channel but have had major problems on and off. Using a DXT3 _L crashes the sim. An 8 bit colorkey _L won't work. A 32 bit _L with alpha worked for a bit and then froze my sim the fourth time I triggered the lights.Then I got to thinking... what if it's not the _L that's supposed to have the controlling alpha channel in the first place? What if it's the $ or the "file=" image that is looked to for this information?Someone please pass me a paper towel... I need to wipe the blood off of my desk and forehead!Scott / Vorlin

[n4gix 4,947]

There's too many misleading and/or false conclusions so rather than quote and post-in-line, I'll start fresh... ;)Please note that this discussion is limited to VC only, so to clear the decks for further explication, let's deal with the first 'red-herring': Luminosity setting in the panel.cfg file.This setting affects two things, and ONLY two things: 2d panel bitmaps and gauges which contain Use Luminous tags. For the VC, the only relevance for luminosity therefore are in the gauges themselves that USE the luminious tag.Next, let us deal with the VCockpitXX entries://--------------------------------------------------------{Vcockpit01} // replaced brackets for visibility in the forum!file=C400_VC1.bmp <= this is an optional entry: 24 bit .bmp only, stored in the panel folder, and used to provide texture to mapped areas where gauges "aren't..." I rarely use this any longer, except as a "template" file to be used in FS Panel Studio when aligning gauges. Now I mostly use "gauge-shaped cookies" for the polygons, and map the main panel background separately so I can use higher quality textures from the texture folder.Background_color=0,0,0 ;)visible=0 <= this is a throughly useless entry. Why would you WANT the VC to be "visible on startup?" However, it will force the a/c to load to the VC if set...size_mm = 1024, 1024pixel_size=1024,1024 ;) The actual coordinate numbers used in the gauge entries are MM though, not pixels! So, if you establish some odd ratio such as 2:1, it makes gauge placement more difficult.texture=$C400_VC1 <= This is a DUMMY filename! No real, physical bitmap is EVER needed here. The $ prefix (or panel_ prefix) simply tells the FS Panel System to "autogenerate" a texture in memory. In effect, $C400_VC1 becomes a memory "pointer" or address in memory. The FS Panel System will then "draw" all the gauges on this "texture" using the coordinate information specified in the panel.cfg file, and then "display it" in the sim.Now that we've cleared up the above, let's turn to the issue of emmissive lighting in the VC. The easiest way to visualize "how" the lightmap works is to consider the LCD computer monitor. Without a "backlight" on the LCD monitor, you would have pixels displayed on screen, but the image would be too dark to be useful. So, manufacturers place a constant lightsource behind the screen to provide illumination.The VC _L.bmp provides this "light source" for $VC textures! Several things have to be enabled before this will work (note, this applies to GMax models, FSDS3 has its own wierd method):1) the model itself must have a Diffuse Color texture specified: $something.bmp2) in addition, the model must have a Self-Illumination texture specified: something_L.bmpAssuming that the model has the above, then in order for the VC to use the something_L.bmp file, all that is needed is to do the following:1) Convert the something_L.bmp to DXT3 w/black or white alpha2) Place the converted something_L.bmp file in the texture folder.The intensity and color of the lightmap is controlled by the main, RGB channel, and the 'light switch' is controlled by the alpha channel:1) if pure white - landing lights switch controls on/off2) if pure black - any light switch EXCEPT landing lights switch controls on/offNote that the ONLY time luminous has any effect in the VC is if it was used in any of the gauges...I sure hope this will help, 'cause it took a long time to write! ;)

[Guest Vorlin]

It was a HUGE help Bill! I've been using trial and error and apparently even some of my errors sort-of function... somewhat.I've been leaving "file=" out and using the texture name specified in "texture=$..." to map a DXT3 to the main panel. This functions if you put that texture in the textures folder but it may be causing some of my issues because the sim locks up after reloading that aircraft 3 or 4 times.Yes, I got the hint about Luminosity LOLKnowing that the _L should be DXT3 is a big help.I've been trying to learn by taking apart an aircraft that has an 8 bit panel.bmp in the panels folder AND a DXT3 $filename for the panel on the same aircraft. It was mapping both to one panel. This only added to the confusion... then toss in the fact that some of their _L's were in DXT3 AND some others were in 8 bit. Yea, pass the Malox...In the meantime, I got it functional though I'll be cleaing it all up here shortly. Also, since it was functional, I devised a dimmer setup... thanks to the archives, I managed to avoid your frustrations with the formula for the sun's angle in the process of doing this.Additional thanks to Jan and Arnie for their past work with that formula... it's still helping wayward peons like me!Thanks!Scott / Vorlin

[n4gix 4,947]

I suppose it's worth mentioning that the something_L.bmp does not necessarily have to be the same dimensions as either the file=something.bmp or the texture=$something...//--------------------------------------------------------[Vcockpit01]file=C400_VC1.bmp Background_color=0,0,0 size_mm=1024,1024visible=0pixel_size=1024,1024texture=$C400_VC1 The C400_VC1.bmp could be as small as 8x8 if you wished, but don't expect much in the way of precision... ;)Typically, unless I'm using some gradient shading for the lightmap (such as a steam gauge), I will reduce the bitmap to 512x512 to reduce the impact on the system. ;)Also, one might think that DXT1 w/alpha would work... they don't...

[Guest Vorlin]

The model I was learning from did have 512 _L maps for 1024 panels. I found out about DXT1 w/ alpha the hard way earlier today.Bill, I'm confused about one thing and I think it comes down to plain old ignorance on my part. You say that with the landing lights bus and some XML in the model you can make individual circuts react. What do you mean by XML in the model? I've done 3d modeling, still use a full-powered studio every day, but have no idea how XML could be part of, or introduced into, the X-file format that is the middleman between Gmax or any other program's native format and the mdl format. Wouldn't XML have to be passed to MakeMDL as part of the X-file?Or are you using XML in gauges to control the landing light bus?Just curious about that. So far, this project is really beginning to look *sweet*. It's for the guys at HoverControl and I look at it as my public debuet.Ok, it's 1:35 AM and I have to work in the morning... plus I think I just butchered the only French word in this whole post.Asta manana... and thanks for the insights!!!!!!!Scott / Vorlin

[n4gix 4,947]

>Bill, I'm confused about one thing and I think it comes down>to plain old ignorance on my part. You say that with the>landing lights bus and some XML in the model you can make>individual circuts react. >>What do you mean by XML in the model? I've done 3d modeling,>still use a full-powered studio every day, but have no idea>how XML could be part of, or introduced into, the X-file>format that is the middleman between Gmax or any other>program's native format and the mdl format. Wouldn't XML have>to be passed to MakeMDL as part of the X-file?Shirly! You jest! ;)XML code may be used in a model via the MakeMDL.parts.xml file. MakeMDL.exe will automatically parse the MakeMDL.parts.xml file and cheerfully insert any code that matches a xxx tag up with a physical part in the model during the compile.With this system, any part of a model may have its visibility affected, or be custom animated/controlled, etc., all through use of simple XML code.There is an entire forum at http://freeflightdesign.com called "XML Parts" which contains working examples and code templates.Essentially, I can control such things as VC panel lighting through use of embedded XML code that swaps non-lighted polys with lighted polys. Here is a simple example of a hierarchy that will control lighting for a main panel divided into three 'zones', left, center and right:interior...main_panel.....left_lights_off.......all gauge polys for left panel linked.....center_lights_off.......all gauge polys for center panel linked.....right_lights_off.......all gauge polys for right panel linked.....left_lights_on.......all gauge polys for left panel linked.....center_lights_on.......all gauge polys for center panel linked.....right_lights_on.......all gauge polys for right panel linkedAll "non-lighted" polys have a Material with Diffuse, but no Self-Illumination texturesAll "lighted" polys have a Material with both Diffuse and Self-Illumination textures (i.e., $VC_01.bmp, VC_01_L.bmp)Now, a brief example of XML code for the left side of the panel's lighting: left_lights_on(A:LIGHT PANEL,bool) (L:LeftPanel,bool) && 1left_lights_off(A:LIGHT PANEL,bool) (L:LeftPanel,bool) && -10This means that for the left panel to be lighted, BOTH the FS variable A:LIGHT PANEL must be on and my custom switch L:LeftPanel must b on, otherwise the 'non-lighted gauge polys' will be displayed.Simple, nu?

[Guest Vorlin]

When it comes to modeling for MSFS I only got as far as figuring out how to export X files from... ummm, other programs.... and get them into MakeMDL.I knew that you could create custom animations by altering the parts xml file but had no idea you could do anything else.When I get this panel done, I think it's time to start experimenting with making models so I can figure out how to best coordinate the XML in both to suit my style and goals.Thanks Bill!AND DON'T CALL ME SHIRLEY!What? Did you think I'd miss that reference? Hey, I may only be 40 but I still remember most of the decent lines going back to "Get away from me kid, ya bother me!"Oh man, we're dating ourselves LOLScott / Vorlin