DazBridge sucks!, constructive critisisme after some usage.

[n00bi]

I am sitting here having my morning coffee and need have a little "Rant."

Yea as the title says, Well at least for Cinema4D.
The 1st times i used it, i kind of liked it, but after some usage i see it has several issues.
While the idea is noble, but it has issues that needs to be addressed.
This is probably not the correct place to give directly feedback to them but i want to share my experience using the Bridge.
So others can know what they are in for in case they try it out..

* AutoRig feature issues.
When you import the model you get the joints/bones as well, unless you just import a pure static object. ie a prop.
The Auto-IK button will create the controls for you.
You can choose from a Standard T-pose and the A-Pose used in Daz.
All great and dandy.. or is it.



However. when using the Auto-IK feature you will get a 2nd set of joints/bones.
This is like wtf.
You either use the existing joints/bones and add extra if needed and rebind.
or you rebind to mesh to the new joints/bones.
using 2 sets of joints/bones is stupid.
In some cases you want it but not in general.



In the image, the green bones(original) are binded to the mesh.
The purple one is the new joints/bones added.
Almost all "Green" bones have a constraint tag added to them after pressing the Auto-IK button.
They are constraint to the purple joints/bones.. basically "virtually" attached to the purple bone.

Not only does this clutter things up.
This can also cause frame lagging of the joints/bones when animating/simulating.



Cinema4D does things in hierarchical order from top to bottom in the obj-manager.
This can result in a frame lagging if the priority of the constraints or other things are not correct.
or they have the same priority but you have the original joints/bones above the purple one and other reasons.


* Morph Pose issues.
So i wanted to see how the morph controls was exported from Daz to Cinema.
What it does is create a Xpresso tag on a null object for the controls.
Nothing abnormal about this, i do this myself all the time.

But when you you open up the Xpresso tag and see whats going on.....
Nodes from Italy,, Do i need to say more..


Who ever thought this was a good idea should be hanged by their balls.
Want to do some small changes in pose morph X or Y.. good luck...


* Material issues.
When doing a normal export from Daz as a fbx file. you will get your materials in a sane way.
As in, the textures are in the color/diffuse channel "actually 2 different channels in c4d, but some apps call diffuse for color."
Any who, the material the bridge makes is just a mess.
it seems like it tries to do some sort of SSS setup on the material.
But the end result is just bad and you spend equal amount of time fixing the material than just making a new one.

Material Conversion isn't doing a good job either.
for example. Converting the materials to RedShift it creates a shader-graph of the materials. (i don't mind this. i prefer it over the New Node graph).
But instead of using the proper RS Skin Node, Its uses the Rs Standard Material.
If you want to do SSS. the RS Skin Node should be used. not the RS Std Mat.
But more so.. it just converts the "Broken" material into a RedShift material.
So you might as well just create a new material from scratch.


I been testing the Plugin on two different C4D version and my conclusion is.
The DazToC4D sucks and is not really worth using.
Once you need to deal with multiple characters it becomes a too time consuming cleaning up all this mess.
You're probably way better off just rigging using the cinema4d builtin rigging tools.
However. you can use it once and create a rig template that you will use on other daz models of same size.
That way you only need to clean up 1 rig. but materials still needs to be manually fixed tho for your imports.
The hole idea behind a plugin like this is to make our life easier, but this plugin isn't doing that.

 

[osanaiko]

I don't recall seeing much about C4D in this forum. From that I would guess it is not very popular amongst f95 devs.

Daz's primary value proposition is the huge library of assets, and the relatively simple "buy-and-play" (cough cough) process to use them in renders.

Their strategy of giving away the base program, and making the monies from selling assets means there is a low barrier to entry for noobs (those not yet aware of the wonderful world of asset piracy), especially when compared to the nearly pro-software prices of c4d ($800+ year!).

This way DazCorp can potentially capture the lucrative market of middle aged non-technical horn-dogs who might actually spend a bunch of money on assets so they can make their own private gobbo porn.

So that leads to the situation of Daz having lots of assets because that's where the creators get the most revenue, but a crowd of non-daz-user creators wanting to use them in *better* alternative software environments.

A-ha! I spy a market opportunity for a clever software developer to write an automated daz-asset-importer!

Sadly, it is a very diffuclt technical challenge - the inherent complexity of translating 3d model meshes, then bones/weightmaps, then rigging (and then morphs! and JCMs!) from Daz's very-app-specific representation to another is enormous. Then a similar issue with skins - how can a software program understand that a material converted from one very complex proprietary closed source render engine to another "doesn't look right"...

It's just a very very hard nut to crack. Hence all the tools have difficulties and we then see many troubles reported by users, and complex voodoo workarounds just to get the bloody things to work at all.

 

[n00bi]

I don't recall seeing much about C4D in this forum. From that I would guess it is not very popular amongst f95 devs.

yeah i have noticed this.

Their strategy of giving away the base program, and making the monies from selling assets means there is a low barrier to entry for noobs (those not yet aware of the wonderful world of asset piracy), especially when compared to the nearly pro-software prices of c4d ($800+ year!).

You dont have to spend $800 on c4d. you can if you want too or more.
But they have different prices depending on if you are a student, etc.
Also they give you a free trail and with some "know how" you can have a free trail forever.
Besides.. you can always pirate it too if you go hunting on some of the torrent sites.

A-ha! I spy a market opportunity for a clever software developer to write an automated daz-asset-importer!

Sadly, it is a very diffuclt technical challenge - the inherent complexity of translating 3d model meshes, then bones/
...

Actually the mesh itself is not a problem. nor the bones or the weightmap or the textures for that matters.
The daz exporter "fbx" takes care of most of this stuff it setup correctly.
Rigging is def a challenge as to how controls works in C4d, Blender etc, is not the same as in Daz.
Morphs can be also a issue. ie.. for example if the program only accepts joint-driven morphs and cant do "direct" vertex morphs.
C4d can handle both fine, no idea about Blender tho.
Also Getting the materials setup correctly will def be a challenge. because the render engine has a lot to say about this too.
Are you using standard render engine, the physical. or redshift or octane etc.
The hardest part is probably getting a auto rigging feature working correctly with controls for joints/bones and controls for the morphs used.
Then material is 2nd hardest or maybe the hardest. i am not sure when i think about this.. because of all the different render engines.

If someone actually make a proper plugin. i would be willing to pay some bucks for it.
But this plugin is not worth a dime.


Anyway. i am creating my own template i will use for the females, so no need to use the plugin.
I have basically given up on the plugin, its not worth the effort.
Cant say anything about how it works in Blender tho, but from the few times i seen it mentioned they say it sucks.

 

[MissFortune]

yeah i have noticed this.

There's probably only a few devs that have even touched C4D here on F95. I'm pretty Domiek mentioned he attempted it before Blender, and I've seen a couple say they use Maya (or Maya artists, more likely.). But I don't think anyone's actively using it for their games.

It's mostly Daz and Blender for AVNs. Blender is probably because it's the only one with a decent, somewhat intuitive option to import Daz assets into it via Diffeo.

 

[Egglock]

The issue with plugins is either the information is broken or loss during the transfer process of X DCC -> Y DCC. While plugins are suppose to streamline the export/import process, who the fuck knows what's really going on in the code base. And in your case, it created some undesirable results.

The other issue is that there isn't a universal language for DCC, while the FBX and OBJ exchange format acts like a bridge it doesn't do it all. That is because each DCC have their own implementation on how to handle 3D objects. Let's take Blender for example. The way Blender handles Morphs and JCM(Joint Corrective Morphs)/CBS(Corrective Blend Shapes) which basically mean the same thing, from Daz3d are completely different and implements them differently.

In Blender JCM are usually control by drivers or another set of morphs, and morphs comes in as shape keys. Now the question here is how do you convert JCM to drivers and bring the morphs in correctly? Does it do it at a 1:1? But this is going outside of scope of what the topic is. The point is, the dev behind the plugin would have to know the API of X DCC and Y DCC to correctly implement the translation from one to another.

For materials. Boy oh boy, again like I mention above, there is no "universal structure" as to how they should be handle. With out going into the technical details of what Materials are, at the basic level they are HLSL (High level shading language) or in other words shader code. They take an input (i.e textures, parameters) -> converts it into code -> off to the GPU.

Every DCC out there has their own way of handling these. So a material in X DCC does not equal to material in Y DCC, why? because the code that implements how a material should behave aren't the same. That is why when you export out of X DCC and wonder why it doesn't work in Y DCC, is because of the underlying code. It's also the reason why you only see textures on export and not the material it self, because the material itself is an encapsulated code that runs on that DCC.

To further illustrate this, while Blender and Daz3D follow the PBR workflow, that does not equate them to implementing it in the same way.

Blender way of implementing materials


Daz3D way of implementing materials


Now let's think about this, how would you convert their material language to each other? I'm not a programmer but I sure as hell can tell you, you'll be pulling your hair out just trying to do what may seem like an easy conversion. It's the reason why material conversion can be a nightmare to programmers, since they have to understand what is happening under the hood, and most if not all the time, it's not worth the hassle, when the easier alternative is to bring your texture into the DCC and do your material editing there.

I can understand why devs implement those feature, and I think the two reasons are,
1. The end user are lazy, and
2. They don't want to redo their complicated material setup. Which I think is a valid reason. But boy or boy if you really dig into the code you'll understand just how cumbersome that task is for a programmer.

Don't get me wrong, a simple
Diffuse -> Diffuse
Spec -> Spec
Rough -> Rough
Metal -> Metal

is a super easy conversion from one DCC to another, but when you start having other parameters in there. It becomes a nightmare hell to move those over.

In the image, the green bones(original) are binded to the mesh.
The purple one is the new joints/bones added.

The only reason I can think of why it does this is maybe the dev was inspired by Blender addon called "Rigify". As it looks similar to how Rigify operates in Blender. How it works in Blender is that, it creates two rigs, metarig and control rig. The metarig is used as a base nothing fancy goes into it. It's just bone chains that matches the object. From that a control rig is generated, that has advance features, visual selectors, constraints ect. The user would then use that control rig to manipulate the object.

The up side to this, and I don't know if the same applies in your DCC, is that the user can go back into the metarig and do adjustments to the bone and regenerate the control rig that reflects those changes.

My question now is, does the object still work when you make the main rig(green) invisible? As in if you start manipulating the controls from the (purple)rig does the object deform? If the answer is yes, then what you see there is an advance form of rigging.

Now why would anyone do this? For a few reasons.

1. Modularity and performance.
Keeping the two separate ensures that the base bone(green) in your case, does not accidently get modify. The structure is clean and you know exactly how the bone structure works. The control rig is where all the heavy lifting happens. Such as functionality, constraints, IK, FK switches. Visual selectors, additional bone helpers ect. The performance comes from not bloating the main rig with unnecessary bones that don't contribute to the deformation. Modularity in the sense that you can go back to the base rig, add additional bones, for example, a tail or cat ears. Hit the button and the control rig reflects those changes.

2. Reusability.
Because it's a script, a lot of the heavy lifting is done automatically for you. While this doesn't apply to you in this case. Imagine if you had three different types of characters. Animal, Humanoid, and a creature with extra arms. Having to rig those three types would be a pain in the ass. You would have to create bones, constraints, IK, FK solvers, visual selectors so on and so forth. With the script, this process is automatic, at the press of a button, saving you time.

The hardest part is probably getting a auto rigging feature working correctly with controls for joints/bones and controls for the morphs used.

Indeed it is. I don't know if C4D has any automating plugins for that, something simple, like selecting bones and create controls for them, with the appropriate constraints and such. Otherwise you'll have to dig into the programming side of things and create a script that automates that for you. I comb through some C4D scripting videos, and it looks like they support python. My suggestion is to take a look at the Rigify code and see if you can emulate that across to C4D.

 

[n00bi]

Blender way of implementing materials

Yea. in c4d you have like 3-4 ways to make materials.
The old way to make materials.


You also have Nodes you can use like in your blender picture.
But there are 3-4 different material types, depending on the render engine used.
Standard, Standard Node, Redshift Nodes or Octane Nodes., maybe Vray too, never used it tho so i don't know how materials works with it.

My question now is, does the object still work when you make the main rig(green) invisible? As in if you start manipulating the controls from the (purple)rig does the object deform? If the answer is yes, then what you see there is an advance form of rigging.

I dont use Blender so i dont know how this Rigify operates.
But yes. the purple bones does drive the green bones. so yea deformation works as it should.
I am not a professional animator. but this doesn't look like a normal workflow for C4D.
I did go though a lot of rigging examples found in the c4d asset library.
None of them does this approach and some of the rigs are rather advanced.

C4D does indeed have advanced character rigging tools builtin, It is a rather powerful tool.
Retargeting seams to be the more normal way to do it though the character rigging tools.
Example If you have a animation from mixamo with a different bone/joint setup.
You can keep the original bones/joints and just retarget the bones.
No point in going into details about that as we need to write many pages to understand how it works.. use YT if you want to see it in action
Anyway. thanks for your input and taking your time to write this post.

 

[Egglock]

But there are 3-4 different material types, depending on the render engine used.

Damn, that's a lot. Why so many? Is it because of the different types of render engine? Isn't it a bit overkill?
Blender has two, but still. 3-4? Does it serve a purpose having that many? Just out of curiosity.

But yes. the purple bones does drive the green bones. so yea deformation works as it should.

Gotcha. Do you get performance back if you hide the main rig (green)?

None of them does this approach and some of the rigs are rather advanced.

Yeah the traditional rigging process consist only of one rig, and it's features. But now I'm confused as to what the dev real intention were. That doesn't happen in Blender when I use Blender's plugin. It brings it over but doesn't duplicate the rig, and I have all my control widgets. I don't have C4D so I can't help you in the matter as to why the plugin does what it does. But you are correct. That's not a normal workflow for rigging. I originally thought it had to do with emulating Blender's addon, Rigify but it could be something else. Either way if it doesn't satisfy your needs, you could always make your own rig. As you mention C4D has some advance rigging feature, that probably might be better than having to deal with the mess the plugin brings in.

Not a problem. Glad to share ideas and advices.

 

[n00bi]

Is it because of the different types of render engine?

Indeed it is. The Standard material method i posted has been around since the birth of C4D.
And a few years ago they added in the Standard Node material.. why idk. to keep up with what other tools are doing.
And then we have the Redshift and Octane materials. These are External render engines.
Gpu based render engine while the "Stock" render engine is using the CPU. software rendering.
Redshift was bought up by Maxon and is now integrated into C4D but not Octane.
RedShift and Octane are not compatible with each other. so yea. that is why there are so many.

Gotcha. Do you get performance back if you hide the main rig (green)?

I can disable the bones, both the green and the purple so they are not shown in the viewport.
but in general it doesnt affect the performance and performance isnt really the issue either.

The problem is frame lagging like i showed in the 1st post.


Since the purple bones are a "Driver" for the green bones the order in the object manager matters.
If you swap around bone or add in something else in between. or change the priority of constrains the result can be frame lagging where the driven bone "Green" is 1 frame behind the driver bones. "purple"

But now I'm confused as to what the dev real intention were.

I am too.
Maybe i should ask the dev.. his repo of the plugin can be found on Github, so i guess i could contact him though it and ask some Q about the plugin.
But as i said. i have rather given up on the plugin. in its current state its not making life much easier.
And for all we know.. it could be a bug in the plugin where the intention was to replace the original bones idk, gust guessing.

 

[Egglock]

What a can of worms. Hate to be the programmer managing the code base for that section of the software.

I can disable the bones, both the green and the purple so they are not shown in the viewport.
but in general it doesn't affect the performance and performance isn't really the issue either.
Since the purple bones are a "Driver" for the green bones the order in the object manager matters.

Ah, my bad. I thought it was a viewport performance issue. I had assumed that the objects in your outliner were decoupled. Because in Blender we can't move the objects themselves or rearrange them in the outliner. Though they have what's called "Collections", basically folders where objects go in, then can be rearrange with out affecting other objects.

If you swap around bone or add in something else in between. or change the priority of constrains the result can be frame lagging

I'm assuming it's evaluating those objects from top to bot. If that's the case, I can see why that would cause performance issues. The question I have is why is it designed like that? Sounds like a terrible way to go about things. Since objects create a "hidden" dependence to each other in the order they are placed in the outliner.

The other thing is, and this is just out of curiosity, pertaining to the lag issue. Does that only happen when you insert something in between or move the order list? Or do you also lag when adding primitives to the top or bot?

Maybe i should ask the dev.. his repo of the plugin can be found on Github, so i guess i could contact him though it and ask some Q about the plugin.
But as i said. i have rather given up on the plugin.

To be honest, if you already given up on the plugin, I'd say don't bother asking. Unless the plugin brings in something that you must have that exporting out of Daz3D doesn't provide, it's probably best to figure out something else that works for you.

 

[n00bi]

lol.. Its a can of worms for sure.

in Blender we can't move the objects themselves or rearrange them in the outliner. Though they have what's called "Collections", basically folders where objects go in,

In C4D we have "collections" too. but its called a Group. it basically a Null object you place your things as a child in.
But things can be rearranged however you like it in C4D

I'm assuming it's evaluating those objects from top to bot.

That is correct.
And if you have several groups or objects with children, it will go evaluate them before moving on to next object in the object manager. it does things in a hierarchical order from top to bottom, why it is so?.. ask Maxon

The other thing is, and this is just out of curiosity, pertaining to the lag issue. Does that only happen when you insert something in between or move the order list? Or do you also lag when adding primitives to the top or bot?

Well. if you just add in a object between the joints/bones, it will not affect anything..
The problem "Can" start when you add in tags to that object in between.
Example a cloth tag, rigid body etc. anything that does some sort of simulation.
Ofc it can be fixed by going over each constraint and change the priority.
But this can be avoided by not using two skeletons in the 1st place.

To be honest, if you already given up on the plugin, I'd say don't bother asking. Unless the plugin brings in something that you must have that exporting out of Daz3D doesn't provide,

Yea. i am just at the point: f.. this plugin. the only thing i wanted from the plugin was the auto rigging feature.

 

[Egglock]

the only thing i wanted from the plugin was the auto rigging feature.

Eh? Is that the one that adds the control widget? Because when you say auto rigging, to me that means it'll set up the bone chain after points are placed on an object that doesn't have bones. I was able to find something close to what I said. Uh not sure if it's there in your version, but here's a video of what I mean in terms of C4D

Start from 24 sec watch for a few seconds should be enough to give you an idea of what I mention.

You must be registered to see the links

 

[n00bi]

Is that the one that adds the control widget?

Control objects. a widget to me is a gui window with stuff in.
But yea. the controls you see in the viewport around the female. 1st post.

That video is basically what i been doing instead.
Its 4 year old video but is still relevant.
Once you have done this you can save the "rig" as a template and use it on other models too.
Also you can have the visual selector added & setup ontop of this for a very fancy rig.


But you know.. i am a human and i am lazy by nature
That is why i wanted the auto rigging.

Anyway thank for your input.

 

[caLTD]

All Daz bridges are sucks. Daz doesn't want its characters to be transferred to other platforms. You will start by accepting this, then you will have to process them again on the platform where you export them.

If you don't want to spend money, improve yourself with the Daz -> Diffeomorphic -> Blender solution. Transferring from there to the platform of your choice will be easier.