Improved mipmaps handling

[arno]

I have found the bug that caused the transparent polygons not to show anymore. That will be fixed in the next development release.

 

[=rk=]

Well I just now got it to build. I had to create the comp textures it so desperately craved, then the hardest part was removing that reference to "roofing_shingles_asphalt_n," I did it by first duplicating the texture as "roofing_shingles_asphalt_normal," I reassigned that so that allowed me to open the gltf in Notepad, find any remaining reference to roofing_shingles_asphalt_n and change that to the roofing_shingles_asphalt_c, that I had created to solve this conundrum.

As to causes, I cannot speak specifically, I do know there is a memory buffer that draws from previous builds and prevents improperly applied edits, it may have worked in reverse and allowed the previous version of the model to build, before flagging it the second time, since now that "corrupt" build data was in the buffer, I don't know, I'm just a self taught scenery hack. I can observe that the fact that those texture assignments were botched within the gltf and MCX did not detect them, instead it took my hacker hands with Notepad correct them, says something.

Again, I am just a hack, but logic does not seem to necessarily apply, if the number calculations inside are misaligned from refocusing mip maps, or whatever and the values exceed intended parameters, I'd think you could get sub logical behavior. MCX can easily create a comp texture assignment, just by my clicking "apply," when that attribute is visible in the selection and I would take your word for it that that would be impossible to initiate automatically, but it still does not explain the other odd behaviors. I should advise that I have rolled back the the 1/28 version, until I sort this out or fall too far behind and if similar reports don't start emerging soon, I'll confront that alter ego. Maybe I'll record myself... but he'll just erase it...

Good to know you found the transparency bug, it strengthens my belief I'm not just seeing things.

 

[arno]

Let me know if I find a consistent way in which the extra slots are added, then I can try to reproduce it here as well.

Btw, the issue with the transparent polygons not showing was not caused by the mipmaps changes from last week, that was a bug that was introduced a month or 2 ago when I made some changes to set MSFS transparency settings correctly when exporting from FSX/P3D models. It was just a coincidence that you noticed it after the mipmap changes.

 

[=rk=]

Well I'd noticed it before, still dealing with it in the 1/28 version. For what it's worth, a work around is to use the normalizer, it shows them pretty consistently, but back sides are invisible in the normalizer render. I don't expect to have the issue again, in that I'm not using the mip map update version, you've isolated that particular glitch and I think my models, 3 of them that I know of, were simply "infected." The issue of the duplicate LOD GUID resolved itself after I started reassigning the textures and I've seen odd "nuisance" errors before.
There still is the matter of the extra unnecessary textures, but it can't be more than 5 mb and a few milliseconds of render load, so not a high priority.

The only thing that seems concerning, to me, is that MCX could not interpret the texture slot mismatch that FSPackagetool was having fits over. I'm pretty sure I still have a version of that gltf because I copied it before I started editing toward a solution, if you want it.
The problem for me with editing it, was that I cannot read the gltf formatting. I can find a text string, anyone can. My first pass, I simply deleted that line in the gltf. The problem had been that the normal map was stuck in the comp slot, so I made the new "_normal" map, assigned it in MCX and then deleted the single reference to the "_n," version using Notepad.

That threw a bigger error than the slot mismatch, which is why I made the comp texture, assigned it, edited the "_n" to "_c" in the gltf and it worked. Just got lucky.

 

[arno]

Rick,

I'm not sure I can follow all the tweaks you are making. I would say it might be easier to just remove the texture in the material editor.

If you decide to edit the glTF file, be sure to never just remove a texture from the array of textures. That will mess up the indices that reference to the textures from the materials. You would have to edit the material where the reference to the texture is made.

 

[=rk=]

No Arno, I agree with you, editing the gltf was kind of a shot in the dark. Maybe this can explain better: if you look at the image directly above, you can see the material editor set for "brick_rough_tan" and it has the albedo and the normal texture, just as I'd intended. But if you look over at the text of the gltf file, it shows a "brick_rough_tan_c" texture that I did not create, that MCX does not detect, but forces FSPackagetool to abort. Faced with that, I had two choices, restart from the Collada, or possibly not destroy the gltf and not have to rebuild from the the Collada, by text editing.

It is my belief that MCX should detect the same level of anomaly, as does FSPackagetool and the fact that it is unable to, supports the assertion that it created this bogus comp texture reference in the first place. I'd never made a comp texture until after the software glitch compelled it. I intend to use MCX to remove that "helper" comp texture when I am confident this is all behind us.

 

[arno]

I have tried to export some models here, but I never got the error about the comp texture from the package tool.

If you look in the glTF file in your package sources folder is the comp texture there or is it only added in the package tool output version?

 

[=rk=]

The only reference to the comp texture had been in the base level gltf, FSPackagetool would not build the package.