Genesis 9 coming soon... good luck guys!!
Issue #1186
resolved
https://www.daz3d.com/daz-3d-prerelease
i have no idea what mean genesis 9 unified, but seems it will be a lot of work for you Thomas and Alessandro to make it compatible.
A whole new dimension opening…
@Xin also for the HD plugin.
Good luck!
Comments (63)
-
-
repo owner
Personally I don’t really like what I see. Making the mesh twice as heavy isn’t going to boost performance, nor is 8K textures. Low-poly meshes combined with normal maps seems a better choice to me. And a unisex mesh is good for gender-changing morphs, but I’m not really into that, and it will necessarily mean compromises for pure male and female characters.
Anyway, I don’t think that it will be too much work to make it work. The plugin has to learn to recognize G9, and info about morph paths must be added. Then there are some less used stuff that will take some more work, like simulations.
-
repo owner
Now I notice that eye and mouth geometry is separated from the mesh. That means some work, but should be the same thing as we already do for eye-lashes.
-
reporter
indeed, it will be much easier to create “ creature/monster” that’s there main purpose of chaning eye/mouth geometry.
also there will be some enhanced “facs” don’t know if they will be supported by livelink/faceapp.
anyway will see next week! ;)
-
The uni mesh is not only about gender-changing morphs.
It’s now also easier to utlize gender-neutral morphs (like navels, toes…) for male and female figures.
For G8 we have tons of such morphs for female, but not for males.While I’m also not a fan of the heavier mesh, having it all quad is super nice.
The downside is, the we need propably with G9 for stuff like navels or nipples, HD morphs or geocrafts. Which is of course both not ideal in Blender at the moment.
-
I agree increasing mesh density was a terrible way to go. It really doesn’t take a whole lot of polys to smooth out a mesh well enough so that normal maps and displacement maps can take over for micro, or more high-frequency detail. Same with 8K textures. 4k is plenty, esp when there are multiple 4k maps for just one figure as we have already.
Seems like something that was done to make development on their side easier more than anything. I think G8/8.1 will continue to be just as relevant as it has ever been.
-
Issue
#1201was marked as a duplicate of this issue. -
I did a first test with Victoria 9. It mostly seems to work. At least a basic import without diving too deep yet. The one major thing which immediatly is visible would be the eyes. They are almost fully white and there’s some questionable node groups which get created.
-
I didn’t get G9 yet since I’m waiting for the dust to settle. Also because for G9 I need to install the new 4.21 studio with transmapped emission that will break any old asset so I’m not thrilled. But will get G9 in a few days and test it.
@Maneki As for the V9 eyes, which shader is that in daz studio and what are your import options for materials ?
-
repo owner
G9 is more different than I expected, e.g. the bone hierarchy and names are different, so this is a bigger change than the step from G3 to G8. Expect things to take some time.
-
reporter
yes i also quickly noticed the facs for livelink/faceap are not working properly.
anyway good luck, you’re the best!!
-
@Alessandro Padovani The shader looks normal but I guess what causes most issues is that the eyes are now a seperate object by default. In Blender I used BSDF with volume.
I made a little list what currently doesn’t work. It’ll be probably way more but in terms of priority I’d say standard morphs and rigging is the most important as of now. The shaders work mostly by what I could see. The only thing is the eyes look weird and the head in the shaded viewport is red colored instead of skin colored. (I didn’t check the mouth yet, which is a seperate object now too)
-Merge toes
-Standard morphs
-Scan Morphs
-Add Softbody
-Optimize Pose for IK
-Connect IK Chains
-RIG conversion (simple IK, MHX, Rigify)
-
The softbody was only implemented for G8, not for G1-G3, because each figure requres a different softbody “template”. We could include all figures from G1 to G9, and even some of the most common geografts, but that requires some time to design all the different templates. Ref.
#828 -
@Alessandro Padovani I personally don’t care because I’ve addons for that but I just wanted to point it out. Maybe there’s people who utilize this feature but I probably would put that far down the priority list.
-
G9 is here, we need a update.
-
@Butaixianran They’re already on it. If you download the newest dev version, import and FACS already work.
-
@Butaixianran I know you’re a good coder and maintainer of the unofficial daz bridge, so please feel free to contribute for G9 if you have any suggestion or you already implemented it yourself. This project by Thomas was always open to contributors.
-
repo owner
The eye problem is due to the rectangular eye texture, 4096 x 2048 . Not sure how to deal with that.
-
Rectangular textures shouldn’t be an issue, we use them all the time for environments and outfits. Will look at it in the weekend.
-
Poliigon uses for non square textures this handy node group with “aspect ratio”:
-
And what’s the difference with a mapping node ?
-
It will fix an incorrect aspect ratio if the the correct value is used.
The formular is:1 - (height / width).
This means, for the eyes it would be an aspect ratio of 0.5.Or in short, you can simple use a Combine XYZ node for the eye textures and use for Y a value of 0.5.
I guess, than it should work.Edit: Ah yeah right, that’s what you meant with the mapping node. Yes, it should also work if you enter simple the value 0.5 directly in the scaling of Y into the mapping node.
-
Daz importer seems to already import with a Y value of 0.5. I assume the core issue is a conflict with the UV maps
-
Apparently Daz does always generate square versions of the rectangular maps and puts them into a temp folder when applied to the character:
-
First time posting here, anxiously waiting for the Gen 9 update. Long-time user of Diffeomorphic.
The eyes definitely come out white at first import, but can easily be fixed as soon as you use your own shader. I assumed (and pardon my oblivious knowledge if I’m incorrect) that everyone used their own shaders when using Diffeomorphic. So I didn’t see any issue with the white eyes since they were just default nodes from the import. All I used was a image texture node with the eye texture assigned, going into one hue/sat value and then to P BDSF and it comes out like this. I deleted the other eye material so they both use the same one. The texture is still squared like Maneki described, set at 4k. Daz tosses it in the temp folder for some reason.
All the textures work just fine. Mouth, teeth, eyes, body, arms, everything. I’ve encountered no issues on that front.
-
The temp folder is used when daz studio builds something at runtime, for example for LIEs. Today I’m downloading and installing DS 4.21 with G9 then I’ll look at it.
-
daz studio 4.21.0.5, blender 3.3.1, diffeomorphic 1.6.2.1229
Ok I believe I got it. The issue is in the LIE for the eye texture. Basically, following the LIE parameters, we have to scale the eye texture to 100% and position it to (0,0) that’s the top left corner of the LIE. We have to translate the LIE parameters to the uv space parameters in the mapping node, the LIE space has top left origins, the uv space has bottom left origins.
note. important. Please Thomas verify the equations below I wrote them quite in a hurry but they should be fine.
# daz LIE parameters to blender mapping node scale x = x scale * texture x size / document x size scale y = y scale * texture y size / document y size location x = x position / document x size location y = 1 - (y position / document y size) - scale y
Then below it’s the test scene g9-eyes.duf rendered in cycles with the fix above.
-
- attached g9-eyes.duf
test scene for g9 eyes
-
note. As a side note I see that in the G9 folder there are baked textures for the eyes. So I have no idea why G9 uses the LIE instead of the baked textures, which would be much easier and faster.
-
- attached lie.duf
test scene for LIE position
-
- attached stars.jpg
and texture
-
I attached a simple test scene for the LIE layers position, you can change the position and scale in daz studio then import in blender. The equations above seem to work fine in my tests, though I didn’t test extensively.
The current commit 5827e18 doesn’t work fine for the LIE position, and that’s the issue with the G9 eyes.
-
repo owner
The issue with the G9 eyes has been fixed. I haven’t time to check your file, but it will probably work too.
The whole thing is very strange though. The plugin did set the location and scale inputs of the mapping node correctly, but when the import was completed the location was reset to zero, but not the scale. The fix was to store the mapping nodes together with the data, and set location and scale again at the very end. A better solution would be to figure out where the location is reset, but this should work too.
-
I did first tests with simple IK and Rigify. Right off the bat for Simple IK I’ve to point out that the IK for the arms should be visually horizontally aligned with the hands and not vertically and in terms of Rigify the retargetting of animations looks really odd around the shoulders currently.
I’m not really a rigging expert that’s why I can just point out issues but can’t really offer solutions. Maybe someone with a bit more expertise in terms of rigging could take a look. For my case I used Rigimap (which is a addon to retarget mocap and animations in general to Rigify). It works more or less good with Rigify on G8 without having to adjust too much but it seems to break with G9 as of now.First image Simple IK, second image Rigify on Genesis 9 and third image Rigify on G8.1 female with the same animation:
-
repo owner
Maneki, both bugs are fixed in the last commit, but you need to reimport the character. The root cause was that some bones are imported with incorrect roll angles, and the plugin corrects for that. However, I forgot to add the corresponding G9 bone names to that list.
The picture shows the orientations of the left arm bones before the fix.
-
Commit f8d4acb works fine for the LIE position and G9 eyes. Thank you for the fast fix.
-
@Thomas Larsson The limbs seem to work now but the upper chest area and the neck still need fixing. I used a G8 female clone on G9 with bones adjusted for better comparison:
-
Issue
#1208was marked as a duplicate of this issue. -
repo owner
I changed the parent of the pect bones from the lower to the upper chest, and that seems to work better. Not sure why the old way worked with G8F though.
The rigify spine needs to be reworked to obtain a better match between the daz and metarig bones. In particular, the metarig has a single chest bone whereas daz has two, from G3F forward. As a first step I removed support for ancient rigify versions (before Blender 2.78). This should be okey, since blender now seems to have scrapped rigify legacy mode.
-
@Thomas Larsson I tried the new version, the chest region looks fixed but the neck still has a mind of it’s own. I remember that there was a neck issue on G8 with Rigify up to very recently, maybe that carried over to G9?
https://bitbucket.org/Diffeomorphic/import_daz/issues/1187/import-pose-issues-with-rigify
-
I also noticed some issue when scaling down the character with the root. It scales down everything but the neck doesn’t seem to be affected. This issue exists on G8/G8.1 and G9:
-
Furthermore there seems to be a head controller missing on G9 currently. Maybe that causes the neck issues during retargeting?
-
repo owner
Some of the issues have been fixed, but I cannot reproduce the neck scale issue. Some difference with the neck behaviour will remain, because the pivot point for the neck bone is located lower for G9 than G8. This is a difference between the daz characters which the rigified versions inherit.
-
reporter
Thomas, Facecap and Livelink are not working for G9.
mouth is always closed.
-
repo owner
Facecap and livelink should be working now.
-
Any word on converting G8 poses? It always say something about genesis9.json doesn't exist when using the converter (atleast for me)
-
@Thomas Larsson Yep, I still got the issue with the scaling on the neck. I looked into it which bone/controller causes it and it seems to be “tweak_spine.006” which doesn’t get scaled at all. I can scale it manually but it’s the only controller which isn’t affected by the root scaling. It’s not really hard for me to reproduce. I just import with rigify selected in easy import, go into pose mode, select the root and scale down and immediatly the bigger neck is noticable.
When I scale it manually down it looks like this^
-
I can’t reproduce the neck issue either, works fine here. Below it’s G9 scaled down to about half a meter.
steps:
- easy import G9 with rigify
- go to pose mode and scale down the root
-
I have this issue is Blender 3.2 but not in 3.3 with a mostly clean set up. The Rigify version seems to be the same though.
-
Yes, I think it’s a Blender version issue. I removed all addons and just installed Rigify and Daz Importer and I still got this neck issue in 3.2.
-
Nope, just checked and 3.2.2 works fine here same as above.
-
How do you guys scale down? Under Object Properties? Because if I type in 0.5 scaling there it works but when I scale it down by pressing “S” I get this neck issue. I installed the latest 3.2.2 Blender version just to make sure and a clean set up didn’t work either.
-
I asked someone else to reproduce it for me and they’ve the exact same issue. To reproduce this neck issue you’ve to:
- Use Blender 3.2
- Import G8/G9 with Rigify
- Go into pose mode
- Select the root controller
- Scale with “S” up or down
-> The neck will visibly stand out
It could be a Blender bug but I’m personally a bit hesitant with using 3.3 currently because as of now I still favor volume skin.
-
repo owner
This seems to be an issue with Rigify itself in Blender 3.2. I rigified a standard metarig, which has nothing to do with the Daz importer, and looked at the bone DEF-spine.005 in layer 30. To the left is rest pose, to the right the root bone is scaled by 0.1 and the entire rig is scaled by 10 in object mode.
A workaround would be to scale the rig in object mode instead of scaling the root bone.
-
@Thomas Larsson Yes, I guess since it seems to be a Blender version/Rigify related issue and a work around exists I’d let it just slide.
Someone wrote a script to convert G8 poses to G9. It seems to work well but the downside at the moment is that it needs to have both, G8 and G9 loaded, G8 with the pose and then applies it to G9.
Maybe it’s still interesting for implementing a conversion for G9 with the Daz Importer though:
https://www.daz3d.com/forums/discussion/598316/g8f-m-pose-transfer-to-g9/p1I used it to convert a G8 walk cycle to G9 and load it as action onto G9 with the daz importer:
https://imgur.com/a/KN7nJ4H
-
note. I can confirm the issue on blender 3.2. It didn’t arise for me because I loaded in 3.2 the rigify I generated in 3.3, that could also be a possible workaround. Sorry for the mistake.
-
repo owner
@Jay3DM The plugin can convert poses between different characters. When loading a pose, enable Convert Poses and set the Source Character. There was a serious bug in the conversion code, but it should be fixed now.
-
I saw that there’s already a pose conversion for G9 in place but the legs seem really off with it currently and are clearly intersecting.
Same animation and base G9 I used with the Daz script mentioned above: https://imgur.com/a/KN7nJ4H
-
@Maneki Retargeting among different rigs, or even within the same rig among figures with different proportions, may always generate some limbs intersection depending on the pose. Even the daz script you mentioned generates such cases, though in a different way. Then there are more advanced tools for retargeting which use ik handles on hands and feet to try transferring the pose better.
-
repo owner
The plugin does retargeting if convert pose is enabled, although it is somewhat limited. It turned out that my previous fix wasn’t correct either, but the current one hopefully is. Here is a comparison between G9F and G8F, using Base pose walking A. Leg do not intersect!
-
Yes, it kinda works now but in terms of animation I’ve the opposite effect now. The legs go further apart than intended.
First image is a pose comparison between G8 and G9, second image is a animation comparison between G8 and G9. Bone location and rotation restrictions unlocked for both. But even the pose conversion doesn’t work flawless. Even though I used a G8 clone, the hands are slightly intersecting with the body. I personally can fix some minor issues like that easily but I don’t want to give up the hope that a better conversion is possible. The script from the Daz forum did a pretty good job in converting poses AND animations.
-
G9 is actually way easier to work with, if you want to modify from base.
UV is very similar to Texturing.xyz vFace textues, so makes it very convenient.
Would love to see G9 support soon :)
-
- changed status to resolved
- Log in to comment
Personally I don’t think I’ll have much to do since luckily there are no new shaders.