Improved mipmaps handling

[arno]

It turned out that for all those years the way ModelConverterX handles the mipmaps of textures was not really correct. So in the last version of ModelConverterX there are a number of changes that improve this. These include:

• Mipmaps are read correctly from DDS and DXTBMP files, instead of being calculated internally by ModelConverterX.
• Mipmaps are saved to DDS and DXTBMP files based on the data that was loaded, instead of being calculated by ModelConverterX. This means that if you modified some mip levels that data is not being lost when exporting a texture file from ModelConverterX.
• The Texture Converter form has a dropdown menu now where you can select which mip level you want to see, that way you can inspect the different levels.
• And last, but not least, the preview in ModelConverterX uses the mipmap data correctly now when rendering the preview of the object.

The video below also shows most of these changes.

Continue reading...

 

[=rk=]

I had been noticing the MCX render showing more detail and fidelity, so I was looking forward to this latest improvement, but it appears I might have to learn how to use MCX again, before enjoying it. This latest version displays some textured polygons black. The texture is in the texture folder and when clicked on the thumbnail in MCX, the texture shows fine in the MCX Texture Converter.The image below is a side by side of MCX and Sketchup, with a window of the Texture Converter showing the black texture is present within the model and texture folder as required. The only back side texture is the wall, the SR71 and the bright green tow tug, all show front side polygons, but render black in MCX and oddly only part. I also checked Normalizer levels and there is no obvious differences between affected and unaffected polygons. Please advise.

 

[arno]

Hi,

What's the size and format of that texture? I had this issue initially with parts showing black when I did implement the mipmaps wrong in OpenGL, but I thought I fixed it.

 

[=rk=]

I specifically composed that image to show the image details, 956x254. The issue definitely seems to affect textures that are out of ratio, however I ran the whole thing through the texture resizer, exported to gltf and reimported the same black renders. I did not try resizing to power of two.

I suppose I could get the stable release, resize everything there before running the model through the development version, in the interim. Here is an affected model. It's texture is 1000x400, which I believe is both powers of two and four.

 

[arno]

I'll have a look, probably there is some bug left. 1000x400 is multiples of 4 indeed, but not a power of 2.

 

[=rk=]

Please also review this short segment to confirm the render is what you intend. To me it seems more "cartoonish" than the last version, but what I really notice is that the directional lighting is out of control, imo, well literally. I see no way to turn it off, it is like a spotlight. I start the sliders at 2 and reduce them to 0, with no change in the display. Finally, selecting night mode only changes the background, the models and light render exactly the same. In the previous version, you had the chrome like parts showing reflections and while I would not go so far as to call it breathtaking, it might have encouraged me to confuse the MCX display, with the MSFS render in regard to occlusion and softening some of those cartoon edges.

 

[=rk=]

Apparently our lesson is to never underestimate the "power of 2."

 

[arno]

MCX does not have a power of 2 requirement. So it must be a bug, I'll check it.

 

[arno]

Hi Rick,

There was indeed a bug in the calculation of the maximum number of mipmaps for non power of 2 textures, it will be fixed in the next release.

I can't really reproduce the lighting issue that you mention. When I look at models here they look fine when changing the light direction or the night mode. Does your model has special texture maps, like normal map?

 

[=rk=]

This is straight out of the Collada. It might be more noticeable with all the largest textures black, but with the light on the polys, everything is washed almost white. I have to keep moving the sliders to move the light away to inspect anything.

 

[arno]

The new build is online now.

So with just out of Collada you only have a diffuse texture? Or did you add a normal map as well? If the normal maps shows as black due to the issue it might affect the lighting.

 

[=rk=]

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.

 

[=rk=]

The damage appears to be worse that I'd thought. At this point I am building the package, prior to starting the sim and entering DevMode. The two textures in this model, plus their normal textures, have been corrupted, it looks like material slot assignments have been confused. Since those textures are part of a common library, I get multiple warnings from all the models affected and I'd never seen this much red. I am pretty sure I have clean originals, I might have to recompose the normal textures.

The minimizer has never done anything like this previously and I'm compelled to suggest this is a consequence of recent changes. I've become nervous about MCX, in that many hours of work are suddenly vulnerable in unpredictable ways, it is as if I need to test MCX before letting it play with my children. At least now I know what Chuck Yeager used to feel like.

 

[arno]

I will check if I see issues with the drawcall minimizer, but I don't think it is likely that the changes to the preview rendering affect the mimizer.

 

[=rk=]

Minimizer...I think it had all been part of the issues with the previous build. I'd been getting nervous that this was unrelated to your mipmap work and that was before the ultimate catastrophe. It's all good now, but wait until you see what happened. I got that particular model into the sim as it was expected to be, but I'd forgotten to add a small night light, so I did it right then and there with MCX, knowing that FSPackagetool will build and add a model that has been edited in an active scenery project. When the model reloaded, I found MCX had stripped all but one LOD and it took me a while to figure out how MCX could go about editing geometry.

Altogether, the is extremely erratic behavior; black textures, switching texture names and slots, deleting LOD's, with one common denominator, the mipmap adjustments, which you inform you've fixed. I shut that version of MCX, downloaded the new build and everything works beautifully, great shadow details for a couple of tiled default Sketchup textures. Thank you for your continued work to enable this.

 

[arno]

Hi Rick,

I just tested the drawcall minimizer and the MSFS scenery export here and I don't see any broken things with it. So I don't think the issues you are seeing are related to the changes I made over the weekend.

Let me know if you have other issues, then we can take a look at them.

 

[=rk=]

Arno, I reported that after adding an attached light and recompiling, the LOD models were deleted, please reread my post. I did not operate the draw call minimizer and I did not report that I had operated it as of your first comment about checking it, so thank you for checking it again and I can stop reporting these errors altogether, if you'd prefer. I'll accept that the software works to the level everyone else notices. I am absolutely certain, that MCX was performing unpredictable operations by changing texture slots, texture names and deleting LOD models, but I have far less need to prove such a thing, than I'd have a desire to disprove it, were it my software acting out - the alternative being that I should not be allowed to operate a motor vehicle and must stop my daytime job of remodeling commercial structures on ladders with saws.

Here now, is a pretty significant and specific consequence of recent changes, in that MCX loses all visible attenuation and even visibility of transparent polygons. MCX will normally display levels of transparency, if the polygons are not in a gltf model and sometimes even if they are. At first, I'd though the polygons were just getting deleted, because they are undetectable. I'll show you too.

A plane model, all polygon color:

But that's kind of a lot of polygons, let's see if we can cull some of those with the LOD creator:

but wait now the glass is truly transparent! It does not even highlight, even selecting it in the Hierarchy Editor does not show it, nothing does until we remove it's transparency:

As you can see, this issue arises from a combination of operations, it is not "obvious," suggesting the deleted LOD issue was equally contrived. The idea of missing LOD's and missing glass after making LOD's, does not seem overly contrived, to me. It was actually quite a process to: reproduce this issue, nail down all the exact parameters and then present them in a way that, hopefully, you will detect everything I am sending. I'll leave the rest up to you.

 

[arno]

Hi Rick,

I tried to see if I can reproduce the situation that levels of detail are lost, but I have not been able to do that yet. I assume you had a glTF model with levels of detail that you imported to add an attachpoint. You would have to load the model XML file in that case to load the model with all levels of detail. If you only import the glTF file of one of the LODs, it will not load the other levels of detail.
The only situation I can imagine that happened is that you loaded one of the LOD glTF files and exported it again with the same name of the model that had all LODs. That would overwrite the model XML file and it would only contain one LOD from that moment on. Could it be that has happened?

I can reproduce the issue with the transparent polygons as well. Not sure yet what caused it, I will look into it. If you apply Set Default Opaque and Set Default Transparent material template on the part it does show up again as well (without removing the alpha value). So it must be something the LOD creator changes that makes them disappear. I will investigate further.

 

[=rk=]

Yes, I am aware of the requirement to use the model XML to access all LODs; The only time I ever open gltf with MCX, is when 3ds Max exports and I use MCX to format myself a quick XML, 3ds Max requires a separate operation that takes almost as much effort with less control. The problem apparently does have to do with LOD's and it's back with a vengeance, preventing package builds at this point.

I cannot recall the specific keystrokes that led to this. I am absolutely certain I never created a "brick_rough_tan_c" texture, I am absolutely certain I created a "brick_rough_tan_n" texture, properly assigned it to the "Normal" slot and used numeric values for metallic and roughness. We can see the MCX panel shows no comp texture, yet it exists within the gltf file. A similar case exists with the "roofing_shingles_asphalt_n" texture, I never assigned it to the comp slot, but fspackagetool insists it is misassigned.

The thing is, I don't remember editing the "Fuel Station" model, at all, since the successful build above. To me, this strongly implicates FSPackagetool.exe, or my evil alter ego, over MCX. Still scratching my head over this one and I think it is most likely I compiled it one more time with MCX and can't remember, but all day today up on that ladder with my chainsaw I will be trying to figure it out. Could an OS instability do this?

 

[arno]

I don't think MCX has any logic to assign a composite metallic/smoothness/AO texture when you don't specify it yourself, but I'll double check in the code to be sure.

But if you did not export that model again how would the glTF file have changed? I don't believe in magic and MCX will not alter other models when you export a model.