[SOLVED] StudioMDL messing up weight paint

[Marco Skoll]

I'm having a really irritating issue with one of the meshes for a model (well, possibly more, but this is the one I'm noticing it on). The weight paint is changing between exporting from Blender and when it gets into SFM (this picture shows a re-decompiled version, but the issue is the same in SFM):
http://steamcommunity.com/sharedfiles/filedetails/?id=1149927802
The model weighs in at 4,765 verts and 18,828 tris, with one flex of 320 verts to fix clipping with certain clothes. The weight paint as exported from Blender is already culled to 3 weight links and normalised.

I've tried eliminating potential issues in the QC one by one (disabling procedural helpers, making sure this mesh is used as the reference animation, etc), but the issue persists even if the QC looks like this, with nothing in it other than this one mesh and its materials:

$ModelName "DMF\Vexia\Vexia_TestCompile.mdl"
$Body "Human" "vexia_bodyhuman.dmx"
$MostlyOpaque
$CDMaterials "models\DMF\Vexia\"
$Sequence "idle" "vexia_bodyhuman.dmx"

The weight paint works pretty well in Blender (I've been redoing the whole thing basically from scratch in order to get the model to work its best with Source's weight paint limits), it's just FUBAR after I try compiling it.

So, what exactly am I doing wrong here? I'm not expecting the model to work absolutely 100% the same as in Blender, but this is more of a discrepancy than I'm prepared to accept.

EDIT: Solved. StudioMDL by default culls bone weights of less than 0.05, which was throwing off the weight paint.
episoder came up with an edit to StudioMDL that could adjust this cut off point.

[episoder]

Originally posted by Pte Jack:

Im not seeing that distortion on compile or DMX reimport to blender. Am I blind?

https://i.imgur.com/J67yI05.png

https://i.imgur.com/1hZ8MLP.png

you look at the wrong things. the shoulders have the problem. and lil bits around the neck. you could duplicate the meshes and use the clean .05 method. then tint the duplicate or wireframe the original and you see where the cleaned mesh sticks out / overlays.

you also gotta decompile the model. you'd have an smd. this is where it looks broken.

[Pte Jack]

Doh, and here I thought it was the nose bumping out... (Slaps head insanly)

I see it now...

https://i.imgur.com/XXXMto0.png

[Marco Skoll]

Originally posted by Pte Jack:

added $body "hair" "vexia_hair.dmx" so I would compile the hair.

As my notes said, the hair is compiled as a separate model. It's in the Blend for completeness, not because it needs to be compiled.

From
$Model "SpiderBody" "vexia_bodyspider.dmx"
$Model "SpiderLegs" "vexia_legsspider.dmx"

To

$Body "SpiderBody" "vexia_bodyspider.dmx"
$Body "SpiderLegs" "vexia_legsspider.dmx"

While that's not perfect syntax, it's definitely not what's breaking the model.

~~~~~

It does seem to be the issue mentioned - StudioMDL is culling weights of less than 0.05.

Anyway, through some really contrived whatyamacallit using an SMD file, Notepad++ and Excel (I'm certain it could be done with Python in Blender, but my Python is really bad, so I didn't want to be trying to juggle the maths and the programming at the same time), I've now got a version of the master weight mesh where the values have been rounded off rather than just culled.

It's better, but not good enough - so unless I can find a hacked version of StudioMDL that doesn't indulge in such shenanigans, it looks like it is going to have to be the painful process of repainting it again.

(Still, it will probably serve as a better starting point than just a culled mesh).

[Pte Jack]

Culling of Normalized Weights With Values Under .05

A well kept secret, studiomdl simply discards any normalized weights below a value of .05 and collapses them back into another weight group. This has a huge impact on fine weighting, especially on high poly models where very low weight values are often utilized to keep all those vertices smoothly deforming. Many models you import will have weights below .05, even older games. It may not seem like a big deal, but it is. Depending on how much your model uses low value weights, this issue all by itself can be severe enough to ruin deforms in very obvious ways, I assure you. A few dropped weights here and there usually can be ignored, but if you have entire sets of edge loops using low value weights, there is real potential for serious damage to pose deforms on your compiled model.


From here.... https://www.sfmnauts.com/general/rigging.html#failure-to-normalize-weight-values

[Marco Skoll]

Yeah, sometimes I'm reminded just how much of toilet this engine is. Not using more than three weight links was a pain in the bum I was just getting used to, but if none of them can be less than 0.05 either... ugh.

[episoder]

well... you can't change the bone limit. it's a limitation built into the shaders. but... i found this.

https://i.imgur.com/OApH8lM.gif

should try to compile a studiomdl exe? this source code is 10 years old. :D

[Marco Skoll]

Originally posted by episoder:

should try to compile a studiomdl exe? this source code is 10 years old. :D

Tempting. Where's this source code located?

[Pte Jack]

These are the vertices in your torso that have weights that are less than .05 and greater than 0

for vert in bpy.data.meshes['vexia_UNP_mesh'].vertices:
  print(vert.index)
  for gp in vert.groups:
     if gp.group != None:
       if gp.weight <.05 and gp.weight != 0:
         print(vert.index, gp.weight,)
         vert.select = True

https://i.imgur.com/y834qzK.png

and in the spider body...

https://i.imgur.com/TP3HXiW.png

[episoder]

Originally posted by Marco Skoll:

Originally posted by episoder:

should try to compile a studiomdl exe? this source code is 10 years old. :D

Tempting. Where's this source code located?

somewhere on the internet. google se2007src.rar. and... it even works. wow. first time i got something working out of it. i just compiled a slightly eye broken beta alyx. :D

https://i.imgur.com/ZrH69vr.jpg

[Marco Skoll]

I can't find that specific rar file, but I'm assuming the version of the Source 2007 leak I've found is probably basically the same.

I'll need to get my head around the basics of C++ again (finally, that "C++ for Dummies" book on my shelf might actually see some use), but surely it's got to be a good thing for SFM modelling if we can get a working StudioMDL that doesn't have that weight culling - or at least where the culling is set really low, like 0.0001 or something (so that completely zero values do get culled out for efficiency).

Arguably, I perhaps should still be refining the weight paint a bit to not have the spine weights so far over the shoulder, but that whole process is just going to be so much easier the fewer limitations I have to faff around with.

[episoder]

ohh. i typoed it. it's se2007_src.rar. it only compiles 'compatible' in vs2013 express. it needs older libraries. and i had to run it in vista compat mode. it's old code. it doesn't properly compile dmx either. may need a lot of fixes. it's maybe a nice development thingy like gmod or maybe mod and pack with sdk13. i got no clue. it should actually not work with the steam interfaces tho. maybe i'll test some of it, now that i got something working. :)

[Zappy]

It might be worth taking a look at Cra0kalo's "StudioMDL 2013"[dev.cra0kalo.com], though I don't think the source code of it is anywhere public, and I don't know if it culls weights below 0.05 or not.

Also, Alien Swarm is said to have some of its source code public and such... but I'm afraid that though there are a few mentions of "StudioMDL" in it, sadly there doesn't seem to be any source code of StudioMDL itself in it, the references seeming more about rendering/loading models generated by StudioMDL than generating the models themselves. (The information about StudioMDL here is based upon my own research for, like, 3-5 minutes with the source code.)

But the official Source SDK base 2013 exists, and... StudioMDL's source code is not in it,[github.com] with no official reason behind its removal, with the latest version of its source code from there(?) apparently failing to compile, sadly. If it's worth mentioning, apparently someone from VALVe was asked about it, and that person would try to at least figure out why StudioMDL's source code is not included, but again, there's no official reason behind it, with communication to that person having ceased long ago.

[Marco Skoll]

Originally posted by Zappy:

It might be worth taking a look at Cra0kalo's "StudioMDL 2013"[dev.cra0kalo.com], though I don't think the source code of it is anywhere public, and I don't know if it culls weights below 0.05 or not.

I have taken a look, but I don't currently have a game installed that it (supposedly) works with, and didn't fancy reinstalling them to find out, so I've tried contacting him to ask.

If it still has the limit, I might beg him to see if he will (or even can) compile a version without it.

If not, well... I guess I have been telling myself I should learn more programming languages.

[episoder]

ohh cool thx. i tried to google craokalo's compiler yesterday. it didn't know where. that sure is some different version then what i have. i have no idea which engine branch those avcodec files are from. i only have the portal version of those. and asw doesn't contain any tool code, not even the map compilers code. this git thread got the code from the 2007er version. same that i have. it's missing the compatible old libraries tho. won't compile. you gotta have and build nvstriplib (it errors) and all the systems in my screenshot (except p4lib - it works without it) to get it running.

Originally posted by Marco Skoll:

I have taken a look, but I don't currently have a game installed that it (supposedly) works with, and...

it comes with a full set of engine. shouldn't that work? i didn't bother to try.

and... i'm thinking. if i can figure out how this line of code compiles and i find this in sfm's studiomdl i could patch the value. it could be just an offset and a tweak. :)

[Marco Skoll]

Originally posted by episoder:

it comes with a full set of engine. shouldn't that work? i didn't bother to try.

Durr... Me stupid. Me downloaded only one of the things on that page, then me saw message that need to be for DOTA or CSGO.

Trying properly.. no, it still has the limit.

Well, I suppose the next step is to see if I can beg for a modified version.