👀

Can't seem to find it anywhere, on Blender 3.3.0, BST 3.2.4
https://imgur.com/a/BB5Quig

Zappy a écrit :

but can't you use math to figure out what position relative to one parent bone would be the same as the original position relative to two parents (baking the animation to just one parent bone)?

That's exactly what the bone constraints are for. The hierarchy is correct, every bone only has exactly one parent. The constraints are for simply applying a transform to that child bone in various ways. There is no re-parenting going on.

So, final bone positions aren't getting written out? At this point I just want to know exactly why Blender's viewport and HLMV don't match up. For what it's worth, I've never even seen the bone constraint error.

Artfunkel a écrit :

Ah, there is actually a specific warning about this:

Bone constraint "foo" found on "object", which already has a bone parent. Ignoring.

Artfunkel a écrit :

It writes out the final bone positions, but the position of your rigid object is affected by multiple bones at the same time. That relationship can't be described in DMX or in SMD.

It's still a child of just one bone, just that there's two "Child Of" constraints. Perhaps you'd want to look at the blend file?
https://pasteall.org/blend/08fa3f4c11c94417969d3a32edb3a513

Artfunkel a écrit :

Bone constraints do not exist in the Source engine. The exporter does its best by making the target object a child of the bone, but only one parent is supported. I expect you are seeing a warning about the object having multiple armatures each time you export?

You must bake this down to a normal skeletal animation if you want it to work in a game engine.

I know constraints dont exist in the engine, I was under the assumption that BST bakes down the frames on export. There is only one armature -- I'm using the constraints within the one armature.

I've got this bone that has two "Child Of" constraints. One to keep it attached to a hand, and another that temporarily turns on to apply a spin.
https://files.catbox.moe/5sskn4.png

However, on export, these seem to go haywire. (Said bone goes upwards)
https://files.catbox.moe/68m00l.png

I'm not sure what might be happening (Constraints being applied in the wrong order? I thought so as well, but looks fine in Blender, no matter what order the constraints are in.)
Its worth noting that everything is 1:1 until the second constraint kicks in, that's when it gets offset incorrectly like that.

Baking isn't exactly an option for me due to various reasons.

Reoxur a écrit :

I use a rigging skeleton which is just a normal skeleton renamed to Valve bones, I use it to auto weight with.

And then I use a script to rename the entire skeleton to something symmetrical with .R and .L
Do the weight painting n such.
Then swap the skeleton back to the sphere bones skeleton.
Auto rename them back.

Mind sharing the script + .blend?

I've asked about this before and yeah, it sucks.
However there are some addons that can import skeletons "correctly".
REDxEYE's SourceIO has an option to "Normalize bones", which results in this: https://files.catbox.moe/89jw2r.png
Which actually looks pretty nice and is great to work with, except like Artfunkel said, it breaks existing animations, so personally it's usless for me to rig things to an existing skeleton. Additionally, the tips of bone chains dont have their proper rotations, (probably because it doesnt know where to put the tip of the bone), as seen here: https://files.catbox.moe/psr6q0.png
Very frustrating.
Maybe one day, through collaboration or something we'll be able to have proper imported Source skeletons in Blender. Until then we're going to have to deal with manually weight painting everything.

See if grey-r's branch fixes the issue.
https://github.com/grey-r/BlenderSourceTools