Seriously, this is killing me. lol. So I use Daz3d imported characters. Took forever to figure out but I got everything setup properly with the Daz to Unreal plug-in provided assets. IK, skeleton, retargeting, blah blah, all that good stuff. But retargeted (and sometime imported) animations still leave The “twist” bones a mess with a mind of there own. In Daz characters it shoulder, forearm, and thigh twist bones.
There has to be a way to fix this, right? Because trying to keyframe fix them is a **** show that usually just makes it worse, and takes forever.
Can they be locked to the angle of the main bone, or a virtual bone? Some type of change, fix, adjustment, Something, or in the long run they are basically unusable.
Honestly I don’t, or didn’t even know there was a difference or specific types of twist bones.
I did notice a difference in hierarchy. In the UE skeleton all the twist and corrective bones are listed under the thigh and calf bones. the Daz skeleton goes straight down the line, thigh, thigh twist, shin, foot, ect…Not sure if that indicates something or not.
I’ve created virtual bones between the thigh bend and shin (for instance) and it shows how much that twist bone is out of alignment.
For Daz3D characters in the AnimBP I usually use virtual bones on the upper and lower arm, so that I can use the TwoBoneIK ( used for realtime ).
I then use the Apply a Percentage of Rotation node on the l/rForearmTwist joints, using the l/rHand bone as the source, and the multiplier set to 0.75.
You do have gimbal lock if the hand rotation goes over ±180, but overall it works nicely.
The hand shouldn’t rotate either way. You probably mean the lower arm.
@ OP
Without further details such as screenshots of what you are looking at, not even the oracle of delphi could aid…
Daz probably (actually isnt it the motion builder or whatever equivalent, which isnt daz?) Manipulates the bones based on an internal algorithm where you have no control.
At export, all the bones should be given matching tracks.
If the bones aren’t following the animation track, then your bone re-target settings are wrong.
Normally, when your animations are good and meant for the specific skeleton, you set the options of all bones to animation scaled.
The fact that in this case they should 100% match the skeleton anyway is superfluos because you could have screwed with the skeleton or have an older version, or worse. Daz could be introducing scaling into the animations…
Regarding the leaf/inline (its essentially BS) stuff.
It only matters to ragdolls.
While you do have 2 bones in a foream, they supinate against each other, they don’t flop at the mid point creating an extra joint.
So, models with more than hand>forearm>upperarm bones in the chain will flop around like noodles when you simulate physics.
The animations for them will still look correct. The problem only sussists when you do interesting stuff with physical animations…
Well animations from daz work just fine. It’s the retargeted ones that are messed up a little. The retargeter is provided via the daz to unreal plugin assets, and the ik chains are already set up. Are you suggesting something is off with the preset chain mapping?
Here’s a pic. this is just the standard manny walk animation. I have virtual bones here, and you can see how far off the twist bones are from where they should be based on the virtual bones.
Has to be a bad retarget.
The bones shouldn’t be re-targeted to anything else other than their matching twists.
Regardless of their physical position.
You can try not retargeting them at all, then set them to skeleton instead of animation scaled to see what happens.
Note that the visual position of those bones is inconsequential.
Unreal will always draw an attached bone between the 2 joints no matter what.
This however doesn’t necessarily mean the bone will move along - unless the skeleton is actually set to link the bones, in that case it will move automatically as well.
The solution to that can be to either retarget it to the thigh and set the settings to skeleton so the translation is kept but the rotation matches the thigh bone - or to open the skeleton in a DCC and separate the bone from the shin/lower leg, making it a leaf bone.
To maintain skeletal parity it is likely better to go with the first option.
To do it right, it is likely better to use a proper skeleton…
Ps, the weight paint and bone structure on this look throughly awful.
Well the root of the problem is Genesis 8< uses parent parent linking for the twist bones. To use nodes like 2 bone IK requires parent child linking so that the twist joint rotates with the parent and not independent to.
The simple solution is Genesis 9 which uses the parent child linking that should work with IK (have not tried yet)
The other option is to just take the G8< rig into a 3d application and change the linking order, which would require re-targeting the animation. This I have tried using Motion Build. You could do the relink in Daz Studio but once again something I’ve yet tried.
Good news the import is getting better as to being compatible with Unreal Engine, considering Daz3D was issued a developer grant to work on it, so it’s just a matter of time in my opinion.
In the mean time I would look towards G9 as it’s made clear that the new design is biased towards UE.
Daz characters have extra bones (ThighTwist and ForearmTwist for both left and right). There are more extra bones there but these do not often show or come in the way of animations.
As for the ThighTwist and ForearmTwist bones, consider these “Animation breaker” bones for Daz characters in Unreal Engine. You should not include them in your IK Solver. If you have attached them as part of your Full Body IK Solver or other solvers, please go into the hierarchy and right-click and “Exclude selected bone from solve”.
This should now make the extra bone stiff as a brick (kinda like locking it in place).
Up to Genesis 8 the twist bones were configured as parent parent so the twist would occur along the axis causing the joint to break. To match up with the Epic configuration Genesis 9 reconfigured the twist bone hierarchy to parent child to match the same configuration used by Epic so that the twist would occur at the joints local transform and allow for correct function of the two bone IK.
If using Genesis then 9 is the option to use as you only need to re-target the animation as the hierarchy matches Epic although using a different naming convention
