I think that it's less so "bone weights" being wrong and more so that multiple vertices weighted to different bones are joined together.

(The SMD mesh format stores each triangle separately from the rest, and then it's StudioMDL's/a model importer's job to stitch the triangles together correctly, which the Blender Source Tools might go a little overboard with, however it's usually fine when there aren't "supposed-to-be-separate" vertices that touch each other.)

Sonario648 lähetti viestin:

-
$JiggleBone "LHairB2"
{
is_flexible
{
length 9
tip_mass 40
pitch_stiffness 120
pitch_damping 7
yaw_stiffness 120
yaw_damping 7
allow_length_flex
along_stiffness 100
along_damping 0
angle_constraint 39.999999
}

$JiggleBone "LHairB3"
{
is_flexible
{
length 9
tip_mass 40
pitch_stiffness 120
pitch_damping 7
yaw_stiffness 120
yaw_damping 7
allow_length_flex
along_stiffness 100
along_damping 0
angle_constraint 39.999999
}
}
-

You have two opening curly brackets ( { ) for "LHairB2", but only one closing curly bracket ( } ). There should be another closing curly bracket before the $JiggleBone "LHairB3" line.

Sonario648 lähetti viestin:

I've triple, quadruple, and sextuple-checked. The materials are attached to the mesh.

Then how come that the eyes changed appearance in Blender when you removed the "tr0010_00_eye_col" material in Blender, suggesting that they were previously using that material and then subsequently auto-assigned to the "tr0010_00_body_col" material when the former was removed?

Artfunkel lähetti viestin:

Don't hold your breath. I can add name remapping on export to work around this, since long shape key names are a hard requirement.

That sounds nice. The problem is just that it's less intuitive than if Blender's shape key names were allowed to be longer.
(But it's of course still better than nothing; I've run into this issue at one point too, when dealing with lots of concurrent corrective flexes, so a workaround is nice and appreciated in any case.)

Pte Jack lähetti viestin:

- I have no idea how this can be fixed. -

Blender is open-source (I think). One could make a self-made build of it with the shape key name length increased (it's hopefully just a single value that'd need to be changed... followed by then going through the trouble of actually compiling it...), or even make a merge request (along with an explanation about "why"), or at least a suggestion, for it to maybe be increased in official builds.


(The "self-made build" option is probably pretty unfavourable, since it'd only apply for you, and you only, plus whoever you'd give the special build. It's still an option, though.)

Yes.

{"RB"}</Ben> lähetti viestin:

help I can't import or export .smd format ... - I get error

Please show us a screenshot of the error.

xDShot lähetti viestin:

Or explicitly define these keys in controller block

Doing so can create flex controllers* with underscores, yes, but I don't think that shape keys* may have underscores in their names if you don't want them to be "corrective" flexes.

* A "flex controller" is the slider that you interact with in Source Filmmaker. A "shape key" or a "flex" is the thing that a flex controller sets the intensity of.

A shape key name of "upper_lid" in Blender means that that shape key will be active when both the "upper" and "lid" flex controllers are used in Source, if exported from Blender as a DMX model. The same applies to any other shape key names featuring underscores.


If you don't want such "corrective" flexes, either replace the underscores in the shape key names with hyphens or such (e.g. "upper-lid" instead of "upper_lid"), or get fully rid of the underscores (e.g. "upperlid" instead of "upper_lid").

Rectus lähetti viestin:

- Not sure if Blender has any interface for editing per-vertex floats, -

It does, being vertex groups or such.

While primarily used to rig mesh to an armature (at least when it comes to Source stuff), they can also be used for other purposes (such as setting how much "left" or "right" specific vertices are when it comes to stereo shape keys for DMX exports for Source, or what the per-vertex value of "cloth_enable$0" should be for DMX exports for Source 2).