Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I seem to have lost track of the various claims here. Daz can import iClone animation (via. 3DX - which last time I looked at it was 32 bit and crashed a lot) and Daz can import Motion Builder animation? What I don't understand is how given they'll export in some standard formats like FBX that Daz doesn't "correctly" apply to its rig, or rather its rig is non-standard and there's no information about that outside of it.
I suppose I should try the G1 -> G8 way again. That was the only way to do it before but I'm guessing you have to ignore twist bones and things like that. I'm sure it'll be a disaster like all my other attempts.
OK I tried it. Genesis 2 export to Blender, imported back a quick animation, able to play it back no problem on the genesis 2 figure in Daz. Save Pose Preset, apply it to a Genesis 8 figure and it's completely wrong. So I really don't know what you mean.
@Pickle Renderer
Yes as custom BVH files
That Daz store product (in the video I linked) for G9 was made with Autodesk MOBU
I know this because that Daz PA is a fellow member of the same private Daz studio animation Facebook group as I.
These are not “Claims”
I have been retargeting
Iclone motion to genesis figures since Genesis 1
I made a 90 minute animated film using iclone motion exported as BVH to Daz Studio
and then exported the actors from Daz studio to( my former) C4D for rendering
RL 3DX is gone and its retarget & BVH export functionality has been folded into the 64 bit Iclone 8 apparently
I still have my Old RL3DX6 which I rarely use as I have largely migrated away from the Reallusion eco system
and will not be buying anymore of their software.
I only use ARP rigged Characters (genesis & others) in Blender
ARPS retargeter is world class and allows me to leverage my huge archive of thousands of MIXAMO
and Iclone motion files inside blender as wel as Cascadure and even ragdoll FBX from my 20 year old Endorphin software.
A Genesis 2 pose preset will NOT work on G8
that has long been established.
If you insist on using external Motion data on Genesis1- 8 to render in Daz studio, then you should consider buying an Autodesk MOBU sub or spending the $900 USD for Iclone 8 & CC4.
So you've been using iClone motion exported as BVH in Daz Studio, but you can't have been using Genesis 3, 8, 8.1 or 9, because BVH doesn't import correctly for those, unless you're also doing something you haven't specified in your post. So let's be clear. Which Daz rigs are you applying your BVH to (1 or 2 I assume). And what are MOBU and iClone doing that none of the other options do? Mangling their FBX and BVH output to work with the Daz rig? What precisely are you doing to get animation onto later Daz rigs from these external packages?
@Pickle Renderer
I have used 3DX for Mill4 thru G8.1
for G9 ,You need Autodesk MOBU which I don’t have
This mocap is from Iclone 3DX as BVH to G8 and saved as .duf for distribution
I am chill. I'm just getting contradictionary information. My understanding is that things happen in retargetting with these tools that mess up things like contact IK, e.g. twisting shoulder instead of twist bones in upper arm, etc. So I don't think you could say they support it. Unless I'm missing something of course.
Hi.
To be clear: It works. Perfectly. The way you would think something that is just pure math would. All the DSBS is figured out.
The only thing that I haven't worked out is when you want to retarget mocap, and the source armature's bones are oriented differently than the target armature's bones, because it screws up the necessary conversion because in Blender bones are always oriented along local +Y. If you keyframe with ARP and Animation Layers, this does not matter to you at all.
This is the reason I wanted a live link specifically made to transfer between DS and Blender, that knows all about either one, instead of a generic file format that doesn't know about the foibles of either.
Case in point: it turns out that you have to ignore the rotations of the twist bones altogether because the bend bone's twist drives the twist bone's twist, and the twist bone's bend and side-to-side are both constrained to 0. Setting the rotation of the bend bone configures the twist bone appropriately, automatically. I don't know of any file formats that can be told to do that. But LotP knows all of that. That's why it just works. But just for DS <-> Blender.
As for contact IK, that works fine once it is baked because the armature in Blender is precisely the same as the DS armature. Precisely. The same origins, pre-rotation orientations, and rest pose orientations. Because ARP's Quick Rig is like magic and can apply an IK rig to an existing armature. You lose some of the cooler ARP features, but hey, it's still an IK rig. Once it is baked, it is just local rotations on all the bones. After they are imported back, DAZ can't know how the Quaternions were calculated... a Quaternion is a Quaternion is a Quaternion and it works perfectly.
I can't bring myself to spend the time to make a video or something, but it worked perfectly on an animation with very extreme rotations. You'll just have to see it and be convinced when I'm done. Again, don't worry... it's coming.
What features do you lose? Not that it matters. The most advanced thing I've done in blender is rig a rope to fit a curve from a YouTube tutorial. You don't need to make a video. I understand what you mean. Still seems kind-of weird to me that these file formats make assumptions about vector basis. You'd think they'd include that info.
you didn't read my thread link in the particular the title did you
Genesis 1, one, uno, eins, prima, not 2, 3, 8, and hell no 9
You lose things like automatic heel-to-toe rotation of the feet when a character walks.
It's not that file formats make assumptions, it that they just don't know how to represent an advanced and peculiar rig like a G8. How would BVH know that it's supposed to ignore certain bones because DAZ Studio will constrain them automatically? Especially when at the time BVH was invented, there was nothing like a G8 in existence? All a BVH is is a two dimensional array of rotations. One axis is the bone, the other axis is the frame number. Such a simple model can't possibly represent a G8 with all sorts of crazy things going on to make it deform so beautifully.
Wait, so you're saying it works with Genesis 1?
Edit: Sorry, I couldn't resist. It's time to go to bed.
the poses in DAZ yes Genesis 1 works on Genesis 3
8 with arms moved down 42 legs out 6 with pose controls
genesis 2 poses and animations need to be saved on genesis 1
OK, a small demonstration without Quick Rig.
That was back in Daz from Blender? I was paying close attention to the feet (no, I'm not one of those fetishist people). Looks amazing. She's not ice skating.
It was the animation exported back to DAZ so the JCMs would work, but then in order to render it, I exported it back to Blender via Sagan (which is Alembic) so that it is a pixel-perfect rendition of what was in DAZ Studio. So the comparison is fair.
And even though the bone orientation of the feet is all messed up anyway (because that actorcore armature's bone orientations were different from the G8, and I haven't accounted for this yet is the back-to-daz script. The feet look fine in Blender.), the feet do slide because the bone proportions from the Hip down are different between the two armatures. But that is because the retarget script I use is not a real retargeter and just applies bone rotation constraints, with no math to correct for differences. I didn't bother to apply the Quick Rig IK and do the general work to fix it... that IK works was not what I was trying to demonstrate. The important point, though, is that the feet slide in DAZ in the exact same way the slide in Blender. Fix it in Blender and it is fixed in DAZ.
I chose this particular animation because it was a case where even the Houdini retargeter that Alex wrote, that I'm sure calculated all the Eulers correctly, confused DAZ on import. I wanted to see if using Quaternions instead of Euler Angles would fix the problem. It did. Again, even that problem was a case of a generic tool that just doesn't speak "DAZ Studio" and a specific solution that understands DS's peculiarities is needed.
So what you're suggesting is if you make the animation natively in Blender, with a Simple Rig Daz character imported via. Diffeo, it probably will import back correctly without any loss of fidelity, after baking.
Not quite. The steps I did are those listed in the Youtube video. Diffeo is not involved at all. The precise steps I followed are listed in the Youtube video, nothing more nothing less.
If you wanted to keyframe the animation natively in Blender, the only difference is that instead of running the "pseudo retarget" script, you would use ARP's Quick Rig with the G8 preset I made, that seems to work suitably. The reason why it works is that Quick Rig's magic is that it can apply an IK rig to an existing armature without modifying it, so you have the best of both worlds: a world class IK rig and an armature that still matches the G8 armature exactly and so all the rotations are still correct and the result is no foot sliding, contact points match perfectly, etc...
And please note that I am not "suggesting" anything. You've seen it work now. The Quaternions that get sent back to DS are baked, so how they actually get calculated doesn't matter... it can be via constraints to a source armature or it can be from an IK rig, or a blend of the two. Once it's baked, it has no memory of its state before it was baked, and the Quaternions work back in DS.
After 4 years, I think I finally figured it out. The only real issues are:
1) When retargeting from mocap data, I haven't thought through what transformation is necessary when the source armature's orientation does not match the target armature's orientation. Hence the janky feet. This is not an issue if you keyframe with or without an IK rig.
2) I thought I had it licked, but the twist bones don't quite work like I thought. Notice that, say, the forearms look correct but there is extreme twisting around the elbows joints at extreme angles, even while the pose itself looks correct.
Progress.
If this may help.
Thomas improved the simple IK rig in diffeomorphic, to bake and save pose presets to daz studio. Now feet sliding is gone it transfers back perfectly. The issue was the unconnected bones in the daz rig, that gave problems with IK targets. But we found that connecting them is perfectly compatible with daz poses and the IK issues are gone.
That's not my experience with it at all. I always connect bones. My animations don't import back to Daz correctly still. So frustrated did I become that I just gave up trying and started learning the full suite in Blender, e.g. I do rendering there too. It's a pity because Daz looks way better than Blender, presumably due to subtle differences between the shaders (I don't have the patience to debug shader spaghetti unfortunately). Don't get me wrong, still looks good in Blender. Daz characters just look better with iRay.
Unless there's been a recent update of course (last few weeks)...
It's subjective, but what exactly did you expect with materials that are native to IRay? Cycles and EEVEE are both absolutely capable of IRay level realism. Just look around at what people who know what they are doing with it (not syaing you don't) have achieved.
I cannot see how one can change a bone's head and have it be "perfectly compatible"... will it not be off by a small but perhaps tolerable amount? And the bones are unconnected for a reason. I'll have to play around more with ARP an see if I encounter any problems with IK targets.
Thanks for the heads up, again, Padone.
Point is it's just an awful lot of work to get stuff from Daz into Blender and make it look good. Diffeo etc. may be "good enough" for most purposes however. I imagine use of PBR materials throughout would make it easier to transfer across.
I fixed the feet.
@Donald Because connecting bones in edit mode doesn't add any offset, the rest pose is always perceived as "zero" and the pivots don't change by moving the tails. You can try yourself go to edit mode and change the bone tails however you want then import a pose.
https://bitbucket.org/Diffeomorphic/import_daz/issues/1418/twist-bones-and-snap-ik-fixes-for-the
@Pickle Yes you have to get the dev version it's a recent update. Thomas also added a root bone that exports perfectly to daz so it's easier to position the whole figure.
An update for anyone interested.
At some point in the past, the SDK was updated and the SceneLoaderApp sample code was fixed, so I was actually able to get DAZ Studio to run headless without remarkably little effort. It is great to not have to write a DLL that runs in DAZ Studio's process space and start/stop the entire application, but rather a small stand alone app that does was you want it to, and no more, no less. Since it is no longer a plugin, I thought it appropriat to change the name, and I admit that "The Lord of the Plugins" was not as clever a name as I had thought it was, 30 seconds after I thought of it :)
So, I envision the workflow being this:
You run hitchens, and it will wait for clients to connect to it and ask it load a scene and to serve up certain things, like character meshes, armatures, etc.
I have another program that (for now) runs on Linux, connects to hitchens, and requests enough information to build a character's mesh and armature. It will then run Blender and run the script. There's now enough of a character in Blender to apply IK via Auto Rig Pro's Quick Rig and animate it.
There's also another Blender script to retarget various animations to the character. I've previously bristled at people who refer to just applying bone rotation constraints as "retargeting", it's not, but since I do have an intermediary rig to adjust bone orientations and their offsets, I do call it "retargeting".
And we get to the part that I think is cool: I have another script to run in Blender that will push the animation back to hitchens. The user won't see anything yet, but hitchens will have stored the animation, waiting for some other process to request it frame by frame. This process will be a Blender Geometry Node that I need to figure out how to write, which will get the geometry from hitchens as the frames are requested by Blender. Because it can take a few seconds to switch frames in DAZ Studio, hitchens will cache frames ahead of time, so in practice, it will seem instantaneous (if it takes longer to render a frame in Blender than it does for DAZ Studio to change frames). This is the major technological challenge, but I am emboldened and encouraged by the Blender devs I met at SIGGRAPH a few weeks ago... man, what an awesome and cool bunch of Alpha Nerds... DAZ, please, that is how to build a community, but I digress.
The benefit is that we get the vertex exactness of DAZ Studio's JCMs etc, but with the flexibility to animate in Blender.
As short diversion, I quickly got really, really tired of these ridiculous scene loading times and wrote utility that will go through your scene file and gather all it's dependency files and put them in all in one place, normalize their names so they work across linux/mac/windows filesystems regardless of how sloppily the PA named the files, and then update the content directories to point to that location only (restoring them after hitchens exits). Loading of my test scene went from 3 minutes down to 15 seconds. I just need to port it to Windows and put the functionality as an option in hitchens.
Lastly, also at SIGGRAPH I spoke to Dalai Felinto and Hans Goudey, and I've taken up the task of adding to the Python API the ability to set the individual control points of hair curves. So I'll be an official Blender dev soon :) But jeez, Blender is huge, complicated, and has lots of Blenderisms. But Dalai, Hans, and also Jason van Gumster have been and continue to be incredibly helpful and supportive. Once this is figured out, hitchens will be able to convert hair meshes into Blender's new Hair Curves system.
I think that's enough for now; I'm working on a lot of things and hope to share at least the content gathering portion first.
Damn, that sounds awesome lol. Hope you succeed in this project, could be a game changer