Hay guys I finally got around to doing a developer blog on character development, making use of Daz Studio, covering a lot of the basics as to the ideal of a quick start overview.
The approach was done as if someone was sitting beside me asking some basic questions as to usability and done in a manner as if I was attempting to extract usable data from Daz Studio to make use of with in Unreal 4.
Part 1 consists of 5 videos, including intro, totaling about 5 hours of work flow theory and I’m planning on a part 2 based around any questions or the direction set down by part 1.
As a 3d artist in general I’ve found Daz Studio a fitting application for usein any 3d pipeline that would befit from ready to use assets even as place holders or for full out character development as part of the iteration process so if there are any questions or concerns I would be more than happy to fill in the blanks.
Right… After all that effort on the Character Development series I realized what was lacking is some usable animations targeted to use on the G3 framework so I did some retargeting of the Epic 3[SUP]rd[/SUP] person template as well as the free set available form the market place to mess around with.
Been a while since I’ve used my public folder so let me know if there are any problems.
With this set you should be ready to follow along with the tutorials over at Epic on building 3[SUP]rd[/SUP] person controllers.
To make use of them as per the series extract either the Genesis_Male or Genesis_Female but rename the root nod to “root” using the joint tool. If you still need help I did up a quick how to video demonstrating the “requirements”.
Aye Frankie I’m following your series very closely and intently, as a result I took time to watch the Ninja Theory Diary Blog; Now I have a question. Have you done a quick tutorial video on how you set up your Daz3d UI; I really and truly would like to see exactly how yours is set up as it is much easier to follow your Blogs and Instructional Information.
Hey @FrankieV, great series! I was able to achieve a fully modular character after watching the second video.
I also like your masking Idea, so far I opted for a series of body parts to show underneath the clothing and hiding those that weren’t needed (e.g. legs beneath pants), but the opacity masking seems better (I’m thinking of working that into a material instance with dynamic parameters, so my character blueprint would add a mask for each piece of wardrobe and the skin material would then apply the combined result as the opacacity mask - should work great).
You mention cluster shaping as a cheaper alternative to facial blend shapes - can you point me to more info on that topic (I believe you mentioned you have a video on that, too)?
Will there be part 2 of the series? I really hope so.
The thing about Daz Studio is it does a lot of things not game related and it’s only been recent that Daz3d has started to focus more on building products that could be used for video games as well as supporting their main market as a previs app so since my videos on the use of Daz Studio and Genesis are popular I figure the first must do “lecture” should be more of an over view of things one needs to know. Kind of like a survival guide of the things most would take for granted.
I do plan on doing more as Epic continues to improve 1-1 compatibility as to usability and I know that Daz3d have plans to make things easier to use their products in UE4, They already support Unity vie Morph3d, as well their licensing makes it possible for others to make products targeted towards Genesis. I see you already have stuff on Epic’s market place so you could make stuff for Genesis and sell it.
Deciding between morphs or clusters is an easy solution as the framework supports both at the same time and is a case of having it even if you don’t need it rather than not having it and in need of it. Which way to go though really depends on the project be it if you just need some simple lip sync, clusters, or high fidelity of a character that can act using morphs
The requirement of morphs is the vertex count has to be the same for each shape so each character would need a morph selection that is the same if you have more than one character. So lets say that to get the kind of sync requires 200 targets each character you add will increase it’s memory footprint. Would be fine if if you have a small enough of hero models but if you have a budget targets can start to add up.
Clusters are cheap as they are built into a single framework that can be shared no matter the number of actors you add and the authoring is the same as would be done as making a typical walk cycle and the animation data shared no mater how much you edit the mesh, which would break a morph target. Typical use is if a player needs to interact with an NPC for dialogue or even making use of a single servers all expression set.
So cost wise morphs for cut scenes where you get up close and clusters for run time interaction is a good combo but to be considered is clusters can be adapted to procedural driven solutions. You make the target shapes once and can be used to drive the lip sync of as many different characters you wish.
P.S. Cluster shaping is not what it use to be where it was more of a talking mail box result
A lot actually. Unparenting clothing + renaming the root node was what I was missing previously.
The general gist of the framework I got from your earlier videos.
So, how would I go about export and setup, in order to choose if my facial animations will run on morph targets or bones?
Is it the case, that if I export an animation with facial expressions from DAZ, *without *the necessary morphs, the animation will run on the skeleton, and if I were to include those morphs, it will run on Morph Targets instead?
Or is there more to keep in mind?
Well it depends on what application you are using to author animations.
In part two I plan to do an overview using Daz Studio and Motionbuilder as per the example video and how to connect them up to the voice device which converts sound files to lip sync.
If you want to use clusters,bones, they are there just like any other bones when exported and in Motion Builder I use a few tricks to get the shape I want.
To use morphs one just have to check export morphs in the export dialogue and set the rules table as to what morphs you want. You could wild card them all but that could land up being thousands of targets that you don’t need.
On the other hand if you want to animate morphs in Daz Studio and export both animations and targets you still need the export morphs selected but set all of the other rules to ignore. In this config only morph targets that have been activated, <> 0 , will be exported along with the animations that were key framed.
Once exported though you can still use bones if you wish.
Overall it’s not a case of having to chose one over the other but rather both being available to you at the same time with the option to excluded morph targets.
I was thinking in terms of the Daz export, i.e. LipSync animations available already in Daz Studio (though for some strange reason only in the 32bit version). Seems to be working all nicely, if I export a figure without facial morphs (or no morphs at all), create a LipSync animation for it in Daz, it plays in UE4 as expected (just bones, no morphs).
On the other hand, if I export the same animation + the figure with morphs (via rules, or just by keeping morphs used in my current timeline), this animation runs fully on Morph targets in UE4.
Pretty convenient and easy enough.
I have some more questions if I may further pick your brain:
Did you run into issues with Dual Quaternion skinning in Daz vs Classic Linear in UE4? (there’s a source mod to enable DQ in UE4, have you explored that option by any chance?)
Can you go into some detail how you solved foot IK with the Daz skeleton? (I haven’t tried yet, but you mentioned at some point that there are issues)
At first yes, with the release of UE4.0, the unique skinning solution caused issues as to excluding vertices from the weight table, or resulted in a zero value, which caused the model to create spikes. The fix was simple by importing into 3ds Max which weights all vertices and then export it back out to FBX to import into UE4. At that time though DS was still on Genesis 2 and overall UE4.0 made a mess of the materials as imported as well used odd sizes textures,not power of 2, which did not leave a very good first impression.
At about 4.15 things started to improve with the release of Genesis 3 where a 1-1 import started to improve in away that suggested that Epic was fixing most of the buggy stuff on thier end rather than depending on Daz3d to solve the problems, using 3ds Max as an example there was never a problem with the fidelity of the asset going back as far as the original Genesis frame work, and at about 4.17 even material import started to improve including hair.
Which as a test resulted in this https://youtube.com/watch?v=vq4dMkD6TOo
I mention all of this as it’s clear that if there is an issue Epic will fix it in due course and as a second impression is at least worth a look see as UE4 is really the only engine that does not have any limitations as to usability.
Yeah 2 bone IK is still an issue as G3 uses a parent,child,parent configuration for it’s twist bones so out of the box it’s a problem that can be solved in an app like 3ds Max As the IK solve rdoes not care how many bones is with in the IK solution and one only needs to make use of a few other constraints.
One of our coders solved the problem but I don’t know how he did it off hand of if done via BP or C++ code. The thing is as things are getting fixed that seems to be of little value “unless” applied to G3 I suspect yet again is another one of those while your at it fixes that will just show up one day.
If it matters at this stage I’ll ask my coder guy but it’s one of those things that works best out of the box but yes IK is possible using the G3 rig.
I understand the concept, I see the main “Two Bone IK Function” (category: “Utilities/Animation”) in the Engine source and can create a custom version of it, but for the life of me I can’t figure out how to duplicate the “TwoBoneIK” node used in the Animation Blueprint (category: “Skeletal Control Nodes”) - the one that takes “Component Pose” as input.
I ran into an issue with modular body parts, maybe you know how to fix it easily.
When I seperate, for example, the head from the body (in order to have easily swapable heads) - I get ugly seams between the head and the body in Unreal.
The Wiki addresses this problem (“What we need to do is set all of the vertex normals on our character mesh to be explicit”), though only via 3dsmax. Do you know of any workflow to work around this using Daz->UE4 only?
The one on the left has the Neck exported with the rest of the Body as one mesh, the one on the right has Head+Neck and Body exported seperatelly.
(While exporting from DAZ I set the visibility of anything I don’t want to export, to Off).
No particular reason, I’m just getting started with workflow experimentation.
What other issues are there to look out for? I was assuming, having the head as an additional skeletal mesh component driven by the master pose component would be a feasible way to “bolt down” the head. Or do you mean the position of the cut/seam, as in: making a larger bust with more torso area rather than just the neck+head? e.g. something such as the one here: https://www.youtube.com/watch?v=JFdrlEW8GLE
Do I understand it correctly, that in your case such a seam would be hidden under a wardrobe item mesh?
Is that what you meant by “using heads as a component of a cloth player”?
Yah the head is a component that the seem is hidden under the clothing For our project we make use of the G3 framework and heads as a component and they are assembled as a character BP.
The problem though of bolting the head to the body becomes a lot more apparent when the character is moving as the vertex placement has to be 100% relative to it’s mate other wise it will tear, and usually does, across the seem.
Another issue occurs when you add a tessellation to the mesh it will also tear at the seem even though you told the shader not to. Seems, pun intended, the shader can not handle moving surfaces.
Materials is another issue of matching one material to the other across the seem. The texture can be blended but forget about normal maps.
There are a few tricks. You can try solving the problem by cutting and creating the seem under the jaw line where it would be less noticeable
I would say though the best solution is to take advantage of how morphing in UE4 works.
When you import an object that contains morph information only the data of the vertex displacement is recorded so the footprint is equal to the detached head, even less excluding the vertices not moved,so in a lot of ways detaching the head is less effective, efficient than leaving it attached and then solving problems with in context of the purpose the asset needs to serve.
Context is very important in game development as most times you will be forced to disregard best practice in favor of what works and is why I asked what it was your working on.
In regards to the 2 Bone IK and Daz rigs having a Thigh Bend and Twist bone - I was thinking about an easier approach then editing Engine source: if we delete the Thigh Twist bone (in Daz), the weights will be transferred to the parent bone (Thigh Bend, at least with G8) and everything *seems *to work properly (presumably except for animations and poses in Daz, but with the “harvest” approach this isn’t really a concern). Could this be a workaround or am I missing some crucial caveat down the road? (I have very little experience with rigging)
In general, I have to say, I really like the Daz workflow - just experimenting with fitting Paragon assets (clothing, shoes but especially hair) to the Genesis framework, works like a charm, same can be easily done with Mixamo Fuse clothing (which already come in game ready poly counts and have great material ID masks to boot, which makes them much less work than anything offered on the Daz store).
In theory, as I’ve yet to do it, there is nothing that I know of that would prevent someone from relinking the joints into a parent>child or even renaming joints so that they match Epic’s naming convention but I think the better option would be for Epic to add the ability to lock the rotation of the twist bone as an option to the parent>parent configuration. There is currently a feature in the IK nod that seems to allow for some form of joint locking in some kind of manner but not as one would expect as to locking the twist joint.
Overall it just creates a unique requirement as to a 1-1 export of the G3 frame work directly from Daz Studio and adds to the work load of ensuring that the G3 characters can be used as a direct replacement of the current Epic base rig that already covers everything that an actor would need even with in a AAA studio environment with matching animations so hacking around for a working solution would not be considered best practice as in most cases it’s the application that should be updated to handle a working solution by adding a constraint or joint limitations as it does in Daz Studio or even in most traditional 3d application.
As it is an IK joint in most cases requires a parent joint with a end effector be it that the link has just 2 bones or 100 and then constraints are added to force the link to behave in a predictable manner. With just the 2 bone IK with out constraints cases the joint to break so in a way the current configuration does work but not in the same manner or in a way that it should.
So in my opinion it’s a bug as to expectations and should be a feature request that needs to be fixed by Epic as a parent>parent link is rather common and easy to resolve in say MotionBuilder.
If it helps the reason we desire a 1-1 between Daz Studio and Unreal 4 is because UE4 comes as a big empty that does not come with built in tool features and because of the liberal license requirements makes for an excellent choice as a character design subsystem that fills more holes than it creates Already there are a few Epic merchants retargeting their assets to work with G3 and by doing so doubles their market potential.
As a personal opinion as someone who has used Daz Studio since day one, more or less, and has used UE4 since day one I’ve found that in most cases that it’s better to wait as Epic is very well aware that G3 is out there, as direct import has improved big time since 4.15, and Daz3D is in the process of developing a UE4 solution on their end.
In the mean time I’ll give a relink a go and see what happens. In all it’s a case of making sure that the animations match the rig but would be a bit of a pain to have to relink clothing and stuff in DS.