Studiomdl destroys lod 0 when $lods are used

[TiberiumFusion]

Details

When I compile a certain model with $bodygroups and $lods, studiomdl fucks up the vertices on lod 0 (and only on lod 0) when at least 3 lods are present. When only 2 lods are present, the issue does not occur.

Demo 1:

Relevant qc: https://pastebin.com/WJCrufsJ Compile result:

Demo 2:

Relevant qc: https://pastebin.com/RENbxB3z Compile result:

Other notes

• SMD vs DMX has no effect.
• As shown in the demos, the model has 4 submeshes in a bodygroup. If I remove 1 submesh so there are only 3 submeshes in the body group, then the issue does not occur when 3 lods are present. I can even add a 4th lod and the compiled model is still fine. Perhaps this means the issue is triggered when the total amount of geometry studiomdl has processed passes a certain threshold.

I am not particularly interested in sharing the model source files if this issue can be diagnosed without them.

Tested Versions

Issue occurs with the studiomdl included with: • x86-64 2021.02.10 • Vanilla 2021.02.05 • Vanilla 2020.08.18 • Vanilla 2020.01.21 • Vanilla 2019.09.03

These versions of studiomdl all produce the exact same result as shown in Demo 1 and Demo 2. See my next comment for additional testing with different results.

[TiberiumFusion]

Additional tests

While testing various studiomdl versions, I encountered different (but still mangled) results.

Demo 3

Tested studiomdl versions: • Vanilla 2019.07.02 • Vanilla 2019.04.30 • Vanilla 2019.02.19 • Vanilla 2018.12.15 • Vanilla 2017.12.19 • Vanilla 2016.12.20 • Vanilla 2015.12.17 • Vanilla 2015.03.09

Relevant qc: https://pastebin.com/gbnYK6GH Compile result:

Key notes

• Compared to Demo 1/Demo 2, this qc is my full model compile with all 5 lods (4 regular + shadow lod).
• Only submesh 3 has been destroyed in lod 0. All other submeshes are fine. All other lods are fine.
• Note that the way submesh 3 was mangled is different compared to the later studiomdls, as shown in my OP.
• When I repeat this test (Demo 3's qc) with any of the more recent studiomdl versions listed in the OP, I get results like what is shown in Demo 1's picture (i.e. lod 0 submesh 2 and 3 are destroyed, all other submeshes are fine). The mangling will be even more pronounced, however (more verts out of place). I suspect this is tied to the difference in geometry between the lowest lod and the highest lod.

Other notes

These tests indicate that between 2019.07.02 and 2019.09.03, studiomdl changed in some way that altered the behavior of this issue. The 2019.07.02 and earlier versions of studiomdl seem to have more tolerance for the amount of mesh data they can process before the issue occurs.

[TiberiumFusion]

Notes on other games' studiomdls

I can already hear rubat typing "this is how Studiomdl has always worked since HL2" so I've taken the liberty of preemptively testing that claim.

Studiomdls that destroy the model

• Gmod (as we've already seen). Has two different studiomdl behaviors as shown by Demo 1/Demo 2 and Demo 3.
• TF2. Produces models that look like Demo 1/Demo 2, not Demo 3. In other words, this studiomdl is consistent with gmod's 2019.09.03 and later studiomdls, but not with gmod's 2019.07.02 and earlier versions.
• HL2/Ep1/Ep2. Produces models that look like Demo 3, not Demo 1/Demo 2. In other words, this studiomdl is consistent with gmod's 2019.07.02 and earlier studiomdls, but not with gmod's 2019.09.03 and later versions.
• CSS. Same as HL2.
• Portal. Same as HL2.
• Left 4 Dead 2. Same as HL2.

Studiomdls that get the model correct

• SFM. But I'm not sure if it produces a v48 or v49 mdl, since my model does not use vertex animation.
• Alien Swarm. Same as SFM.
• Portal 2. Same as SFM.

[robotboy655]

I will need the model sources (if you can create something that replicates the issue, that's obviously fine too) that compile to the problematic mesh if this is to be debugged further. You can send it to me to my email in readme.md of this repo.

It was caused by CS6324 on 22.08.2019. A rollback is not really an option as both versions are bad.

[TiberiumFusion]

@robotboy655 I have emailed you the relevant source files.

[robotboy655]

Well I found a fix, but I don't know what side effects will occur if I push it.

Maybe related issue: https://github.com/Facepunch/garrysmod-requests/issues/1637

[robotboy655]

Added -vpfix command line option to our studiomdl.exe for you to try on the Dev beta. I have restored the default behavior to how it is in HL2/L4D2/In GMod before, as it is clearly better, but I was unable to find the proper fix for this and I have tried a bunch of things including copying over CS:GO's studiomdl almost entirely, (CS:GO studiomdl.exe appears to not suffer from this)

[TiberiumFusion]

@robotboy655 You say "I was unable to find the proper fix", so then what exactly does this new -vpfix option do? If it is not a "proper fix", then what are the caveats?

[robotboy655]

I don't know what sideeffects it may have on the model, that's why its behind a command line option.

[TiberiumFusion]

@robotboy655 When I compile the demo I sent you with your mysterious -vpfix option, the model looks just fine in hlmv, as I am sure you have already done yourself. I have not tested the model in gmod itself, however, and I certainly do not know the proper means and extent to test it for these "side effects".

I get correct models from SFM's studiomdl, and gmod seems to handle those v49 mdls without any issues. Since SFM's studiomdl doesn't require a mystery argument with unknown side effects, I don't have any reason to go back to gmod's studiomdl and use your blackbox -vpfix option.

[robotboy655]

The point is for you to use it on a bunch of models and see if it creates any issues (that being fucked up meshes), but suit yourself.

[TiberiumFusion]

@robotboy655 Ok, I'll add that to my list for the week and get the report on your desk by Friday.

Actually, wait, no, I don't recall being hired by Facepunch to fix your bugs in your game when I bought gmod. I must admit, though, I am surprised you got this far into the ticket before saying "ehhhh good enough" and expecting a user to do the rest of your work for you.

If the point really is for me to do the boring part of your job for you, then just put a check in the mail and I'll get right on with it. I'll cut you a sweet deal at $15/hour.