Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
+1000
Just an update to confirm that ARP's Quick Rig works like a charm. It took me a few tries to understand it, and get a g8 preset figured out (hint: you must check "Preserve" so that it doesn't change the G8 rig at all, and not check "Connect" because G8s look so good because the bones' centers of rotation are offset, just as in human anatomy).
But like everyone else in the known universe, I am nothing but impressed with this addon and the author's attention to detail. He's like Thomas Larsson. For example, you have to tell it what all the spine or centerline bones are in order for it to set up the IK rig. I was thinking that there is no way it's going to know that the pelvis points down and parents the legs, but it is actually the Hip bone that is the root bone, but the addon just figured that out. Noice :)
So now the actual problem is that the IK rig works, but it is incompatible with I calculate the rotations; I won't bore anyone with the details I discovered through blood, sweat, and tears that DAZ could have clarified in about 3 seconds. So instead of tricking Blender into doing the Quaternion math, I think I'm going to have to do it. No problem, I dig that sort of thing, but who am I kidding, I'm probably going to ask ChatGPT to write it for me, and it probably will do it perfectly in seconds. For the other stuff I asked it to do, it basically told me I was an idiot for not using the OpenGL math library, and I was like "What OpenGL math library?". But it was actually very nice about it. I for one, welcome our digital overlords.
And once that is done, I'll have to go back to my Pierrick Picault classes, because for the purposes of mocap, I don't understand how the source armature and the IK rig can co-exist... won't they both try to constrain the actor armature? I'm reminded and comforted by my favorite (only) Einstein quote: "We are as confused and befuddled as we ever were, but we are confused and befuddled about more important things..."
This is going to be really cool, guys.
@Donald, be aware that in general IK requires quaternions for free joints to work fine (aka avoid gimbal locks), euler is only good for FK rigs.
Not just gimbal lock. They are just generally unstable to calculate and not even conceptually sound: I believe there are six ways to specify each orientation, corresponding to six ways an app can interpret them. I avoided them from beginning to end, and that was the hiccup that took me a long time to figure out. Get this is you can believe it: in the SDK, if you specify a local rotation by euler angles, the angles are relative to the bone's oriented position. But if you specify the local rotation by quaternions, it is relative to the bone's unoriented position, which is aligned along the axis that is the first axis in the bone's rotation order. But I've been doing this long enough now to be used to undocumented things like that.
Thanks for your input, and by all means, please continue point out details that you think might crop up.
I know nothing of the sdk my comments come only from my little animation experience. For euler the rotation order is important because with the same xyz parameters you may get different positions depending on the order, thus the six ways. Blender has similar options too. Quaternion doesn't have this issue by design thus it's only one.
With "six ways" I actually wasn't referring to the rotation order. With a fixed rotation order of, say, XYZ, there are still multiple ways to specify the same rotation because of the implied ranges of each roration, i.e. each one can range from -pi/2 to pi/2, or -pi to +pi. And I thought of another way that Euler Angles are just not methodologically sound: after each rotation, do you do the next rotation relative to the original, un-rotated axis, or do you do it relative to the new, rotated axis? This is yet another convention that send and receiver have to agree upon.
As you say, with Quaternions, there is just one well understood concept: rotation about a vector, and simple rules on how to calculate the Quaternion that performs it.
Euler Angles are important in Aerospace applications because many formalizations of the Coriolis effect are expressed in terms of Euler Angles, and it is indeed from where we even get the term "gimbal" of gimbal lock, but it is difficult to see how any of this is relevant to character armatures.
That's what happens when you let Engineers formalize phenomena instead of mathematicians :)
Wait... what? Did I read this thread correctly. There's a plug in that'll do what I've been punching myself in the sack about for ages, without my needing to do so anymore? Export from Daz to Blender, do animation in Blender, push a button to get the anim back in Daz? Show me. I have wallet on desk.
Still working out some usability issues, but... yes. But it only does the figure, at base resolution, and without hair, wearables, nor JCMs. That's 100% acceptable for me. You need Auto Rig Pro and its Quick Rig addon (well, not really, but why would you not, and I made a preset), and that, together with the Animation Layers addon, is really all one needs. I've only tried it with G8Fs, but it works.
If you're working with mocap, I still don't have a convenient method of correcting bone orientations that doesn't screw up the export back to DS, but keyframers would consider this a full solution, I think.
That's also acceptable for me too. Can I try it?
Of course. There are just a few things I need to work on so that I can be sure that it'll work on other people's systems, a "minimum viable product", and then I'll just post it for everyone who is interested to try out.
Then I'll continue the quality of life improvements and elicit feedback on it. That's kind of what happened with Sagan.
OK.
In my naivety I was playing with exporting animation from Blender to a text file (literally tail bone xyz and euler rotations), then running a Daz script to import them. Then I thought god, it's is going to take days or weeks to work out who's oriented to what, in what vector basis, etc. and decided to give up. I downloaded the Sagan bvh to convert Blender to Daz bvh. I get an error popup saying expected CHANNELS 0 at line 5. So I go and look at the .bvh in a text editor and ... there's a CHANNELS at line 5 (do I need to set a base directory for the convert tab?).
So far I've tried bvh, fbx, Rig-DNS (for Mixamo but should work with any Action I'd have thought), Sagan, Diffeomorphic Save Pose Preset and I don't know maybe some other things I can't remember. I think through all this my conclusion was a plugin that gets animation from Rigify back into Daz, with feet that don't slide, hips in the right position, etc. would be able to make a bit of money.
In retrospect, the BVH converter was one of my dumber ideas. Because nothing is documented, I just didn't realize how dumb of an idea it was.
I have benefitted so much from Open Source Software throughout my life, and enjoyed the sense of community where everyone is invested in the success of everyone else's projects, that I am sure that I will never be interested in charging money for a proprietary solution.
Fair enough. Why did you think the BVH converter was a bad idea though? Any number of tools to establish a chain that actually works is good. It's just so much easier to switch out clothes, shoes and so on in Daz, so I'd love the animation in there. But Daz is terrible at Ik and very slow across its timeline, so you'd rather make the anims in Blender. I'd be fine with a tool that "fixes" an exported bvh.
I don't know if this is any help since you don't own Carrara
but Fenric's pz2/BVH exporter plugin works pretty flawlessly for DAZ studio
Genesis+ figures only do BVH but with G3-9 that includes the facial bones!
maybe studying it and Carrara's SDK may give some insights as to how the rotations are handled
https://www.dartanbeck.com/carrara-zone/carrara-info/carrara-plugins/fenric
Hi Wendy, so I did figure out the rotations. The problem was the way DAZ converts from quaternions back to Euler Angles. My solution was to just not use Euler Angles at all. But then I encountered some more undocumented DAZ stuff in that if you specify the rotations by Euler Angles, they are reckoned from the bone's oriented rest position. But if you set the rotations in terms of Quaternions, they are reckoned from the bone's un-oriented rest position, which is just one of the world-space axes depending on the first axis in the bone's rotation order.
I suspect that the method you say works flawlessly will actually fail for some extreme poses.
What was so bad about the BVH converter is that BVH uses Euler Angles, and Euler Angles do not unique define a unique orientation in space, leaving room for DAZ to misinterpret a BVH file created somewhere else, even though it is "correct". The retargeter that Alex wrote suffered from that. Houdini was calculating the right angles, but DAZ was not taking them correctly. So any solution based on Euler Angles has the capacity to misbehave if it doesn't produce the Euler Angles in the way DAZ likes them. But, orientation issues aside, a Quaternion is a Quaternion, is a Quaternion.
The remaining things I need to fix are actually network related, not having anything to do with DS.
But maybe Fenric will give me some insight into the hidden face problem... thank you for the link.
Donald
Are you trying to use sockets or something, to communicate between the two applications? I had a similar project recently, though couldn't use networking due to the elevation levels of the two programs in a domain environment. Instead I used a memory mapped file and a global mutex for coms to make sure one wasn't writing whilst the other was reading. It was pretty easy in the end. It was C# but these things are wrapping Win32 constructs:
4096,
MemoryMappedFileAccess.ReadWrite,
MemoryMappedFileOptions.DelayAllocatePages,
My_Memory_Mapped_File_Security,
HandleInheritability.Inheritable);
Maybe fewer problems than sockets or named pipes, etc.
Thanks for that.
But no, the networking works fine, I just need to change the method for clients to discover the server. Right now I have the server multicasting its address, and just need to change that so that clients multicast a request, to which the server responds. That's for the initial connection. For the actual data transfer, everything works except for an edge case where the server won't accept new commands until the current connection times out when it should continue to use the current connection for subsequent commands. It's something simple; I'll find it.
And when the client and server are on the same computer, I do have a proof of concept that can transfer data between DS and Blender via shared memory, but neither plugin uses it yet. I'm not even convinced it's even worth it for the amout of data that needs to be transferred. Certainly not for single frames. For Sagan, it might be useful to be exporting the current frame concurrently with advancing to the next, and for LotP, it's just a few kilobytes per figure per frame. Given that I think the Win32 socket layer is smart enough to use a loopback optimization that just copies from one process to the other, I don't think I'm going to use shared memoy at all.
Thanks for the suggestions... hardly anyone ever talks tech with me about either plugin.
So as of this morning I think I've tried pretty much everything to get animation back into Daz. Nothing works. I just want you to know you're the last hope with your quaternion manipulations. So no pressure.
Ha ha, don't worry. Help is on the way.
But I understand that Diffeomorphic can already do this. Have you tried it?
Wait, did I misunderstand what you're actually doing? Is it two-way transfer, or just putting Daz data into Blender? I'm hoping it goes both ways, and that you've learned the required black magic to retarget to a Daz rig (I won't ask what the magic spell was - I once read a blog on all the transforms involved in a standard FBX rig and I lost the will to live by the third paragraph).
Here's a list of what I've tried:
Literally nothing works. It's all broken. Well, either that or I'm so dumb I made the same mistake on all of the dozens of attempts and combinations I've tried. Going the other way, out to Maya, Blender, Unreal Engine, etc. no problem.
if you are prepared to use conversion methods in DAZ studio (and put up with foot sliding) Genesis 1 was the last figure to work with BVH import
https://www.daz3d.com/forums/discussion/250726/so-if-an-animation-is-saved-using-genesis-it-works-on-genesis-3/p1
rather than derail TMITP's thread (unless it's about adding BVH to THE LORD of the Plugins) how to do it as is best discussed in that thread
No, you did not misunderstand. It is two-way. But I was under the impression that one could import via Diffeomorphic, and save it as a preset. People say that it works.
The difference with LotP is that it's literally you press a button to export a character mesh and armature from DS to Blender, and you run a single script to export the entire animation back to DS. I'm not going to say that no black magic was involved... it was a case of trying a million different things until everything worked. What worked was a combination of
1) Using Quaternions everywhere, no Euler Angles anywhere
2) Correctly accounting for DAZ bone orientation, which is aligned with the first axis of the bone's rotation order vs Blender's orientation, which is always aligned with +Y
3) And this one is the one that makes me angry everytime I think about it: If you set a bone's local rotation with Euler Angles, it is from the bone's oriented rest position, i.e. the bone's orientation is offset from that axis. But if you set the bone's local rotation with Quaternions, it is from the axis without applying the orientation. So the fix was to create a "proxy" armature that is constrained to follow the figure's armature, but its rest position is unoriented. It looks wierd, but the quaternions that get baked and sent back to DS are the unoriented ones, because only Quaternions are guaranteed to work correctly, even at extreme rotations. Well, as <> pointed out, that's not even true, as I never did figure out why I hade to negate the w component of all the quaternions.
So no, you're not crazy... you probably just never dreamed that DAZ would do something like have the same setLocalRot() function behave fundamentally differently based on the way the same !@#$ rotation is expressed, and not document it. I don't remember, but the "documentation" for both probably says "setLocalRot() - Set the bone's local rotation" Gee, thanks. For nothing.
But that's the thing: The mathematics of an armature is not difficult at all. It's just a DAG where each edge is a matrix multiplication. I started this task naively thinking it would take a few days, tops. DAZ made it difficult by not documenting adequately critical information needed to make it work. One day I just noticed that a bone's rotation seemed to always be off by what appeared to be about the same as its orientation, thought "Could it be?", and when I created the proxy armature like I described, BAM! every pose started coming out perfectly. I mean perfectly. The way I thought it should and would, about 4 years ago.
And that is why I keep saying that we don't need more features. We need more documentation, and the features will come. I don't know why DAZ can't seem to appreciate how many people are trying to help make DS better and that they should make the barrier to entry as low as possible.
Hi Wendy,
Derail anytime :) Your input is always appreciated.
If I'm thinking about not using Alembic, I'm waaaay past not using BVH :) Knowing now what I do about how DAZ rigs work, I can assure you nothing that I develop is going to ever use BVH again.
My issue with the math was the order of matrix multiplications and the generally terrible FBX file format even with (or especially with) the Autodesk SDK. I used a library called Assimp in the end, which presents kind-of a single interface to a bunch of different 3d file formats. At the time my own engine was OpenGL 4 (this was before Vulkan, DX12, etc.). There's a lot of boiler plate needed to get to animation "hello world" unfortunately and I have a day job, so gave up.
But anyway, I've tried Diffeo (different versions) and I can categorically say animations don't come in correctly at all. It's possible I'm doing something wrong when baking in Blender of course. Unless I have to switch something somewhere before I bake to get the IK converted to FK properly. When I click on each FK shape, I can see a key on every frame after baking however, so I think I baked it OK. It plays back in Blender fine too. It's just the feet slide in Daz and the hip is consistently wrong, so the entire animation is wrong.
I don't understand what content producers are doing to create quality animations and sell them in the store. That's why I assumed there was some secret incantation. Then I saw Daz's own Cascadeur tutorial video on YouTube. I followed the instructions exactly except I just did a 3 key animation moving the hip up and down. Same problem on import. Feet sliding and hip in wrong place.
At least it's consistent!
I don't doubt what you are saying at all. It's all these proprietary file formats where it is impossible to inspect them, figure out what they're doing, and learn from them. It's so simple, I don't understand why it has to be so difficult. But what I understand even less is why DAZ won't officially help.
Nothing FREE perhaps.
one obvious paid solution( RL 3DX or Iclone 8) works with every Daz figure from M4/V4 to G8.1
and the other (MOBU) works for everything including genesis 9.
https://www.daz3d.com/runway-animation-for-genesis-9
When you say "works with", do you mean can import animations back into Daz?