"Importing an animation" problem
DrGonzo62
Posts: 221
Hi,
I have been importing animations into DAZ and then rendering them in iRay for a while now, since DAZ is not really suited for creating complex animations.
My workflow is to create the animation in a third party application, and then import it as an FBX into DAZ. I then save it as a pose preset, instead of dealing with any BVH export/import issues.
Applying that preset then to any G3 character is working very well.
However, I've now run into a scaling issue when applying a pose preset.
2 characters in the scene, one is a bit taller than the other. When I apply the pose presets to the characters, the shorter characters animation is scaled, compared to the full size character.
I have fuzzed with this for a while now and haven't been able to fix this problem. The animation was created with the correct hight of the figures. One is 100% in size, the other is 84% in size.
When I import the FBX into DAZ, the bones of the 2 figures animate correctly. The little clip shows how the bounding boxes of the skeletons move in unison after import into DAZ.
The 2nd half of the clip shows the pose presets applied to G3M (to keep it simple). The taller figure now outruns the shorter one.
Does anyone here know how to fix this? I've even tried BVH export and re-import in DAZ, but the animation scaling remains. Disabling the "Scale Translation" settings in BVH didn't fix the problem either.
If I scale up the shorter figure to 100%, the both animations are matched again.
Any ideas, please?
Thanks,
Kay
(Corrected title to make more understandable. ~Mod)
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Hi Kay
I think this might be an interesting problem to solve, because there are several things going on here, and Daz studio in many ways is not really designed specifically for animation, so it is trying to cope but doesn't know how. Their fbx importer also has some issues (I have a similar workflow, I animate in Motionbuilder together with my mocap system, both facial and body, then export to Daz studio for rendering) , some of which I've entered as bugs, but no resolution as of yet.
If you think about it, two people who are walking side by side that are of different sizes (and 85% is quite a difference), the smaller one, to keep up, will have to either take longer strides, or faster strides to keep the pace, but either way the animation will be slightly different. the first part of your clip does look like it is doing this, but it is hard to tell by the angle and the blockiness and lack of reference (like a grid). I do notice the scaling issue on the smaller character, as you see the feet sliding quite a bit, and the strides are longer, so it is probably applying the pose correctly
I know you probably have done this already, but have you made sure that you've done the following on your g3 characters before applying the saved pose? 1.- select all child nodes, edit, figure, lock, unlock selected nodes, and figure, limits off? Also, make sure you turn IK off on the character, as it will modify whatever pose you apply to it. I dont think any of this will solve the scaling issues, but might reduce some of the other issues like foot sliding a little bit to see what is going on a little easier
Would you be willing to share your fbx file? that way I can test on this end too
Ok, I think I duplicated your problem.. and I have a solution.. I think you might have applied the wrong animation file to the larger character.
This is what I did.. In Motionbuilder, I had both being retargeted by the same character.. with "match source" so they both have the same animation (the shorter character of course has a longer stride) I color coded the small one as blue to differentiate
see here: https://bryan_steagall-hotmail.tinytake.com/sf/MTU1MzcyOF81MzU5MDgy
In Daz studio, I brought both of them in as fbx https://bryan_steagall-hotmail.tinytake.com/sf/MTU1MzczNV81MzU5MDg5
I selected each and saved as pose file (editing the pose file on one of them as it had the namespace from motionbuilder to differentiate them), saving one as small guy, the other as large guy
then I created a new scene with gen3male, one gray, one blue.. now here is where I got something different.. even though I scaled the blue one smaller before applying the animation.. when I applied the small guy animation to the blue character.. it changed the size back to 100% and it gave me the results you mentioned.. https://bryan_steagall-hotmail.tinytake.com/sf/MTU1Mzc2NV81MzU5MTQw
after I re-scaled the blue guy back to 84%.. then the results were what you were looking for https://bryan_steagall-hotmail.tinytake.com/sf/MTU1Mzc3Ml81MzU5MTU3
Hi Bryan,
I'm glad to see that I'm not the only one who is trying to use DAZ for more than just rendering stills.
The imported FBX characters are indeed walking lock step in DAZ, with the correct scaling.
The only way I was able to render the skeletons was using solid bounding box shading btw.
I did unlock rotation limits prior to applying the pose presets, but that didn't solve that particular issue.
Tried disabling IK as well, but - same thing.
It looks like DAZ wants to scale a character to 100% when you apply a pose - even if you turn the scale options off
when applying it!
So when you then rescale the figure after applying the pose, the animation gets scaled as well.
Same when you export/import as BVH. The animation always gets scaled.
I have attached the 2 FBX files.
I sure hope that there is a solution to this!
While I understand that DAZ main focus is on still renders, I at least would hope to have better thrid party animation support.
- Kay
I guess we just cross-posted.. :)
Let me check that out.
Kay
Interesting.. I brought in both your fbx files into mobu.. and took the shot from above.. it looks like they are actually not in lockstep, the larger character is actually moving faster than the shorter one, so what you are seeing is correct.
https://bryan_steagall-hotmail.tinytake.com/sf/MTU1Mzg4OV81MzU5MzY0
I didn't modify anything except give a namespace to one of them to differentiate the bones so I could bring them both in at the same time..
so what it looks like, and correct me if I'm wrong.. you are retargeting the animation of the same movement to both characters? I'm assuming you are using Mobu?
Hi Bryan,
That is strange. I just re-imported both FBX files into MB and they are walking lockstep. There must be some weird interpolation going on between our setups.
But - I think that you had been right! I must have selected the wrong figure when saving the pose preset in DAZ. Not only once - but several times.. Yikes.
I just tried it again and this time both figures are walking lockstep in DAZ.
Thanks for pointing this out to me! :)
Kay
hmm, interesting, . I'm just using the files you gave me, no other modifications..I'm using mobu2014 here's the same shot from the side https://bryan_steagall-hotmail.tinytake.com/sf/MTU1MzkzMF81MzU5NDI2
And this is what I would expect to see.. when retargeting the same source character to 2 of different sizes, mobu will retarget the animation accordingly and it would do this. But I'm glad to be of help!
I'm using MB 2015, so mabe that is causing the difference.
The walking animation was just a test I did after having figure scaling problems in DAZ with a much more complex animation.
I am going to try importing into DAZ again and I sure hope that I just had srewed up a couple of times.. We'll see.
Have you come across any alternatives to rendering animations in DAZ btw? Since I'm running dual GTX 1080 cards I seem to
be stuck iRay rendering in DAZ. No other application can let me render high quality anims that fast AFAIK.
shouldn't be any difference, since the underlying mechanics are the same in all versions, even back to 7.5 when it was still Kaydara, but no matter, it is working for you. With fbx files, I don't remember daz studio asking about scale though, only with bvh files. What type of scaling issues were you having? Different scaled actors or mocap source files to characters can be tricky.. when it is only 1 character, there's no problem.. but once you get more than one.. it can be challenging. That is why in productions they try to use actors with similar proportions to their corresponding characters, so that you don't have to go back and retime/retarget or modify animation to make it match
Nope, not really, unless you want to go with something like Maya..or 3ds max with several render nodes.. although you might try Unreal (I'm looking at that also) I also render with iray.. here's a sample of something I've been working on.. both body and facial mocap
https://player.vimeo.com/video/202399366
That's some good stuff there!
But I'm sure that you still crinch when her hand swipes through the keyboard..? :)
But really nicely done.
The animation I'm working on is the usual mix of handkeyed and mocap. For most parts it is working well, but the problem starts when my characters are walking away from the scene and the taller figure outruns the other.
I'm starting to think that it might be a morphing rather than a scaling issue in this case. The shorter figure has some morphs applied that make him shorter. I wonder if that doesn't translate back, but I have to do more testing.
I have looked into Maya for rendering, as there is now a (pretty expensive..) iRay plugin available. Both apps are not cheap, but I would probably spring for it if DAZ wasn't so much more plug and play. Sitting there for hours creating shaders in Maya isn't my cup of tea. What takes minutes to create in DAZ can easily take hours or days in Maya
Granted - you can take it much further than DAZ, but that comes at a steep price. Monitary and time wise.
Anyway - here're the 2 FBX, re-imported into MB. Walking lockstep. Go figure.. ;)
I ran one more test, and - sure enough - the morphs applied to the shorter figure seem to be causing my "out of step" issue.
The sample scene shows (from left 2 right): G3M scaled to 86%, G3M at 102%, and to the far right G3M with morphs making the figure shorter.
Bummer..
Now I have to figure out how to work around this.
I had a similar problem with scaled characters causing issues with translation offsets and I have a workaround . Basically the problem is the way DS handles scaling inheritance.
The two assumptions are 1) the scaling for your character is based on scaling of the root node 2) you have the animation working in mobu properly as you want it to look (and even if the exported mobu fbx works properly in other programs as-is, you have to use some workaround in DS because of the way it handles scaling inheritance in the hierarchy)
If your character's scaling is based on the root node, and inherits_scale is "true" , the transform properties are compensated for in the node below, and that includes translation. And it sort of makes sense, a "Giant" will take bigger steps than a "Dwarf", thus translating farther . But the problem is if your animation if perfect already, there is double compensation; once already in mobu,and once again in DS. So the "dwarf" travels too short distances, or the "giant" too far
scaling inheritance properties
http://docs.daz3d.com/doku.php/public/dson_spec/object_definitions/node/start
You can't just disable the scale inheritance, otherwise the character will go back to "normal" size. I couldnt find an option in DS to use different inheritance rule options (you want to keep the scale, but not affect the translation)
In most characters, the character translation in the scene is based on the hip bone, which is a child of the root node (eg. "Genesis 3 Female" is the root, then the hip node which is the first real bone) . So the workaround is take the hip x,y,z translation values and place them into the root node above (ie. hip translation should now be zeroed out, and translation is controlled by the root node), so they are unaffected by scaling values in the root node when you are in DS, because they are at the same level in the hierarchy now. Of course, you can do copy/paste keys or animation curves in mobu easily, but if you have keymate you should be able to do this in DS, or in other programs you can just use a dope sheet and copy/paste the translation x,y,z keys. Or even place the values into a null object, which you can use as parent later in DS (character root node set back to 100%, but the parent null controls both scale and translation at the same hierarchy level). But placing the hip translation values into the root in mobu worked for me for those characters who's scaling is based on the root.
Another way might be to "bake" the scale into the character, maybe some sort of ERC freeze , where the root node scale is reset and reads 100%, yet the character is still effectively scaled. I couldn't figure out how to do this
I'm bummed when I read about all these problems with animation in DAZ Studio. I have been tempted recently by Houdini 16. They made improvement to animation along with other things. I'm holding off waiting on what DAZ surprise is going to happen that they teased when G8 came out.
Thanks for your feedback pdr0
I was able to get isues with scaled characters resolved by using ERC freeze prior to exporting. That is when the scale modifier was used on a character.
What I still haven't been able to resolve are scaling issue when a morph (like the G3 "Massive" morph for example) was used and that morph has changed the scale of a character.
Re-importing such scaled characters always results in translation mismatches between different characters for me.
What's driving me nuts is that we are stuck with DS when it comes to PBR rendering.
No other application that I know of (free or commercial) will let you do PBR renders (such as iRay based) as easily and fast as DS.
Today I tried adjusting a fairly simple animation (around 1500 frames) with graphmate, tweaking some bone rotations, and it was absolutely tedious dragging the keys around. DS was almost unresponsive.
I ended up fixing it in MoBu and then re-importing it back into DS for the iRay render.
I would gladly pay for a DAZ Studio app with decent animation support!!!!!!!!!!!!
Within reason of course.. ;^)
RobotHeadArt in another thread posted that DAZ's Iray shaders work in Houdini's Mantra engine as it is PBR. Houdini will work with Octane and Redshift, too.
https://www.daz3d.com/forums/discussion/comment/2802921/#Comment_2802919
Also RobotHeadArt started a thread on how to import DAZ characters into Houdini.
https://www.daz3d.com/forums/discussion/196556/daz-studio-and-houdini-go-procedural
How is the morph actually working or causing the translation issue ? Is it scaling elsewhere, etc.. ? What is different about that morph ? Can you open up the parameter settings and look around, see what other controllers are accessed ?
If it was scaling inheritance issues - wouldn't you just take care of it the same way ? Either ERC freeze, or take the translation out of the hierarchy ?
I suspect the problem is something else, because those are custom morph targets
For rendering , what about blender / Eevee ? Maybe it's still early in development but the demos looked promising
Free iray is nice, but DS's version of iray does not support important things for animation such as DoF, motion blur (yet). I suppose multipass / post work with the iray canvas options might be a suitable workaround
Blender now has a denoising solution which works well and helps decrease render times by decreasing the need for higher samples, which makes it a little more attractive, but it's still challenging to me. I do believe Wendy showed that animated DoF does now work in Iray in another thread, pdr0.
I don't have that massive morph , but I couldn't replicate the translation issue when scaling is based on a morph, not "scale". I tried a few and they all work as expected. Unless there is something different or special about that particular morph ? Maybe it's using morph and scale combo ?
Here is a free G3M morph you can test from sharecg, and WYSIWYG between mobu and the motion transferred to the native DS character. I used your motion test above and they superimposed perfectly between G3M with motion and the FBX with mesh
http://www.sharecg.com/v/86474/browse/21/DAZ-Studio/Megaton-for-Genesis-3-Male
Good to know, thanks!
I'm doing another DS -> MoBu -> DS test right now.
Will post my results soon.
OK, it looks like using the youth morph is causing the problems.
The "Massive" morph only slightly increases the height of G3M, but with 80% youth morph the difference in translation between characters is very apparent.
Same like my video a couple of posts up. The odd thing is that the bones on import into DS are fine, but saving and then applying the animation as a pose preset shows the problem.
Can you be more specific about which "youth" morph ? eg. Which package is it from ?
Is it a custom morph or does it use "scale" ? If it uses "scale" somewhere on one of the nodes, then did you try one of the workarounds?
I'm using the Growing Up for Genesis 3 Male & Female morphs.
And yes, there is scaling going on. I will try to use one of the workarounds you suggested. You've obviously spent some time on this issue, not an easy subject matter.
On a side note - you've probably ran into sliding feet issue when importing a MoBu anim back into DS.
I tried using the mscasual AutoLimp 2015 script on the feet, but it gave me less then satisfying results. Weird foot twisting and such.
Have you figured out how to get foot placement as solid in DS as it was in MoBu?
Very likely that's the reason - scaling inheritance interpretation rules in DS
No I haven't. If the animation is ok in mobu - then it's ok in DS too. Motion transfers perfectly using FBX, merged as a pose preset on the target Daz model
I usually keep the fbx mesh to compare, and you can see they overlap in terms of motion perfectly . That is "minus" the subd differences on the DS model, but you can toggle to base resolution, but that usually won't affect "motion" characteristics unless there are massive subd modelling differences, or very fine motions like the difference between a base finger and a subd'd finger. Or if you footwear that change size slightly when subd'd , that might show slight offset from the ground. But nothing as big as footsliding, assuming there was none in mobu
In MoBu I just tried copying the hip rotation and translation keys to the root node instead, and I delete the TR keys on the hip.
While the anim still played fine in MoBu, the imported anim in DS was a mess. Not sure what I'm missing here.
Sliding feet - I have a couple of idle animations and I used parent/child constrains on the feet in MoBu to keep the feet from moving too much.
And although I plotted everything down in MoBu (do you plot with Unroll or Gimbal Killer btw..?) and disabled the constrains, the characters feet in DS are not
nearly as solidly planted as they are in MoBu.
I'll try to get an anim up to illustrate.
And a quick edit here:
When I just scale a character in DS, then I don't have any issues with offset translations between different characters when re-importing back into DS.
But when there is a morph that is changing the scale (like the Growing Up morphs) that is when I have problems. Not sure if that has come across.
Thanks Kevin - I'll definitely check this out!
T only. Keep the R on the hip
I typically use unroll .
If the plotted skeleton is "solid" in mobu, it should be solid in daz. Look to other reasons for the mismatch, such as forgetting to unlock nodes/ rotation limits off or the scaling inheritance issue
But your workaround was ERC freeze in scale case, did you do the same thing in the morph case with all affected parameters that are linked to "scale" ?
Thanks pdr0,
I'll try that out tomorrow. Makes sense that the scaling issue would show up on translations.
So far I have used ERC freeze only on the scale parameter of a character, so I'll' see if I need to include additional parameters.
It's weird that the imported bones fbx looks fine in DS, but that applying that pose preset to a character doesn't work.
Thanks for your feedback though! :)
But I have cases where the imported fbx bones are way, way off , and yet the end result is a perfect match . I would not make any judgements based on the appearance of the viewport from the "broken" fbx importer; the only thing that works is transferring motion keys
Yes - that did it. Incredible!
Moving the T keys to the root instead got rid of the translation mismatches. Fantastic.
Thanks pdr0!