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
I removed it. I don't understand how a duf while would help solving the issue. It's a general problem I've with any morph and any character. In Blender just import a character with the addon, add a custom morph with ERCs, keyframe it between 2 points and put the character in a pose where the hands (fingers) are not in A-pose position. Then apply the script and select the rig and it adjusts. At this point when I start rendering it, the hands clearly deform.
Did you register the script as described in the blog post? That step is necessary to define a handler which is called on frame change.
Yes I did that, it doesn't work. Is it important to save the morph_armature.py script at some specific place? I just put it somewhere random and put it into the text editor and register it.
Does it work in general with animations for you as of now? I tried the newest addon version in 3.0 and 2.93.
Just to make sure: It works in viewport frame to frame perfectly but when I put the character in a pose which is clearly off A-pose and start rendering, the fingers don't move along correctly, making clear that the script doesn't work during rendering.
@surody Providing a test scene is good to make sure we're on the same boat. Otherwise anything can be different or misinterpreted. I just tested the morph_armature script and it seems to work fine here. Test animation included g8f-height.duf. Let me know if it works for you.
steps:
edit. @Thomas When I run or render the animation the armature is not updated unless the figure is selected. But the ERC morphs are correctly applied anyway. Don't know if this is intended or a bug or me missing something, but the animation works fine.
edit. Never mind, it is explained in the docs that the script only affects the selected armatures.
I'm not sure how to use the .duf file but in your test scene the character seems to be in a A-pose. You can't test it like this because a rest pose won't show you if the rig gets adjusted. For just making a character bigger we don't need this tool, it works anyway if the character just is in idle position, A-pose to be specific. I did all steps you mentioned multiple times with different Blender versions, different morphs and characters but the result is everywhere the same. Try a scene where the character is grasping their hands for example and then apply some character morph over time to it.
Edit: Nvm, I know how to use the .duf file now. I'll test your specific case.
I tested your scene now. Like I guessed, it doesn't work and ends up with the same result when I change the A-pose on the hands+fingers slightly. As soon as you get out of A-pose everything deforms. Try importing "Body Morphs" (for example R-Hand grasping), add grasping the hand to your test scene and then render it while having a close up of it.
I repeat again, don't try it with a pure A-Pose.
How do you save an animation containing both the shape and the pose ? I mean, I can save a shape preset with a shape animation, or a pose preset with a pose animation, but I don't see an option to save both together.
I don't understand what your plan is. You can simply load in morphs with the morph panel in the diffeo addon after you imported a blank character without animation or morphs. When ERCs is checked in the addon settings you can load in any morph with ERC data (I assume, because every morph gets adjusted in the viewport that way). It just doesn't work in the renderer afterwards. It technically works for me when I render every frame one by one but I don't really want to press 1000x render for a animation.
Ok I get it now what you mean. Just tried it and it seems to work fine here. I don't see any deformations in the hands, not in the viewport nor in the rendering.
steps:
edit. Sorry it seems I can't upload pictures right now it must be an issue with the forum. Will try later.
Which Blender and Diffeo version do you use?
I followed what you did and I can see what happened in your scene. The rig got in a adjusted state at the end of the animation and in the beginning in a state where the rig isn't aligned (in the renderer), making the deformation basically not visible because at the start the character is in a normal A-Pose. Please follow exactly what I suggest and you will see the issue:
daz studio 4.15.0.2, blender 2.93.5, diffeo 1.6.1.0678
Well as I understand it JCMs and ERCs, as well as any daz animation, requires the rig to be in rest pose to work fine. So you have to start with the rest pose. Unless I miss something. May be @Thomas can confirm this.
Below an example at frames 1 and 30, starting from the rest pose. Please note that I made all bones posable so I can animate the fingers that would be otherwise driven by the morph. Both the viewport and the rendering are fine here. In this case the grasp morph is relative to the pose I stroke at frame 1, but I see no deformations.
I use the daz rig since mhx and rigify can't support ERCs.
edit. As for the grasp being relative to frame 1, this is the same in daz studio if you strike a pose.
steps:
I can see the deformations if I don't register the script, when I close and reopen blender. But this is expected you have either to rerun or register the script for it to work fine. This is also explained in the docs and remarked by @Thomas is his answer above.
https://diffeomorphic.blogspot.com/2021/09/morphing-armatures.html
I can also see the deformations if I don't select the armature. This is because the script only works on the selected armatures for performance reasons, this is also explained in the docs. I don't know if @Thomas may want to provide an option to make the script always affect the whole scene.
In any case you just have to save the scene with the armature selected and the animation will work fine when you reopen the scene. Or select the armature after reopening the scene.
I was going to say the same thing as Alessandro, because it worked for me. Until it didn't. Not sure what happened, although I suspect the registration of the application handler went wrong. Will investigate further.
@Thomas Works fine for me here. If it may help I always install by hand overwritng the "import_daz" folder, so I don't have different names for different versions. It seems the easiest way to me. Also I don't move the script from its original location. Don't know if this matters.
Oops, I deselected the armature.When the armature is selected, morphing it works again.
Only selected armatures are morphed for performance reasons. If you have a scene with several characters, only those that need to be morphed should be selected.
When the armature is deselected and hence not updated on frame change, my animation runs at 25 fps. When I select it, the frame rate drops to 10 fps. And now I noticed that if I hit the script execute button (right triangle) a couple of times more, the frame rate drops even further, down to 1 fps. Apparently a new handler is added each time the script is executed.
@Thomas Multiple handlers shouldn't happen anyway, if we register the script it only runs once on loading. But this may be a useful note in the docs.
I tried to write to you in a personal message, but it seems that it does not work. Could you tell me what problems I have (see the picture) When the button is pressed, the export produces such a message. Blender 2.93
Strange. I have never seen this problem before, and it is code that is used all the time. According to the docs https://docs.blender.org/api/2.93/bpy.types.ColorManagedInputColorspaceSettings.html#bpy.types.ColorManagedInputColorspaceSettings the possible color spaces are [‘Filmic Log’, ‘Linear’, ‘Linear ACES’, ‘Non-Color’, ‘Raw’, ‘sRGB’, ‘XYZ’], cf. picture, so ‘Non-Color’ should be legal. This corresponds to the dropdown list in the texture node. Perhaps some image formats only allows for color spaces in ['Linear' 'sRGB'], or perhaps something else goes wrong.
Anyway, the problem should be gone in the latest commit. If assigning ‘Non-Color’ as color space does not work, the plugin attempts with 'Linear' instead.
I did a clean 3.0 beta installation, removing the entire 3.0 folder with all addons etc. and just install the daz importer. Same issues.
Here's a video to show that I did everything in the docu and that it works in the viewport just fine, just not in the renderer:
https://www.dropbox.com/s/rlaff8cy31tdgeo/MorphTest.mp4?dl=0
I'm not sure if that tool has some specific limitation and my morphs don't work with but since it works in the viewport already it should work in the renderer, right?
Is there a way to have more direct contact to you like Discord to speed this process up a bit?
If you did any modification to the figure, as adding a new cutom FBM you did yourself, then you have to save as support asset for it to be imported in blender.
Yes, I'm aware of that. When I create a new morph in Daz, I adjust the bones, ERC freeze and save them like that. If I wouldn't do that, the viewport adjustment wouldn't work either most likely.
Then if the issue arises only with some specific morphs you did yourself, you could provide one morph to test in a daz installation package, that's a zip with the daz folders to write in the content library. This allows to install your morph in daz studio and test it both in daz studio and blender.
I've the issue literally with every single morph, official Daz products too.
I tried it now on my laptop with a clean Daz+Blender+Diffeo installation. Same issue.
To me it looks like a registration problem. If you type
in Blender's interactive console, does it return a list with the single function onFrameChange? If the return value is the empty list [], the handler has not been registered for some reason.
This is what I got:
On my laptop with clean installs and a new scene it looks like this (still doesn't work in the renderer):
As we discovered earlier in this thread, executing the script repeatedly should be avoided, because each time you run it a new copy of the function is added to the handler. Better just to register, save, and reload. You may need to restart Blender to get rid of the excess functions. I will rewrite the registration code so unnecessary copies are removed.
However, multiple copies of the handler function should only slow down frame change, not make it stop working. Perhaps they interact in some way with the other functions. Do you have the same problem on your laptop?