MSFS20 MCX Crash on Resize all to multiple of 4

[GaryGB]

Hi Arno:

I am testing MCX with import of a Sketchup *.KMZ 3D model that requires mapped *.JPG texture conversion to *.PNG.

In MCX Material Editor:

[Resize all to power of 2] button works OK

[Save Textures] button > check: Resize all to power of 2 and check: Overwrite existing textures ...works OK to yield *.PNG's.

[Resize all to power of 4] button crashes MCX


On { Textures } tab, 4 textures appear to have a very small pixel array, and cannot be seen highlighted Red in MCX 3D preview


Can this be fixed by any existing workflow using the June 30, 2022 development release of MCX ?

I hope it is possible for you to fix this resizing issue, as MSFS SDK compiler seems to not complete processing of the 3D model.


I will link to a ZIP of the unrestricted use 3D Warehouse Sketchup *.KMZ file (for a private use freeware project) ...via PM.


Thanks in advance for your advisement on how to proceed with this MCX 3D model I/O project for MSFS.

GaryGB

 

[arno]

Hi Gary,

Got your pm, will have a look.

 

[=rk=]

I get that error often with textures that are made using some sort of automated procedure. You'd have to consider that textures that are extremely small in one of the dimensions, say 14 pixels by 27 pixels, could be resized to 2x1, but not to 4x1 and at what point in evaluating proper divisions of these miniscule textures, would the software be entitled to throw up it's armatures in frustration.

My procedure, when I get these errors, is to evaluate each oddly sized texture and proceed accordingly. If it is just a pixel or four, it's gone, like it never existed. Same with 2 pixel slivers that are 21 pixels long, or so, barely worth the time to even type about them. The others, I will either manually resize, recolor them like a tiled texture, or assign to other fates.

I know software created this situation, but it seems too complex for software to solve. I'd prefer, that if you made some sort of algorithm that denied us those decisions, that you'd make it optional please Arno, thanks.

 

[arno]

Hi,

There was a bug in ModelConverterX, resizing to a multiple of 4 could result in width or height of zero for small textures. This model has some textures that are 1x1 or 1x23 pixels in size and these gave the issues. Will be fixed in the next release.

It's typical for SketchUp models to have such a diarrhea of tiny textures. In my view it is just lousy work of the modeller, he/she did not take the time to design a proper texture for the model. Running the drawcall minimizer first is also a good way to get rid of all these small textures.

 

[=rk=]

There are several Sketchup function that shatter textures. One I never use is called "make unique texture," which I believe creates a new texture for each polygon, this is where poor modelling that creates those 1x23 sizes applies, imo. TBH, if you replace those textures with polygon/vertex color, they are virtually invisible and MSFS does not charge any draw calls, for rendering colors. Models created in Maya can be odd. If you zoom in very, very close, you can see that many large faces of polygons never touch, it's very unsettling. Anyway, I think Maya might contribute to the demi-polygon infection we encounter with some communal models, almost like a kind of pox for the content we pass among ourselves.

Use vertex color whenever you can! Microsoft Flight Simulator uses a single vertex format, so using vertex color is essentially free. Because of this, low-resolution LODs often do not need a texture at all.

Landscape Elements

docs.flightsimulator.com

Speaking of which, I'd wanted to make this observation, in relation to the draw call minimizer. Since colors are free to render, taking them out of the minimizer could allow more room for textures on the merged texture file, if MSFS users could have an option to do so, maybe a tick box to leave colors out, like there is one for specific textures.

 

[arno]

Rick, that's an interesting idea to turn colors into vertex colors instead of textures. MSFS differs here from FSX.

 

[=rk=]

It probably should interest people. If models are composed entirely of vertex color, the initial color/texture conversion will add a draw call. If the model is composed of mixed textures and colors, then that "color matrix" texture will have as many individual textures added, that will fit. The software will declare a reduction occurred by as great a factor as there were individual vertex colors, instead of relating specifically to the number of added textures, since MCX does not recognize single vertex format. Any textures that are pushed off the minimizer generated file, due to the presence of the array of texture colors, will add additional draw calls.

I would say, with the way it is, if in doubt, go without.

 

[GaryGB]

Hi,

There was a bug in ModelConverterX, resizing to a multiple of 4 could result in width or height of zero for small textures. This model has some textures that are 1x1 or 1x23 pixels in size and these gave the issues. Will be fixed in the next release.

It's typical for SketchUp models to have such a diarrhea of tiny textures. In my view it is just lousy work of the modeller, he/she did not take the time to design a proper texture for the model. Running the drawcall minimizer first is also a good way to get rid of all these small textures.

Thanks for looking into this MCX crash, Arno.


Will MCX now resample / correct texture pixel arrays that (initially) do not meet MSFS SDK criteria of "Multiple of 4" and "Minimum of 8x8" ?

https://www.fsdeveloper.com/forum/threads/failed-to-convert-texture-during-build.452595/post-882700

https://docs.flightsimulator.com/html/Asset_Creation/Textures/Textures.htm?rhhlterm=8 pixels

Rick, that's an interesting idea to turn colors into vertex colors instead of textures. MSFS differs here from FSX.

Also, is a MCX work-flow feasible- or implemented- yet for Vertex Colors in glTF exports for MSFS ?

I'm thinking if MCX had an option to 'cull' texture pixel arrays that are too small to meet MSFS' minimum size limit into a compatible visual equivalent vertex color, it may improve FPS etc.

https://www.fsdeveloper.com/forum/threads/material-colors-not-displaying-in-msfs.453561/post-890628

GaryGB

 

[arno]

The minimum texture size of 8x8 is not implemented correctly at the moment. MCX will allow 4x4. I'll have to check that again.

As for the vertex colors, MCX can read and write them in glTF. But there is no function now to turn material colors into vertex colors.

 

[=rk=]

But there is no function now to turn material colors into vertex colors.

Maybe MCX could show an alert? It is easy enough to assign a color and delete the link to the texture, but I usually don't even notice the issue, until I get a failed compile. It is true that the texture thumbnails of these slivers look pale, or they look clear with a dark edge, but it is not that obvious, an alert upon loading would inform us to check for them and then we could do the switch manually.

 

[arno]

I am not sure I understand you Rick. Assigning a color in a material and removing a texture is not the same as using a vertex colour. MCX has no functionality now to change or assign vertex colours, it can only import and export them so that they are not lost. To save drawcalls you would have to remove the colour from the material and move it to the vertices.

And nothing of this all is a warning or an error that should show up in the log. It is just different approaches modelers can use, but there is no right or wrong there.

 

[=rk=]

I did not comment "assigning a color to a material," we never referred to materials before MSFS and all they are is combined textures, like albedo/metallic/night. Can one have a colored polygon and a metallic texture? I do not think so, but one can have a colored polygon and material _settings._ I do not believe one _can_ remove color from a material, because materials cannot be made from colors, only textures. However, changing the color from default white 255,255,255, to an actual colored polygon is something MCX does all the time, for me. I remove an assignment to a botched texture placement and color the polygon to sort of match. Are you saying that vertex color is different from polygon color?

The warning we had been getting, is the failed compile. That hang alerted me to check the textures and edit the assignments. Apparently now we won't even get that, the little sliver textures will be included, instead of crashing MCX and alerting us we can remove draw calls by turning those textured poly's, into colored poly's. This means the only way to remove these small polygons moving forward, is to carefully parse any model, looking for odd texture thumbnails.

 

[arno]

Are you saying that vertex color is different from polygon color?

Yes. A vertex color is assigned per vertex, just as the normal or texture coordinate. A polygon color is assigned via the material on that polygon.

The warning we had been getting, is the failed compile. That hang alerted me to check the textures and edit the assignments.

What is causing this packager error? The fact that the textures or too small?

 

[GaryGB]

Hi Arno:

I am testing MCX with import of a Sketchup *.KMZ 3D model that requires mapped *.JPG texture conversion to *.PNG.

In MCX Material Editor:

[Resize all to power of 2] button works OK

[Save Textures] button > check: Resize all to power of 2 and check: Overwrite existing textures ...works OK to yield *.PNG's.

[Resize all to power of 4] button crashes MCX


On { Textures } tab, 4 textures appear to have a very small pixel array, and cannot be seen highlighted Red in MCX 3D preview


Can this be fixed by any existing workflow using the June 30, 2022 development release of MCX ?

I hope it is possible for you to fix this resizing issue, as MSFS SDK compiler seems to not complete processing of the 3D model.


I will link to a ZIP of the unrestricted use 3D Warehouse Sketchup *.KMZ file (for a private use freeware project) ...via PM.


Thanks in advance for your advisement on how to proceed with this MCX 3D model I/O project for MSFS.

GaryGB

Hi Arno:

IIRC, the MSFS SDK Console error did not spell out a specific size issue, but that was my "guess" as to what was happening:

"...as MSFS SDK compiler seems to not complete processing of the 3D model."

You may also see this, if you attempt to compile the 3D Warehouse object cited / linked above in my OP and PM without running MCX DrawCall Minimizer.

Why not immediately process the 3D model via MCX DrawCall Minimizer ?

Because the "Frankenstein Texture Atlas" created by MCX DrawCall Minimizer is proprietary and does not facilitate the 3D model being further modified by the application which was originally used to create it.

Since no 3D modeling application or other viewer (including MCX 3D Preview in 'Advanced Shader Mode') can precisely render an object exactly as it will actually display at run time in a 3D world such as MSFS may generate, we need to have an easy to use 2-way edit feature set, so we can quickly re-load our 3D model source to tweak it, in order to achieve the display we want it to have in MSFS at run time.

Thus, we may need to work with our 3D models in a minimally-processed format repeatedly ...until we get display configured as we want it.

Then we can consider optimizing complexity of Geometry and mapped texture Materials by various methods (including a "final" exported build processed via MCX DrawCall Minimizer).

[EDITED]

BTW: Just under 200 *.JPG mini-texture Materials in that *.KMZ become approximately twice as many *.PNG.DDS and *.JSON files after processed to a MSFS 2.x "extended" glTF ...that does not display in MSFS.

One might wonder if there is an internal threshold limit in the MSFS SDK DevMode Console that, after seeing more than {X} (...texture size ?) errors during an attempted compilation of an 'intended' MSFS 2.x "extended" glTF, compels the Console to not even bother to generate a verbose error message, but instead to create a "half-a$$ed" 3D model compilation that does not actually comply with the MSFS SDK specification, and therefore does not display in MSFS.


And yes... some of us Sketchup users feel that this work-flow is to be preferred over the Blender workflow ...to generate MSFS scenery content.

IMHO, the Blender option has gotten more than its fair share of attention since MSFS RTM; by comparison, the Sketchup MSFS option needs more work if it is to be more fully supported by the MCX 3D I/O feature set.

[END_EDIT]

GaryGB

 

[=rk=]

Yes. A vertex color is assigned per vertex, just as the normal or texture coordinate. A polygon color is assigned via the material on that polygon.

This raises a few uncertainties. First, how to see this vertex color while modelling, it means there are three ways to color polygons, material color, material texture and vertex color and it implies one could have a color material, with a normal map, that seems odd. Also, if material color and material texture were both available in previous versions of the sim and they both incurred draw calls, it seems logical that only vertex color is rendered without draw calls. Is this correct?

What is causing this packager error? The fact that the textures or too small?

Gary's description covers the issue pretty well and I don't mean to hijack with the other draw call questions. I would agree, yes, too small textures and it really seems practical to me, the way Gary describes it, to just ditch these dozens, or hundreds of small textures, find a color, even if just material, it is still only one draw call - find the color, or just plain tiled color texture - or go all the way and pop a vertex color in there - that most closely matches a large batch of these sliver textures and deal with the issue that way, saving many draw calls imo.

 

[rhumbaflappy]

Use vertex color whenever you can! Microsoft Flight Simulator uses a single vertex format, so using vertex color is essentially free. Because of this, low-resolution LODs often do not need a texture at all.

The reason you don't use high-resolution LODs with vertex color, is because to display a crisp image, you need thousands of vertices for a complex image. If you can use a blurry image with lower LODs, then using vertex colors makes sense. Blender has a method of baking materials to vertex colors. https://www.fsdeveloper.com/forum/threads/converting-textures-to-vertex-colors-in-blender.455655/ But we are now wandering away from the OP's original MCX post.

 

[GaryGB]

The reason you don't use high-resolution LODs with vertex color, is because to display a crisp image, you need thousands of vertices for a complex image. If you can use a blurry image with lower LODs, then using vertex colors makes sense.

IIUC, this video by the author of MeshLab may compel us to reconsider what can actually be done using vertex colors:

Blender has a method of baking materials to vertex colors. https://www.fsdeveloper.com/forum/threads/converting-textures-to-vertex-colors-in-blender.455655/

But we are now wandering away from the OP's original MCX post.

AFAIK, Arno's implementation of "per-vertex" colors now makes it possible for Sketchup output processed via MeshLab to be used for a number of purposes that were not possible before.

https://docs.microsoft.com/en-us/windows/win32/direct3d9/per-vertex-color-state


While per-vertex color certainly may prove useful for extreme distance lower LODs in MSFS, we may also use vertex color for AO.

http://wiki.polycount.com/wiki/Vertex_color

"Usage
Vertex color is typically multiplied against the Diffuse Color, colorizing/darkening the color map.

Vertex color can also be used for controlling blends between different texture sets, controlling transparency, providing per-vertex sound effects in response to collisions, controlling which foliage vertices are affected by a "wind" vertex shader, etc.

When used for non-color effects, typically each color channel is treated as a separate monochrome set of values, so for example RGB vertex color can control three different per-vertex effects. Vertex alpha works this way, it is a single channel of vertex color data."

< Hmmm... does that mean we could actually use RGBA to impart (4) different "effects" / 'attributes' in our 3D models ?

>

Although MSFS provides Ambient Occlusion (aka "AO") via the built in rendering engine, perhaps we may still need to simplify high complexity geometry 3D models used for close-up LODs, to create the "appearance" (READ: 'Illusion' without actual geometry beyond a flat Face) ...of greater 'perceived' detail at intermediate distances via LODs that utilize vertex colors providing AO info baked into a MIPMAP of a Diffuse texture Material ...as this proposed work-flow discussed in 2015 ?

https://www.fsdeveloper.com/forum/threads/burn-material-colors-into-textures.435060/post-721332


Consider the following screenies of MSFS default scenery 3D models:

AFAIK, most faux "windows", bannister "pillars", "rough stone surfaces" ...are flat Faces with AO Baked into texture Materials.

IIUC, we would not have AO shadows generated from actual 3D geometry displayed at the above angles to Sun direction via MSFS' lighting engine, so AO skylight shadows are baked.


AFAIK, in Sketchup 2017 et seq. we may be able to "Combine Textures" after we "Make Unique Texture" ...even with PBR Materials.

GaryGB

 

[=rk=]

Gary was preparing for MSFS in 2015!

 

[GaryGB]

Actually, at the time I was seeking a way to Bake AO into FSX / P3D 3D models without Jim Robinson's manual xNormal work-flow.

https://www.google.com/search?q=site:www.fsdeveloper.com+JRobinson+XNormal&client=firefox-b-1-d&ei=LTnTYuL0FMKN0PEP9rmVeA&ved=0ahUKEwiiv9CZuP74AhXCBjQIHfZcBQ8Q4dUDCA0&uact=5&oq=site:www.fsdeveloper.com+JRobinson+XNormal&gs_lcp=Cgdnd3Mtd2l6EANKBAhBGAFKBAhGGABQggVYggVgwwloAXAAeACAAUKIAUKSAQExmAEAoAECoAEBwAEB&sclient=gws-wiz

GaryGB

 

[arno]

This raises a few uncertainties. First, how to see this vertex color while modelling, it means there are three ways to color polygons, material color, material texture and vertex color and it implies one could have a color material, with a normal map, that seems odd.

Seeing them in SketchUp you mean? I don't think SketchUp supports vertex colors. Or do you refer to another modelling tool here?

Also, if material color and material texture were both available in previous versions of the sim and they both incurred draw calls, it seems logical that only vertex color is rendered without draw calls. Is this correct?

No, they still cost a drawcall. It's that you can render different colors in one drawcall by using vertex colors. The color information is stored with the vertex, so the sim does not have to change the rendering state to switch color.