I downloaded the compiled Source model and checked it in Source Filmmaker, and yes, it seems wrong. Then I downloaded the Blender session, copied your QC file, loaded the Blender session, exported a mesh DMX (and changed the QC to load that), and compiled the model, and nothing seemed wrong.

However... You have "$scale 360" in your QC file. It's much better to do the scaling within a 3D model editor instead (so you scale it up to 360x scale in Blender and remove the $Scale line from the QC file). While I haven't tested doing so, I assume that doing that will make the model end up as you want it to, even if you do SMD exports.

Does this issue also happen in Blender? And whether or not it does, please upload the Blender session and compiled Source model somewhere for us to view ourselves.

Please show a screenshot where the propeller bone's axis is visible in Blender, and another where it's visible in Source.

When importing a DMX or SMD file using the Blender Source Tools, the bones of the armature/skeleton have their "tails" at a certain distance from their "heads".

However, this distance seems to be based entirely on the largest distance between two bones (and/or the mesh dimensions), so one model may have the "tails" be 0.5 units away from the "heads" while another model may have them 1.25 units away.


As such, I would like to request a way to set a specific bone "tail" distance when importing (like 1 unit), as I like when things are neat and orderly.


The way it currently works is especially apparent when importing a DMX or an SMD in one Blender session, then a different DMX/SMD in a different Blender session, and then mixing and matching the bones as wanted, as then bones of one DMX/SMD will have a different "tail" distance to bones of another DMX/SMD.

Originally posted by ficool2:

- (both models need to have the same matching bone order) -

This would be a first for the Source engine as far as I'm aware. Are you completely certain that that's true? I don't have a Festive Team Fortress 2 weapon, so I can't really test it myself.

Either way... Depending on how the model is supposed to work and how various QC commands actually work, it might be a valid option to use $DefineBone to define all bones before any SMD/DMX references in the QC file, and/or to have a "special" bone-only SMD/DMX (like an idle sequence/animation file) which is loaded before any other SMDs/DMXes, with the wanted bone order, like this:

What happens if you delete C:\Program Files (x86)\Steam\steamapps\common\SourceFilmmaker\
\game\usermod\models\darknessringo\test\test.[extension] (with "[extension]" being at least "mdl", "dx90.vtx", and "vvd") and then try to compile it again?

Blender's "connected" bones connect along the Y axis of bones. Both the SMD and the DMX format support any rotation for any bone (and are often "chained" along the Z axis of bones, but not always).

This wouldn't really work out if you let Blender "connect" the bones, as you might be able to guess, so it keeps each bone separate when importing a skeleton/an armature. This is completely intentional, or at the very least completely normal.

If you move bones of the armature around in Blender, does the mesh deform correctly in Blender? If it does, then, just to be sure, if you export and then re-import the SMD into Blender in a new session, does it now no longer deform correctly in Blender with non-pelvis bones?

With VTA flexes, the Blender Source Tools have to "assign" each vertex of the VTA to a vertex of the mesh object in Blender for the shape keys to work.
(The same applies to StudioMDL when compiling the model, though it may be better at doing this than the Blender Source Tools is.)

Any difference, even very tiny ones, in the positions of vertices of the mesh object and the VTA file may cause the Blender Source Tools to not match all of the vertices of the VTA to the mesh, and/or match them up incorrectly, in both cases causing some issues with the shape keys.



The only true way to avoid this is to export as DMX with embedded shape keys/flexes rather than SMD with external VTA shape keys/flexes.

Originally posted by W.I.U Simpy.:

Oh, Melons are one object. Is that a problem?

No. Just make sure each melon uses the same material in Blender if you want them to use the same material and texture as each other in Source.