Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Vanilla PoseDriver nodes work perfectly once they are set up, there is no need for any plugin (or engine) source modification. The JCMs created by DTL are always prefixed with 'Genesis8Figure__' so that the anim BP postprocess I created can be re-used for any character created by DTL, whether they are G8F, G8M, G81F or G81M (the same goes for control rig setup). End users will not have to deal with setting up the PoseDrivers as the anim BP post process in the demo project I will ship works 'out of the box' for any DTL converted character, even when extra joints and / or geografts have been added.
I standardised all the G8* skeletons and JCM naming because setting up PoseDrivers can be difficult. They are still 'experimental', so have their quirks. There are some parameters that must be set up in a certain order (e.g. RBF radius last) and if they are accidently compiled with the wrong settings (e.g. drive bone instead of curve) the UE curves arrays can get corrupted, leading to the dreaded 'Duplicate or Invalid curves' error. Once this happens the anim BP will start randomly crashing UE with an 'array out of bounds' error. I have typed out literally 100's of crash reports.
With persistence and by keeping backup copies of the project to revert to when the curves array gets corrupted, it is possible to set up all JCMs with PoseDrivers (as can be seen in the DTL tech overview movie). Once they are set up, they are solid and run hyper efficiently with no issues at all.
Thank you! I have created a python script in Blender 3.3 to sample these shapekeys according to your method. It needs about 30 minutes to run. Of course, it depends on sampling accuracy. I'm trying to use posedriver in Unreal 5 . Hope to have a good result! Also, look forward to your plugin!
Using python script to generate JCMs is quite cool, I'd wait for DTL to further improve the results. Have manually sculpt some JCMs and keep using the modified DTU Daz Morph Driver nodes for now, there are too much other work to do after the characters have been imported.
We can use script to replace manual sculpting. Just adjust the bone angle, create a new shapekey, make it active and let vertivces of model which without JCMs and DQS automatically snap to DTU model with JCMs and DQS based on their topology. I think it's a convenient way. In fact, my sript works like this.
Understood it needs to add the Blender DQS morphing onto the existing original Daz JCMs and create the new JCMs, thanks
since we are talking about "geograft elements" any chance for this pluging to fix the issue of "double mesh" from geografts?, it's a really old and annoying issue which when you create a geograft element in daz this generate 2 extra meshes", instead of a single one, it's a old issue which never got worked on the bridge and maybe it could be fixed here
https://www.daz3d.com/forums/discussion/433892/geografts-elements-help
basically when using geograft attachments and exporting to daz you ending get a second copy of the "geograft" which normally comes without any mats, and normally the best way to "maybe fix it would be create a invisible material to make this mesh "hidden", but still a "extra mesh" and extra polygons which the right way to fix would be to "remove it, then any way this tool would find a way to proper fix it and only export "one version" of the tool", like the "right one", because when you export it one of the meshes come "bugged" leaving "holes"(seams) between the geograft and the main mesh, while the other proper attach it without any hole or seamless,
another thing which i would love to see addressed would be for the geoshell stuff which when exported to the unreal it become a sort of "plain non rigged mesh" like a obj and if you animate the main mesh it will remain in the same place not following the mesh, the "workaround for it normally would be if the geoshell use the same uv as the main mesh like for exemple a underwear geoshell which use the main character body uv as base then you can apply the geoshell direct to the main body material, however the right way would be turn the geoshell into a proper rigged mesh.
and for the last the non rigged props which are attached to the character instead of rigged, you have a workaround inside daz to convert most of then to "rigged" however it not work 100% all times some objects when converted they are moved to a different place like for exemple some "props shoulders" you have one left and one right then when you convert let's say the left instead of it remain in the "left" when you conver it goes to the right like it was just a clone of the right a good way to proper convert those objects to rigged if needed" like some outfits acessories which are supposed to be rigged but are added as props.
another variation for the props are the rigid props or stuffs whcih are "attached" to the outfit or body part which are props which when exported to unreal they fall apart from the main body, would be good see a way to fix it and make then get rigged into they right place.
DTL already does this. The first part of the Maya script deletes any 'ghost' geografts leaving the underlying mesh (complete with any merged geografts) intact. This has been tested with a variety of geografts. DTL does not support any sort of colour / effect shells so those are deleted at the same time; so whatever is seen in DazStudio when any shells are hidden / disabled is exactly what is seen when the final fbx is imported into UE.
The geografts I have tested with DTL (various anatomical elements) are merged into a single mesh by the DTL Maya script, along with eyelashes, tears and any clothes / accessories. All morphs (including JCMs) act on this single mesh perfectly. This includes any exported morphs that were specific to geografts or clothes / accessories - e.g. there will be a morph called 'Shirt__ExpandAll' in the list of morphs for the character in UE that will do the exact same thing as it did in DazStudio before the meshes were merged.
The exceptions are meshes attached to rigid follower nodes (e.g. buttons, some jewely) and any other meshes attached to regular joints within the joint hierarchy (e.g. props, some jewelry). DTL keeps both of these separate from the single mesh. As part of the pipeline, I export higher subdivision fbx files to feed into DTU via the DazToUnreal plugin. Some rigid follower nodes seem to get displaced by the DazToUnreal plugin fbx export process, so the DTL Daz script saves their positions when exporting from Daz and repositions them correctly in Maya. Once imported into UE any rigid follower meshes or other embedded meshes display correctly on the DTL figure. The only remaining issue is that they are not affected by JCMs or other morphs.
I'm currently working on a feature that would move rigid follower meshes in the way they should when morphs are applied in UE (e.g. buttons on a shirt move forwards and rotate slightly when the 'heavy' morph is applied). Additionally, some morphs change the regular joints transforms when applied (e.g. facial bone positions change when opening the mouth or character head morphs are applied). These joint position changes would be applied when the morphs are applied in UE. This feature is not planned for the initial release of DTL though, it will be in a later version as it's quite a lot of work and I want to get DTL released asap.
the geoshell i was talking about are products like this one:
https://www.daz3d.com/dforce-wet-and-dry-dark-fantasy-outfit-for-genesis-8-females or this one
https://www.daz3d.com/gloves-and-mitten-fashion-for-genesis-8-females
the geo shell is a sort of "fake mesh" which when exported to unreal it become a "prop" which works like the others props when exported like not being rigged and they can't be turned in a rigged mesh in daz, normally the way to deal with then is use they "texture applied direct to the character in the cases where they use the same uv as the character body part and allow it.
in some cases like this one
https://www.daz3d.com/jepes-body-hair-project-81
use the texture direct to the body mesh is really the right option, like tatoos but some cloths are made in this way and can make those cloths "not proper work since they work in a totally different way in daz.
yeah the rigid follow node is one of the big issue many outfits which have buttoms and others parts "attached aways ending being a issue and being exported as a "prop"(not rigged) to the character and in some cases is hard to make it proper work i really hope it can be fixed on this tool.
still too much time until the tool release????, any estimate date to release like: still this year, or maybe in 3 or 4 months???
@Ellessarr - As I say, geoshells are not currently supported by DTL. The Maya script optionally deletes them or leaves them in place as 'static' meshes (i.e. they follow the bone they are attached to, but are not affected by any morphs). I've had a look at merging them into the single mesh when imported into Maya but have not had any success yet. Merging geoshells (and embedded meshes) looks like it will require quite a lot of vertex-level manipulation of the skinclusters that would delay the release of DTL.
So I'm putting merging of geoshells onto the feature list for a version 2 of DTL, along with G9 support, embedded mesh merging and morph-driven bone length changes.
The first release of DTL is in a working form at the moment but needs improvements to the UX. I'm currently creating options dialogs and generally making the system as easy to use as possible. I'm planning to get it released before the end of the year.
It does seem like rigid followers are a bit of a problem for some of the other programs. Would it be preferable if the nodes were part of the conformer instead?
A quick workaround could be to export all the geometry attached to nodes as a single obj (base resolution) so that its all in one obj. Then use the transfer utility with for example the shirt as the donor so that it conforms to the shirt and follow all the morphs in the shirt and save that as an item. Downside is you'll have some morphs distorting the buttons again with that method.
@Mada - Thank you for the suggestions. I've experiemented with various workarounds quite a lot, including merging the rigid follower meshes into the main mesh. Unfortunately, buttons etc look awful if they get stretched out of shape even a little.
I have a nearly-working methodology for exporting bone length changes for both morphs that affect bone lengths and rigid followers. I've hit a roadblock with a couple of function calls always returning zero (Node.getLocalTransform and Node.getLocalPos) Node.getWSPos works fine for me, so I can calculate a joint's local position using the parent node's world position, but this doesn't give me the right axis orientations when the joints are moved out of the reference pose during my export process.
I'll solve this for the second release for sure - the next step is to dig deep into why I'm getting zeros for Node.getLocalPos and put together a formal bug report if it is indeed broken.
But for now I'm going to focus my efforts on getting DTL released - it works great for many purposes as it is. If I let the feature creep take over I'll never get it released - I decided I had to cut off the new features for the first release somewhere!
geo shell, geografity and rigid nodes, are thing which really are created to work only inside daz, as really daz only feature, while one of them can 'work" like to 70% to 90% perfect outside daz which is the geografty, the others 2 where really made to be a daz only feature being impossible to work outside daz unless you do a lot of work around even going to the point of being pointless try to use then, specially the rigid node, it' is the worst of the 3 features, while geograft can somehow be "mitigated", and geoshell you can have a work around using only the textures, rigid is just "useless" and don't work at all, the best work around would be using the transfer utility but it also not aways make it work leading to bad placements.
Thanks for the reply :) I wondered if items that was created as rigid followers because of stretching issues would have the same problem and it sounds like it does yes. Good luck with feature creep heh
The Bone Driven Controller node was fixed in UE5.1 official release, the mapping is linear by default without driving curve.
.NET 6.0 runtime and Windows 10 SDK are required to compile UE5.1 C++ projects.
The UE5.1 official release fixed lots of bugs and it seems quite stable without crashing itself when playing with new features.
----------------------------------------------------------------
Bone Driven Controller node was not fixed there's the bone rotation axes related bug. It uses the parent bone axes of the driver bone, not the axes of the driver bone. Attached new images showing how to set the driver bone rotation axes according to that.
Since the UE5.1 has fixed Bone Driven Controller node, there's no need to use the original DTU bridge for me. There needs to be better material conversion from Daz to Unreal, DTU has the PBR master material which creates awful results, however the Iray Uber master material from DTU is quite decent.
I don't care about geoshell support because I don't like the shells used on geografts or any body parts, shells have to be baked in order to export to any other program, the baked results are quite different from original and the seams joining the body maps are inevitable with baked geoshells.
The geografts should use standard PBR or Uber textures, like the genital maps for Daz original genitals, but the original G8F genital lacks the inside parts when the camera goes inside. The unofficial geografts have nice geometry but need extra work to manually create new materials based on existing body materials.
The DTL plugin could improve the material conversion results to make Daz characters in Unreal look as good as possible compared to Daz renders.
Hi Dave,
I followed your tip and tried adding custom morphs made for linear skinning but I have run into a 'normal' issue. I saw your youtube video the elbow normals of your daz figure stay clean. Whereas when I try, All the normals get distorted. I was wondering if you could share how you were able to fix that issue. Thanks.
Nevermind. I just figured it out. You have to enable 'support compute skin cache' in the project settings in UE 4.27.
It seems very easy to improve the G8.1 material results in UE5, attached the results and the method to modify IrayUberSkinMaterial and make G8.1 characters use IrayUberSkinMaterial template.
When using DTU to import G8.1 characters it'll use BasePBRSkinMaterial template, whereas when importing G8 it'll use IrayUberSkinMaterial template. The default BasePBRSkinMaterial gives very waxy skin for G8.1, it's better to use modified IrayUberSkinMaterial for both G8 and G8.1.
[Some images removed]
It seems the DTU provided materials use too much resources that video memory has been exhausted, solved this with modified shaders that are more efficient.
The master materials are complex and they try to one size fits all different characters. Most Daz characters just use basic three textures: Diffuse, Normal, Bump, and optionally have opacity mask textures. For these specific type textures they don't need the DazParameters and PBRSkinParameters functions, which preload bunch of white square textures as default values. When using dedicated materials taking only necessary inputs, the rendering has much higher fps with lots of Daz characters in the scene. Attached examples of modified materials suitable for most Daz characters, output same quality but much more efficient.
If using different type of textures then create new materials for them, the concept is to avoid master materials and too many layers of material instancing, and use dedicated materials for the textures.
-------------------------------------------------------------------------
How's it going with DTL plugin development? Looking forward to use it to improve results for Daz characters.
In UE5, if I enable physical simulation, post process anim BP or pose driver doesn't work. I don't know how to solve it.
Post process anim BP doesn't respond to physics simulation by default, couldn't find any setting of Post process anim BP to enable this. Post process anim BP seems to react to bone rotations from animaions but not from simulations.
The solution is to not use post process anim BP, instead make the pose drivers or bone driven controllers as normal anim BP, and embed it as Linked Anim Graph into the character BP, like embedding IK controls before the character animation output, attached the example from the Paragon character anim BP.
----------------------------------------------------
That doesn't work if the physics simulation is initialised from character BP event graph, by using the Physical Animation Component.
Physical Animation Component seems be be layered after anim BP has been processed, so it can't drive the morph targets used in the anim BP.
The processing order is like this: Animations -> Anim BP -> IK Control -> Post Process Anim BP -> Physics Simulation. Physics Simulation seems to have no influence on the Pose Driver because of this.
In UE5.1 there's a better alternative called Physics Control Component which is more customizable, but it has zero documentation so it needs some testing to discover how useful it is for this feature.
If that component also doesn't work then it needs some C++ plugin to override the animation processing threads.
Thank you for your explain!
[delete]
Can't wait to use this plugin just for the better JCMs along, put this on both the Daz and Unreal market, would be one of the most desirable plugins.
hey i have a question, for what i saw daz have a huge issue when exporting characters outside daz and using "morphs to change character "sizes" i means which any morph which normally should affect bones too it's not work like if you export the "heigh morph" outside daz it only gonna work on the mesh the bone will remain in the original tranformations without "following the mesh as enlarging it as it was pointed in the plugin discord, it's seens which the bones transformations are ignored when you try tro export the morph to use outside daz, if you export a character with the morph applied it works fine, however if you try to export the morph to apply it inside unreal as slider it not gonna work or only work on the mesh the bone will remains in the same which will lead to bad deforms when animating, it will fix that?
That's not Daz's problem that morphs outside Daz can't change the bone sizes. Morphs in Daz are property drivers, they're not the same as pure morph targets which are snapshots of deformed meshes.
The morph targets can get exported into UE5, however the Daz property divers are not supported by other programmes.
To recreate the Daz morphs inside UE5 it needs to connect other BP nodes with the morph targets, so that changing morph targets can drive other properties like the bone transforms etc.
https://docs.unrealengine.com/5.1/en-US/animation-blueprint-transform-bone-in-unreal-engine/
Not sure if DTL plugin would include such code to implement the Daz diver features. That's similar to how Diffeomorphic converts Daz morphs for Blender.
Can I see parameters of pose driver? I'm trying to do what you did. But there will be a little muscle shaking when rotating. Thank you! @dave_0aa47f5a80
The pose driver gives bone jiggering when at some angles, and similar problem with UE5.1 IK retargeter. Also some animations if not well made it's not enough to just retarget them in UE5.1, have to use Blender animation layers to clean and modify them.
The simple Bone Driven Controller works well for me so I don't use pose driver node yet, Bone Driven Controller also works with the IK solutions of my game without any jittering.
The lack of quality animations specially for some types really slows down the game development, going to try Cascadeur and see if that's quicker than Blender tools, anyone tried Cascadeur to make customized animations?
I'm looking forward to the release of DTL. Will we be able to use it in January?