Night Texture not Available

[=rk=]

MCX has not been displaying night textures for some time now. It was not enabled in the version before the mipmap improvements, which is why I switched back to latest dev, where it is also unavailable.

I only modeled one of the two marker lights, so I only made one of the lights a night texture in Photoshop, I'm pretty sure I got it right, but I'd like to check. Got it! I'll just load the night texture as day to inspect it.

 

[arno]

Hi Rick,

The material settings look OK.

Does the event log show that both textures are loaded into MCX?

 

[=rk=]

Yes MCX loads the texture internally. MCX does not display the night texture for any model.

Also after processing by MCX, the model displays as expected at night in sim.

 

[arno]

Now that I look at your screenshot again, could it be you have the simple shader mode activated? You need to use the complex shader mode to see the night textures.

 

[=rk=]

I can see that thank you. The simple shader functionality is also necessary? I'd like to disable the whole possibility of it.

 

[arno]

The simple shader is needed for people who run MCX on an old machine that does not support all OpenGL commands. But the default shader is the complex one since that has all the functions.

 

[=rk=]

Like Windows 98/2000? OK, well they probably know they can't use the night texture button. Is it not possible to configure MCX to also activate the complex shader, when someone clicks the night texture, since that is obviously the intention?

Besides foreseeing this play out again in the not too distant, but overly dim future, the feature might help others, as well.

 

[arno]

Hi,

It's not really related to the OS, it's more that some people are running their development tools on laptops that have integrated GPUs. If these are a bit older, they don't always support all OpenGL commands.

But it might be useful to print a warning when the simple shader is active.

 

[=rk=]

If you are suggesting that setting the button to activate a warning, "night textures not available with simple shader," seems like it is less of a conversation starter at FSDeveloper, then empowering people smarter than I to figure it out for themselves, I agree.

 

[arno]

I have added a warning now, it will be in the next development release.

 

[=rk=]

Thank you. I've noticed an odd behavior using the LOD tool with one model. I often use the LOD tool to replace a model that has already been placed in scenery. I do this by importing the new model as a unique LOD, then I delete the previous, allowing the placement and attached lights to remain. On this occasion, with one particular model, MCX is not importing all the replacement textures, unless I first export the new model as gltf.

The original low detail model.

Collada replacement.

GLTF replacement.

Procedurally, it's not really a big deal, I just have to import the Collada with MCX and export as gltf and then the replacement routine works fine, but it seems odd. You can have the model if you want, going to give it away soon anyway.

 

[=rk=]

More oddness, the phantom texture slot is back. The Console informes the same texture is in the decal slot for one LOD model, and the COMP slot for a different LOD of the same model. Of course I never made a decal texture or set a decal on one specific LOD, it is a software glitch, MCS shows everything as it should be and I know from the past time that the .gltf file is probably corrupt.

Sample.zip

Shared with Dropbox

www.dropbox.com

 

[arno]

Thanks, I'll check the sample file to see if I can spot any issues in it.

 

[=rk=]

I think it is the LOD swap trick I use, the model was completely unusable. I first tried stripping the extra LODs, that didn't help, FSPackagetool insisted it was still calling a decal texture in place of a comp one and also that it had duplicate GUIDs to itself. I ditched it and rebuilt from the Collada with no issues, except the lost placement.

 

[arno]

I have checked the glTF files in the sample, but I don't really see an issue in there. The error indicates that the same texture image is used for a different texture types (comp vs decal). Could it be that you have by accident changed the material type in one of the LOD models? I don't see that in your samples, but maybe if one was changed from standard to decal that might explain it.

 

[=rk=]

Arno, how could anyone change only one material slot assignment, in one LOD and getting that far inside the model, call it a mistake? "Oh, I just wanted to see if I could text edit individual material slots of the gltf in Notepad, or I just decided to build my model using random lower detail versions with randomly assigned textures and forgot?"

And it is your position that I make this nearly identical mistake, multiple times, on separate models? I feel like your child just drove through my fence and you are insisting that my fence is at fault.

No extra texture, straight out of Sketchup and into MCX. Last night, however, MCX was on a real "bender." I ran a model through the draw call minimizer, it turned all the material colors pure white, removed an albedo texture and moved the normal texture into the albedo slot. I "undid," the material colors returned but the textures stayed garbled. I then ran the minimizer again, hoping the white colors are the more likely display anomaly, than an actual corruption, I manually re assigned the textures. I decided that since I'd already done all the PBR editing, that is the hardest part of the MCX procedure, it would be lost if I discarded the model anyway.

View attachment 86411

 

[arno]

Rick,

If you look in any of the LOD models you will see that for the xROOFHANGAR02_ALBD material the albedo slot and the RoughMetalAO slot both have the same texture assigned. The normal texture slot has the comp texture assigned. If that is corrected so that each slot has the right texture the compilation error goes away. So it seems that the textures got mixed up for this one material.

From the glTF files I can't see of course how this mixing up of the textures has happened. But since it only happened for this one material in the model, I think it is most likely not a structural error in MCX. I have not been able to reproduce such behavior by modifying the model in MCX (actually I used MCX to correct the error). But if you know a workflow to reproduce this behavior I'll take a look of course.

I might add a warning to the glTF writer if the same texture is assigned to these incompatible slots.

 

[=rk=]

The workflow that appears to induce this behavior is when a model is replaced using the LOD tool. The procedure is to change the original LOD from 100 to 90, then use the add LOD model button to import the replacement at LOD 100. The original is then deleted. Doing this preserves attached lights, GUID and scenery placement, although I have since learned that MSFS placement is only model name controlled, you can replace a model with a different GUID using the same name in the Scenery Editor.

 

[arno]

The workflow that appears to induce this behavior is when a model is replaced using the LOD tool. The procedure is to change the original LOD from 100 to 90, then use the add LOD model button to import the replacement at LOD 100. The original is then deleted. Doing this preserves attached lights, GUID and scenery placement,

I have just tried to replace a LOD in the LOD Creator, but that does not change the material settings here. From which format are you importing the new LOD?

although I have since learned that MSFS placement is only model name controlled, you can replace a model with a different GUID using the same name in the Scenery Editor.

No, the model placement is still done with the GUID in the XML files that are part of your package sources. It might be that the scenario editor GUI has some functionality to update the placement when the name is the same, I don't know since I don't like that editor.

 

[=rk=]

I have just tried to replace a LOD in the LOD Creator, but that does not change the material settings here. From which format are you importing the new LOD?

I have the most issues when the replacement format is Collada.

No, the model placement is still done with the GUID in the XML files that are part of your package sources. It might be that the scenario editor GUI has some functionality to update the placement when the name is the same, I don't know since I don't like that editor.

Well I can attest that it most certainly does update placement. I know this because I'd had so much trouble with the model, I decided to abandon the placement, since pushing a model around a tarmac is something I can do. I started over from the Collada, made sure to generate a new GUID, used the same name and folder because why not, but when I opened the Scenery Editor, it was already placed.