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
Are we dicussing a different issue? I am talking about c4d slowing down to an unworkable crawl when adjusting pose morph sliders on a basic export using bridge, not about file size.
No no, it is the same issue. You see, C4D handles .fbx imports reeeeeeeeeeeeally stupidly by default. Instead of bringing in pose morphs as simply coordinate deltas by default like Blender does, it generates an entire new copy of the mesh PER MORPH, which bloats the file, causing the crawl. I don't know the exact math behind it, but processing the difference between the points of two complete meshes is a lot more taxing than just looking up a point's coordinates in a table of states.
If you convert these mesh copies BACK to a coordinate delta, aka a standard morph (as in the tutorial I am currently writing and will post tomorrow-ish), the bloat is eliminated and the crawl disappears..
Yeah I am 100% interested in this @ mmdestiny. We only need the deltas anyways and not the full morphs. It is silly to keep all the data especially with additional items and JCM data for these aswell.
And thanks mxo, I was actually asking around on c4dcafe and c4d rigging dojo discord for some script that does exactly that. So this saves me alot of time. Do you have alot of experience with python and the c4d API? I would love to have someone around to exchange with since I want to go more into that area aswell. Been doing alot of mel in maya for small helper scripts through the years but never really used much scripting in c4d, even though it is my main 3d application.
I will take that script and adjust it for G8F. Might have almost the same jcm structure so probably not too many changes needed.
Oh, before I forget. To make it all work perfectly, we would have to also create an automatic joint alignment fix script, because right now the axis alignments are all wrong due to c4d bruteforcing the world axis 0 0 0 alignments on each joint instead of the ones that are used in DS.
Finished the tut quicker than I thought I would. In this tutorial, I explain how to eliminate the massive file bloat that C4D's fbx importer creates. When C4D imports a DAZ fbx, it imports every single facial morph as a target MESH instead of a collection of point deltas (a "standard" pose morph). This bloat in turn drives pose morph slider performance into the ground, not to mention gives you a ridiculously and unnecessarily large file.
The test file this time went from 3.06gb to just 25mb (!!!!!) That's a 99.2% reduction!
Hope this proves useful to everyone. I would recommend saving a backup copy of anything you try it on until you get the hang of it and are sure you are happy with the results. You want to be precise since you're deleting things, after all.
EDIT: (Updated image to include a step that will affect those of you who don't convert every morph).
@ mxo : I have setup everything, correct data types etc I assume (link for the two objects, string for the Prefix). But you forgot to mention that you are not using HPB but instead XYZ?
Also I noticed that we need some additional logic in these bindings, because some of the morphs have more than just a zero to hundred percent range. The shins and the forearms both have extra keyframes in them. So for example on the forearmfwd we have the larger morph to 155 go straight up but the smaller one only goes up to 100% when it reaches 75 degrees, and then goes back down to 0% when it goes from 75 degrees to 155. Not sure if there is a way to simulate this with the vector method, but we might be able to add some if cases into it that reverses the logic when the rotation value goes past a certain degree.
The relative vector linking somehow does not work with the auto rig created by the daz bridge. I added the auto IK to it and it does not take any effect because the joints themselves are PSR constrained to the autogenerated (pink ones) FK joints and the values on the original figure joints are zeroed out due to it, so the python method does not properly fetch the rotation values out of these. Maybe there is a way to still get the correct data, but right now it probably just looks at the data field value and this stays at 0, so no joint weights get set to anything other than 0.
ah damn @ mmdestiny, you are right. I completely forgot about this. C4D strangely only seems to save the morph deltas when manually dragging it in. Always found this super wonky. Thanks for reminding!
Sorry!
I wanted to provide example file but didn't want to post all that purchased content I got in my scene.
I made one with Gen3. I hope Gen3 is ok to post here (its free!), sincere apologies if I am violating anything, its for science.
Attached file is 2.5mb but unzips to 320mb containing c4d scene that works. The tag only works when animation is playing.
The part of the script in main: applies all the morphs, I have not checked if its all correct yet, axis may be wrong on some of them.
Thank you, this reduced the 320mb file above to just under 8mb. I'll do this for all my exports from now on.
Unfortunately it has no effect on Cinema4D performance - sliders are still very unresponsive when there are a lot of posemorphs. I think Maxon needs to revisit their pose morph implementation.
snip: double post
I put together 2 small files which contain the working scripts for both g3f and g8f, including the properly aligned joints for g3f and g8f. Note : the g8f one might not work 100% because I was lazy and simply used the g3f joints and rotated the shoulders 45.75 degrees down, and the thighs 6 degrees outward. So you probably need to change the feet if you want the exact same behaviour of g8f feet :)
For g3f however, it should work perfectly fine. For proper g8f joints, simply replace them with the original g8f joints from that area and manually align them.
The way you can replace your existing joints with these is this :
- Select your G8F shape node. Then open the commander and search for save weights. Execute this and save them into a place you can find later on
- Disable the skin tag
- Delete the original joints from the scene
- put the new joints into the scene
- Select your weight tag and open it in a new attributes window
- CTRL Click your new joint structure to expand it completely, then select all of the joints and drag them into your Weight tag window where the joints are then being listed
- Select the G8F Shape node again, open the commander and this time search for "Load Weights". Execute this and load the file you saved before, to load the weight data.
- Enable the Skin tag again
IF you did it correctly, you should be able to now move the mesh exactly like before, but with a different set of joints.
Below you can find the joint structures with proper alignments at least for G3F, the G8F one is not perfectly done, but will work for the main joints apart from the feet, since g3f and g8f differ on those.
https://www.dropbox.com/s/0ueki6wpfon1gts/g3f_g8f_joints_aligned.zip?dl=0
Hi!
I cannot import into Cinema 4D any figure to which I have added hair. The bridge window stays at "Please wait ... Importing" Has anyone else had this problem?
No, I'm afraid it isn't OK to share the file.
If I understand this correctly its something like this?:
forearmfwd.X maps to morph from (0 to 75) as (0 to 100) and then (75 to 155) as (100 to 0)?
If that is the case, I think script needs a two step map then. I can add it, do you have the list with all these mappings? When I wrote it I was guessing.
Also all of these are linear, I have no idea if Daz uses curved translations. This can all be added, but I'll need a reference to how Daz does it...
Yes you are correct.
The property editor allows for setting of your own keyframes so it IS possible that you can set these things in very complex ways, but I cannot remember any of the morphs on the more modern figures having more than the upwards and then downwards increase.
Btw perhaps you don't know this but you can export the rotational values by clicking the maya helper scripts on the fbx export and this will generate a <exported_fbx>.mel file in the same folder as your exported fbx which contains all the rotational values for each of the jcms. The script can be directly ran in maya to link up the rotations but we can use it to put the values for C4D since they work for us aswell.
My initial idea from that was to create a parser with python, which goes through the helper file and looks for trigger passages and then basically takes the values for the joint, the axis, the morph and each of the values into variables and then creates expresso rangemappers with the values and links these to the correct rotations for the joint axis and the morph on the posemorph tag. I am not sure if this would be slower than the direct evaluation through python which we got now in your script, but the rangermapper allows for using curves which might come in handy if there are more complex custom jcms from third parties. I am just not yet very comfortable with the c4p scripting api and python in general, otherwise I would have already done it :)
These are the values from the mel file, so you can use them to put into your script :
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_R -v 0 -cd Genesis3Female|hip|pelvis|rThighBend|rThighTwist|rShin.rotateX -dv 0;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_R -v 1 -cd Genesis3Female|hip|pelvis|rThighBend|rThighTwist|rShin.rotateX -dv 70;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_R -v 1 -cd Genesis3Female|hip|pelvis|rThighBend|rThighTwist|rShin.rotateX -dv 110;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_R -v 0 -cd Genesis3Female|hip|pelvis|rThighBend|rThighTwist|rShin.rotateX -dv 155.5;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_L -v 0 -cd Genesis3Female|hip|pelvis|lThighBend|lThighTwist|lShin.rotateX -dv 0;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_L -v 1 -cd Genesis3Female|hip|pelvis|lThighBend|lThighTwist|lShin.rotateX -dv 70;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_L -v 1 -cd Genesis3Female|hip|pelvis|lThighBend|lThighTwist|lShin.rotateX -dv 110;
setDrivenKeyframe -at Genesis3Female__pJCMShinBend_90_L -v 0 -cd Genesis3Female|hip|pelvis|lThighBend|lThighTwist|lShin.rotateX -dv 155.5;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_R -v 0 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|rCollar|rShldrBend|rShldrTwist|rForearmBend.rotateY -dv 0;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_R -v 1 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|rCollar|rShldrBend|rShldrTwist|rForearmBend.rotateY -dv 75;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_R -v 0 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|rCollar|rShldrBend|rShldrTwist|rForearmBend.rotateY -dv 135;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_L -v 0 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|lCollar|lShldrBend|lShldrTwist|lForearmBend.rotateY -dv -135;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_L -v 1 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|lCollar|lShldrBend|lShldrTwist|lForearmBend.rotateY -dv -75;
setDrivenKeyframe -at Genesis3Female__pJCMForeArmFwd_75_L -v 0 -cd Genesis3Female|hip|abdomenLower|abdomenUpper|chestLower|chestUpper|lCollar|lShldrBend|lShldrTwist|lForearmBend.rotateY -dv 0;
I don't think there are more of these. Everything else seems to have a simple linear a to b connection. And on g8f they have normalized this into all of the base jcms having these linear a to b connections.
Just keep in mind that you will first have to unhide the jcms that you want to export, otherwise the exporter will ignore them.
I noticed another one regarding Redshift: DAZ plugs the normal textures into a bump node. That is correct so far. But the bump input map type is set to "height field" instead of "tangent space normal". So you need to go into every shader that uses a normal map and correct that.
DAZ should address that and set the map type to the correct one when we click "convert".
I would say from multiple hints that the people coding this do not have much knowledge about Redshift.
Ok here is updated script:
https://gist.github.com/maxenko/10a8472aafe8adc1b3be96f8090700fb
I only applied it to the pJCMShinBend_90_L and pJCMShinBend_90_R, if you end up mapping the rest for gen3/8 please share or edit the gist itself. I intend to use this script in the future if Daz Bridge doesn't offer this by default.
One thing - there is dead space between 0-70 and 110-155.5. So I mapped it 0-110 instead (line 256,257)
I think this is where the curve thing might come in handy. To be 100% perfect, this gets hairy quick. Basically you'd have to define curves in UserData for each of the morphs that need them and then reference them as last parameter on utils.RangeMap(..)
https://developers.maxon.net/docs/Cinema4DPythonSDK/html/modules/c4d.utils/index.html#c4d.utils.RangeMap
Regarding loading weight maps from maya file: its totally doable, and if you're concerned about loading the file each frame, you can always restrict to updating it from disk on first frame only. I don't blame you on not using Python in C4D, although everything is exposed - its very documentation reliant and unintuitive (at least to me).
Thanks for this tip. As a relatively low technical knowledge animation amateur I found this very helpful. I knew the file bloat [good way of putting it] was due to morphs but had no idea how you might rectify and still use DAZ morphs. There is a lot of good information here which I am trying to stumble through. Thanks to all contributors for lending their minds to the forum.
Another thing you can do is that once the imported absolute morphs are converted to relative morphs this allows you to save them to an external file and they can be loaded when you need them so they don't use any memory at all until you actually need them.
I exported Stonemason's Frontier outpost. What a mess. The export script said that multiple instances need to be converted to geometry. After importing into C4D multiple of the buildings where at completely different places than in DAZ.
In theory this would be great tool – and a big chance to daz to extended the community more into the pro-league (C4d, maya, Redshift, Octane etc.). But to become a tool, it needs to run. It simply does not work yet. Please take that as constructive feedback:
Here the main poin points:
– Not intuitive, self explaining and not user friendly. An export should simply export hthe scene, make it transparent where the exported data goes.
– The Cinema 4d Brdige does not give any feedback to users about the import stadium. ("Please wait ...importing)
– Most "hair" included imports did not work: no results after hours of waiting.
– If hair did import it was horrible displayced.
– The files have been about 3 to 6 Gig – a rediculous high ammount for only one character in the scene.
– Setting a key or a morph change manualla took half a minute each – laging and not intuitive at all.
The here provided solution of bug fixes, reprogramming code and published scripts are very honorable to those who did the job. But it should be Daz, who should provide a "final" running Plugin. Again, its great to have a free plugin, But greater is a free running one. ;)
This is an expermiental beta, I think. An update should fix all the problems and customers should be notified when it comes to a "final realease". Grateful and looking forward for this ;)
Hi,
I have an issue with the plugin. When I export from C4D Bridge, the resolution of my model is a lot lower ("poligony" nose, weird wrists articulations) than when I export in .obj. Does anyone have an idea on how to fix this? Thank you.
Wrist articulations are because morphs are not exported and mapped. Solution posted above.
For higher rez simply stick your exported model into subd, base setting gives pretty good results.
Thanks for your answer! The subdivision tip works great. However, I don't understand which solution you're referring too regarding morphs. Is it the script you've uploaded previously? Could you give more precisions (because I'm struggling using it)? Thank you.
When you bend the hand in DAZ it applies 1 or more JCM morphs, something like pJCMHandDown..70L and pJCMUp...30L or whatever, they need to be applied when the joint bend, so bend hand down 0-70 degrees, apply morph 0-100% and you get a much nicer bend of the hand, the importer does not handle this, you also have to make sure the HJCM morphs are exported, they are usually "hidden" in DAZ, you don't see them in the list of morphs in the FBX exporter for example, but if you add a filter to inlude them, they will be included in the export, but there is a ton of them for eye lids and all kinds of stuff, for a "normal" character you just need a few (hands, forearms, shoulders, thigh, shin and maybe foot).
In C4D if you do it manually you would create an Expresso tag and map the joint rotations to the morphs with a range map in between (sometimes it is a little more complicated than that though).
Thanks for your answer, I understand it a lot better now!
EDIT: - Sorry for doubling up the info someone has already posted - I hadn't seen page 2 of this thread before I wrote it!
My first go with the bridge today, and I can definitel;y echo a lot of what has been said above, in terms of what it still needs to have added, but its a good start!
In terms of the pose morph issue, I can provide a solution that I have used when using the fbx workflow previously, and needing a large number of morphs to access with Cinema. It will both speed up the scne, and save space!
Select your Pose Morph tag, switch from Animate to Edit mode.
Select all the poses within the Poses window, Note they have an 'a' icon next to them. Right-Click and select 'Remove All'
Now, under your figure mesh null (for example; Genesis3Male.Shape), select all or only the morph meshes youd like to be able to use, and select the Pose Morph tag again.
With your morph meshes still selected, drag them into the Poses window of the Pose Morph tag.
A dialogue will ask you to choose yes for 'Absolute' or no for 'Relative'. Select No.
The morphs are now listed, and have a target icon next to them.
Swicth back from edit to animate mode, and click on 'reset sliders'.
You are now free to delete all the actual posemorph meshes under your main mesh, as they are stored relatively by the Pose Morph tag, rather than Absolutely as a reference mesh!
This will speed up your scene files, and can vastly reduce the file size, depending on the meshes, and the amount of morphs you wish to work with.
Hope that helps!
Adam :)
I tried the Redshift coversion in the bridge, but it only seemed to convert the first material, and that was it! - Has anybody else tried this, and had a similar issue?
It's not a big deal to run Redshift's own conversion process of course, which I assume this part of the bridge is attempting to activate, but in my case it didnt function as expected!
Cheers
Adam
For me, the bridge consistently fails to bring in any materials at all.
Glad first tip helped.
I can't help much with the second one without posting a correctly exported file which is verboten by mods. But basically - you need to export the corrective morphs, merge them into your daz bridge import and then the script will pick them up once its activated. You can add your own mappings to whatever morphs exist. Last iteration adds two step morphs too - which I didn't know existed until pointed out here.
Hopefully in the future Daz Bridge to C4D can:
Until then its not really going to be very useful.
When you say 'merge them into your import', How do you mean?