(Mdlvis Issue) Model texture-shading problem

[Xeryxoz]

Alright, so, I come with a little problem which I've noticed through a little bit of exploring.

My exploration process:
I've taken one of the models from Tranquil's modular wall sets currently on hive so that I may edit a small aspect (It had clipping issues at the screen border, such as disappearing after I've passed a certain extent with the screen's border). Simply calculating extents in the Magos model editor wasn't enough, so I needed to create a 2D plane which would greatly expand the size of the model without adding anything visibly new (I slapped an Alpha texture on the 2D plane for transparency)

Moving on, I saved the model in Mdlvis, calculated the extents in Magos and imported it. This is where the issue happened.

Although the model was no longer disappearing on the screen's borders, the shading of the model was altered. To put it simply, it looked like a gradient which shaded the right side darker. You can imagine how irritating and bad it looks when we talk about a modular set where every single model has its left side lighter and right side darker. If you can't, just imagine 5 short walls placed in a line, each suffering from inconsistent shaders which break immersion.

Finding the culprit:
I've been tracing where the problem occurred by exporting the original and saving the model individually in both the editors, The results:

• Magos Model Editor is clean and hadn't caused any issues for as far as I know.
• Mdlvis is the crowned culprit which altered the shaders of the model, even if I didn't alter anything.

Request:
Now my questions are, how can I fix the texture shading problem and is there a way to prevent the issue from occurring when using Mdlvis?

Example:
I've set a picture up to show the issue; the two-piece on the right side are the models edited by Mdlvis, whereas the models on the left are unedited and what I wish to have.

EDIT : THIS ISSUE HAS BEEN SOLVED

 

[eejin]

It might be helpful for other people if you could explain how you resolved the issue.

 

[Xeryxoz]

It was answered in W3U - The problem persists only when saving with Mdlvis because of automatic tampering with the normals upon opening the model. I heeded the advice from Wareditor and downloaded Matrix Eater 3D. The problem didn't happen while using it. To fix the problem and keep using Mdlvis I'd have needed to tamper with the normals, personally, Matrix Eater suits me a lot better. That's basically the answer - hope it helps others that find this thread.

 

[Retera]

Yes. Typically if I want to do MdlVis animation work, I save a backup, make handmade animations in MdlVis, and then use a Matrix Eater import to the backup to transfer in my custom animations while avoiding the model automatic tampering done by MdlVis.

When I wrote Matrix Eater I tried to make it do as little automatic tampering as possible, because that is annoying. It does modify:

1. The ordering of Materials, because the list is automatically generated to make transferring Geosets between models easy. The generated order should always match Geoset Materials, then Ribbon Emitter materials for the Materials ordering. Duplicate Materials are merged and unused Materials are removed.
2. The ordering of Textures to make transferring geosets between models easy. The order should always be Materials first, then ParticleEmitter2 texture references. Duplicate textures are merged and unused textures are removed.
   
3. The Matrices block in Geosets, because my code-side representation of this information is per-vertex and it only changes back to the MDX layout upon saving/loading (This allows per-vertex matrix assignment in a logical manner, and automerges duplicate vertex groups)
4. GeosetId and GeosetAnimId data on bones and helpers is entirely cleared and recalculated based on an algorithm that I wrote that is nearly perfect. In practice, users almost never understand these Wc3 specific model concepts and they were the cause of inordinately convoluted model bugs where a Geoset would be bound to a bone that was erronously deleted in RAM for performance optimizations, based on its GeosetAnimId/GeosetId settings, causing the Geoset to stretch and contort and attach to nearby models. It is my belief that Blizzard artists did not choose these values, but that they were automatically calculated by 3dsmax for Blizzard original artists as well.
5. Global Sequences ordering will change because these are also automatically computed based on model content to ease the process of transferring animated content between models

Generally, although I *do* perform the automatic tampering with the model listed above, I tried to make it something that users would only benefit from. In my experience, MdlVis will try to remove content to "optimize" the model, which I don't like because I feel like I could lose something in my model. I also vaguely recall it corrupting my models in the past due to its automatic changes. Generally if I want to optimize a model, I want that to be a specific function separate from making it.

With all of that said, you can corrupt a model file in some cases by using a bunch of Matrix Eater functions on it. But I tried not to let my code ever damage a model just by saving/loading. Where this fails is the MDX/MDL conversion. The Matrix Eater was originally MDL only when it was written, and uses an MDX parser that I did not write. That parser lacks understanding of some really obscure format features such as non-static gravity of ParticleEmitter v1 or something like that. So those models would be damaged but generally that never happens because people don't use the obscure features. I'm always working out bugs in it when I use it. If you do "File -> Fetch" and fetch the Blademaster and save it to a file, the dissipate animation changes very slightly and shows the Ribbon Emitter erronously. It's fixed in my newer build but I haven't released that one yet. I believe there is a similar issue if you fetch the Paladin and save his portrait to a separate model. Certain older versions of my code would redirect the camera to point at his forehead.


Edit: if you *want* to recalculate the lighting data (normals) similar to how MdlVis does it, there is a button labelled Recalculate Normals for that specific case in newer matrix eater versions. But it can drastically change models, as you have seen, so for me it is a function to be used only deliberately and only in specific cases.