• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX Bright Displays

Messages
531
Country
france
Hello experts,

I am sure this question has been asked a million times but I couldn't find a good answer at this time.
I have developed many aircraft displays for glass cockpits, using GDI+ in C++. When setting up the gauge, I always used the IMAGE_USE_BRIGHT flag so that the gauge always appears bright, like a real LCD display, whatever the exterior lighting in the sim. This works perfect in the 2D panel, but who uses a 2D panel today?
In the 3D cockpit, it doesn't work that well. The same code is used for the display, with the same IMAGE_USE_BRIGHT flag, but it is ignored in the VC. I know this is because it is supposed to be done through the textures and materials used in the definition of the VC model, but I never saw any add-on aircraft that is satisfying regarding that aspect. Even among the "professional" advanced add-ons available on the market, I have always been disapointed by the way the glass displays are lighted at day (it is OK at night).
Is it a limitation or bug of FSX? Is it because the 3D models are not defined correctly? Did I miss something?

Please feel free to move this topic in another forum if it is not the right place.

Thanks,
Eric
 
Eric, in a virtual cockpit the "lighting" of glass is entirely dependent on the Blend Mode settings in the FSX/P3D Material assigned to the $VC_texturename used on the polygon on which the gauge is projected.

For glass displays, one should always use "Additive" for the Blend Mode as it will ensure consistent brightness any time of the day. One can then control the actual relative brightness via normal GDI+ techniques, or by a semi-opaque overlay in an XML driven display.

Many years ago I authored a "White Paper" for Microsoft/ACES per their request. It is since gotten lost when ACES was closed, and I've long since lost my original. However I did find at least one intact copy at this URL that you may wish to read. I hope it helps!

http://doczz.net/doc/4662300/fsx-emissive-textures-and-how-they-relate-to-virtual-cockpit
 
Thank you. I from another post from you where you were saying this but the link was dead, I am happy you provided me one that works, I will read it carefully.
To make it short, can you please tell me WHERE the material is defined? Is it in the MDL file?
I ask you this because I would like to know if this can be changed on an existing aircraft. It is an old aircraft nobody really cares about but I still like flying it and I would like to improve this.

Thanks,
Eric
 
Just for information, the link I had found was this: https://www.flightsim.com/vbfs/wiki_index.php?title=FSX-Emissive-Textures
It is the same document but the link is still dead (http://www.freeflightdesign.com/tutorials/VC_Lighting_Tutorial.zip), probably not important.

Now I understand why I had so much difficulty understanding, this is because my panel.cfg looks like this:

Code:
[Vcockpit01]
size_mm=1024,1024
pixel_size=1024,1024
texture=$panel1
background_color=0,0,0
visible=0

gauge00=...
gauge01=...
Can you see the difference?
In my panel, there is NO file defined for this VCockpit section, no file for the texture. So I was thinking: how can a material be applied to a texture that does not exist?
(I know this $panel1 texture is not related to a texture file, it is here to position the gauges that are listed in this VCockpit section)
So if I understand correctly, adding a 24-bit format BMP file for light mapping, and referencing it in a line like file=... would make it work, is that right?
Is it the right way to apply an emissive texture to the virtual cockpit?

Thanks,
Eric
 
Eric, the Material is defined and configured in the 'source file', either GMax, Max, Blender, etc.

Since you can 'decompile' the model via MCX, you can also set parameters for the Blend Mode in that, then recompile for your target sim version.

Which specific techniques you can use depends entirely upon your intended target platform.

An alternate bitmap would replace the background_color=0,0,0 entry in the panel.cfg file.

[Vcockpit02]
file=B350i_VC2.bmp
size_mm=1024,1024
visible=1
pixel_size=1024,1024
texture=$B350i_VC2
 
Last edited:
I already used MCX to change some object animation but never found the way to change the blend mode.
I found the material editor but was surprised to see there are 2 definitions for $panel1 texture used here...
I tried to set both to 'Additive' as I think it is the mode I am looking for but it doesn't work. And worse, when I re-import the model in MCX, my choice has disappeared back to 'AdditiveNightOnly' :(
Do you know why?

Thanks for your help,
Eric
 
Last edited:
Eric, sad to say I've reached the end of my rope at this point. I haven't used MCX myself for much of anything except recovering the modeldef.xml for a project which had unfortunately gotten lost in a hard drive death a few years ago.

Arno would be the one to ask regarding the Material definitions, et cetera. One other idea is to duplicate the $panel1 entry in the "Self-Illumination" slot in the Material definition, instead of a panel1_LM texture (light mask).
 
Thanks for your help. I will ask for Arno's help but I think this problem has no solution. I talked to the FeelThere modeler who has done this aircraft, he told me that he tried many different options for this but never found the right one, probably because it does not exist.
I tried the same with MCX because I found out the way to change the emissive texture option. I am not 100% sure the modification worked fine, but I saw no change, whatever option I used.

All the add-on aircraft I saw that use vector graphics for the display gauges have this problem.
 
[...] One other idea is to duplicate the $panel1 entry in the "Self-Illumination" slot in the Material definition, instead of a panel1_LM texture (light mask).
Sorry to bother you again with this Bill, but I didn't totally understand your idea of using self-illumination and it looks interesting. Is it something you can do with MCX?
 
I understand that Arno has implemented the full gamut of Material options in MCX. The two criteria for self-illumination to work is having the gauge(s) replicated in the "Self-Illumination" slot (via the $VCxxx texture name) and having Additive emissive mode active.

It just occurred to me that you never mentioned what your target sim platform is. That too can have a direct bearing on what options are available...
 
I think I understand what you mean.
My target platform is FSX SE. If I am not wrong, it is the same as FSX regarding that aspect.
 
I don't see a Self-Illumination slot in my MCX Material Editor, but I might be missing it somehow.
 
Indeed, FSX and FSX:SE are virtually identical with regards to modeling and textures.

If Arno left Self-Illumination out of MCX, that is a major oversight, since it is an essential part of the SDK's specifications. Yes, it is most definitely part of the Max's FSX/P3D SDK toolset. It is also included in Blender I believe:
FJvka.png
 
Guys - Arno calls it "Emissive". It is the same thing:

"Self-Illumination" = "Emissive"

The slot is right under "diffuse" texture ;) and above "Environment" texture.

I wish Arno arranged the MCX material properties in exactly the same order as in 3DS MAX, and labeled them the same... there would be so much less confusion :rolleyes:
 
Last edited:
Hi Misho, happy to see you joining this thread :)
The problem I now have is when I made changes to the material properties and export the model, everything looks OK, but if I re-open the exported model, many updated properties appear with their initial value, as if my changes had been ignored. Among these "ignored changes" is the emissive mode, which I think is important. I set it to Additive but when re-importing the model, it appears as AdditiveNightOnly :(
I contacted Arno about this, he said the XtoMDL can change values if they are not used. For example, it may change the specular color if no specular attribute is set to true. I can understand this, but I don't think it should change the emissive mode... I tried to use the XtoMDL that comes with P3D (32 bits) and it doesn't work any better :(
I feel that I am close to the goal, but I cna't get to the next step. I'm afraid that without the help of Arno, I will not make it.

Eric
 
Hi Misho, happy to see you joining this thread :)

I thought I dropped in and see how things are progressing ;)

So - I tested MCX... I use MCX v1.4.0.0 4fa5843f DEV 7/2/2019
  • I loaded a small object I have, and I added an Emissive texture, exported it to EXPORTED.MDL. Shut down MCX
  • Restarted MCX. Imported EXPORTED.MDL, and the added texture was there - so, no problem.
  • Then - I changed AdditiveNightOnly to Additive, exported to EXPORTED2.MDL. Shut down MCX
  • Restarted MCX. Imported EXPORTED2.MDL, and the setting was at Additive - so, again, no problem.
So - it definitely works for me.

Just checking - Are you exporting as .x and then using XtoMDL to create new MDL? Or do you export directly to MDL from MCX?
 
That's interesting, thanks for doing that test.
I use XtoMDL because I thought MCX needed it to export as .x to creat an MDL, as you say. I thought this was the way MCX works to export a model. I thought this because the first time I tried it, I had an error message saying XtoMDL was not found and its location needed to be set in the options. I set the options to point to XtoMDL I have in the FSX SDK and it worked after that. I am surprised you can do it without XtoMDL but I may have missed something here...

I also thought my problem could be related to the model I am trying to update (FeelThere Airbus A318) so I tried the same changes with the standard Learjet and the result was the same.

Eric
 
Oh boy... no... the whole point of MCX is that it stramlines the process. That being said, MCX still uses XtoMDL to process .x files, but only when you import an .x file and want to export to MDL. Then it just acts as a fancy user interface for XtoMDL.

I am not sure, but I think Arno figured out the MDL file format, so when you import MDL, it writes the changes directly to MDL file which is in memory, and then simply saves back that same MDL with changes, bypassing any XtoMDL conversion. And I'm guessing, the way you did it, from MDL to x then to MDL, something got lost in translation.

So - did you try doing it the way I did?
 
I have just tried, right now. BTW, I saw there is a new version that I've just downloaded, I am sure to have the latest version.
As you suggested, I removed the location to XtoMDL shown on this image:
MCX_Options.png


Then I made some changes in the model and tried to export it, here is the error message I had:

XtoMDL_Error.png


What I understand is that MCX needs XtoMDL to export the model. If it doesn't find it, it generates an error and stops.
Is there another way to configure MCX for not using XtoMDL?
Are you sure you are not using another tool for this? (maybe you can share you Options page?)

Thanks,
Eric
 
Back
Top