Is it possible to access SubD geometry?

onix

I already know that HD morphs are a top-secret commercial trade secret of Daz company

But is there any way at all to access SubD geometry at all? like from the script or plugin?

 

 

Masterstroke

onix said:

I already know that HD morphs are a top-secret commercial trade secret of Daz company

But is there any way at all to access SubD geometry at all? like from the script or plugin?

 

 

 If so, why would anybody tell you here?

Matt_Castle

Sure.

If you're sufficently minded that you could create some amazing new HD morphs, then it should be within your capability to become a PA and get access to the HD tools.

WendyLuvsCatz

Displacement maps

Richard Haseltine

You could always write your own HD plug-in with the SDK, though it would not be able to read the Daz dhdm files. I believe the mesh data, post-SubD, is available to SDK and probably Script but it's not an area I have explored.

WendyLuvsCatz

Richard Haseltine said:

You could always write your own HD plug-in with the SDK, though it would not be able to read the Daz dhdm files. I believe the mesh data, post-SubD, is available to SDK and probably Script but it's not an area I have explored.

think Casual has something on his site already

https://sites.google.com/site/mcasualsdazscripts/mcjelevate

Seven193

onix said:

But is there any way at all to access SubD geometry at all? like from the script or plugin?

What do you mean by access it?  Export it to file?  Can't you just bump up the subdivision level to enable HD, and export a Wavefront .obj file?

 

WendyLuvsCatz

Dave230 said:

onix said:

But is there any way at all to access SubD geometry at all? like from the script or plugin?

What do you mean by access it?  Export it to file?  Can't you just bump up the subdivision level to enable HD, and export a Wavefront .obj file?

 

I believe they mean sculpt it yourself in some way,

Casual's script uses as I suggest displacement and creates actual morphs but on figures you would have all the issues like joints needing correctives posing etc and would need to do it all manually 

using Casual's script to add expression wrinkles from photos might be something worth looking into though

Singular3D

I'd love to get the HD stuff to displacement maps. Is there a way?

WendyLuvsCatz

Singular3D said:

I'd love to get the HD stuff to displacement maps. Is there a way?

I have asked about that often

there are ways but none of them simple or in DAZ studio

You can export two meshes and use Blender, Xnormal, Zbrush etc to do it but it needs breaking into surfaces that share the same texture as overlapping UV's is always the big problem

thats what makes it harder, creating a new unwrapped UV is a bit easier

Singular3D

OnlyLuvsCatz said:

Singular3D said:

I'd love to get the HD stuff to displacement maps. Is there a way?

I have asked about that often

there are ways but none of them simple or in DAZ studio

You can export two meshes and use Blender, Xnormal, Zbrush etc to do it but it needs breaking into surfaces that share the same texture as overlapping UV's is always the big problem

thats what makes it harder, creating a new unwrapped UV is a bit easier

Thanks for the fast reply. I'd love to get the HD stuff, like wrinkles and other details to a displacement map. You don't need such a high res mesh to render in engines like Vray, if you have a decent displacement map. As I understood the HD morph is just a morph, which means that the vertices are shifted of the hires mesh, where only PAs have access. You can export the hires mesh and try to make a displacement map with an external program, but I wonder, if there is a proper tutorial for Blender, 3DCoat or Substance.

I hoped that maybe there is a script in Daz available, or planned.

WendyLuvsCatz

no nothing in DAZ and not for lack of asking either

an improved map transfer that did texture baking as well would be lovely but

 ...I cannot really say much,

an occasional PA is lovely enough to have displacement maps as well and those work beautifully as expected in other softwares but most say it is too much work

been much discussed about it

I find it not much work to export a displacement map from ZBrush myself AFTER sculpting my high resolution mesh I cannot use in DS

NOT SPECULATION a PA said it  that they don't want to as they only want their morphs to be HDmorphs not something you can edit which you can a displacement map

 they are in that case protecting their Artistic vision I guess

there is piles of stuff for Blender and Zbrush etc out there on YouTube

once you overcome the UV hurdle there are plenty of ways to optimise mesh for games you can watch where they discus making Normal maps, Vector maps etc that can be applied

the UDIM is actually useful in programs that can read it and Zbrush can so I can in fact do maps using Zprojection between the meshes there but I am terrible at using Zbrush 

creating a new UV for the Base mesh then using both  in Xnormal is easier for me

then add that UV in surfaces and use map transfer

Blender has Texture baking I am terrible with Blender too

I bet MAX has many ways you could

 

 

 

 

TheMysteryIsThePoint

I already know that HD morphs are a top-secret commercial trade secret of Daz company

onix said:

But is there any way at all to access SubD geometry at all? like from the script or plugin?

The SubD geometry is available via the SDK, not sure about scripting. The call sequence is something like (no error checking):

node->update(true);

node->finalize(true);

auto object = node->getObject();

auto geometry = object->getCachedGeometry();

auto facetMesh = dynamic_cast<DzFacetMesh*>( geometry );

 

Matt_Castle

OnlyLuvsCatz said:

You can export two meshes and use Blender, Xnormal, Zbrush etc to do it but it needs breaking into surfaces that share the same texture as overlapping UV's is always the big problem

At least with G3 and G8, they don't have overlapping UVs (I've not checked G2, but I've never wanted to bake to G2). Each UV is offset by one width from the last - because the textures normally tile outside their boundaries, it means it loops back round and still selects the right pixels from the texture, but it also means that if you load all of the UVs onto a wide texture and then scale them to match, you've got a non-overlapping UV.

For example, if you want to displacement bake to G3 or G8, you make a 5:1 ratio texture, then scale the width of the UVs to 20%, and you get Head, Body, Legs, Arms and Mouth laid out in order, which can be chopped up in any decent image editor. You still want to separate off the eyes, teeth and (for G3) eyelashes because you don't want to be baking to or from these (it can cause problems with detecting which bit of model to bake from and to), but the mesh UVs are actually designed so they don't overlap.

I've been taking advantage of this a lot, because I'm still on Blender 2.79, which doesn't support UDIM (although Blender 2.8 apparently does, but the new version breaks a lot of my important scripts); recently, I was using it to paint the skin patterns for one of my established characters (so now I finally have a DS version of them, hurrah).

Richard Haseltine

Matt_Castle said:

OnlyLuvsCatz said:

You can export two meshes and use Blender, Xnormal, Zbrush etc to do it but it needs breaking into surfaces that share the same texture as overlapping UV's is always the big problem

At least with G3 and G8, they don't have overlapping UVs (I've not checked G2, but I've never wanted to bake to G2). Each UV is offset by one width from the last - because the textures normally tile outside their boundaries, it means it loops back round and still selects the right pixels from the texture, but it also means that if you load all of the UVs onto a wide texture and then scale them to match, you've got a non-overlapping UV.

For example, if you want to displacement bake to G3 or G8, you make a 5:1 ratio texture, then scale the width of the UVs to 20%, and you get Head, Body, Legs, Arms and Mouth laid out in order, which can be chopped up in any decent image editor. You still want to separate off the eyes, teeth and (for G3) eyelashes because you don't want to be baking to or from these (it can cause problems with detecting which bit of model to bake from and to), but the mesh UVs are actually designed so they don't overlap.

I've been taking advantage of this a lot, because I'm still on Blender 2.79, which doesn't support UDIM (although Blender 2.8 apparently does, but the new version breaks a lot of my important scripts); recently, I was using it to paint the skin patterns for one of my established characters (so now I finally have a DS version of them, hurrah).

I'm not sure I follow. You can certainly arrange the UV tiles into a single unit square, to paint in a tool that doesn't understand UDIMs, then split the result into separate maps for use in DS, but that was true with previous figures too - often people would tuck them into the four quadrants of a square mapping. The UVs require (simple) editing either way

Matt_Castle

This is a G8F figure exported from Daz (with the default Daz Studio OBJ settings, other than that I've turned "Write Groups" off), loaded into Blender 2.79 (with Keep Vertex Order on, which is necessary to make morphs anyway), and then opening the UV view:

The UV for each texture group is already offset. This isn't anything that's been done in Blender or by Blender, this is actually how the UVs are laid out. However, because textures are automatically tiled, it still ends up using the right bits of the texture when the tiling sliders are set to 1.

It can be proven that this is not something Blender has done, because it can create side effects in DS if you ever use tiling values that aren't 1 on the model. The texture's scaling origin is always at (0,0) , but the eyes' for example have their UV origin at (5,0). It's not very noticeable if you use whole number tiling values, but if you use a non-integer value like 0.5, the head, legs and mouth will use the left half of the now double width texture, and the torso, arms and eyes will use the right half of the texture.

To demonstrate, a texture with a blue left half and a red right half, with horizontal scaling 0.5. If the surfaces had a UV origin at (0,0), they should instead all be blue:

However, it's rare that anyone would ever want to tile textures on a figure in this way, and you couldn't expect any patterning to line up exactly anyway (even with tiling 1), so such side effects are basically a non-issue.

This has to be a deliberate design choice, and my best guess is that it's for the benefit of non-UDIM programs (or at least some related purpose).

If you create a 6:1 ratio texture to work on, then scale the UVs (about the origin) by a factor of a sixth, you've got a non-overlapping UV layout where each surface template is using a separate part of that 6:1 texture with barely any effort at all. (Or 7:1 for G3, which has the eyelashes as an extra tile).

Richard Haseltine

Yes, that's how UDIMs work. I was querying other perts of your post - the idea that being able to rearrange the maping onto a single UV square for painting was new, or that it didn't require some modification in software that is not itself UDIM aware.

Matt_Castle

OnlyLuvsCatz mentioned overlapping UVs and needing to split the model into different surfaces. I haven't checked every different figure, but the UVs don't overlap (or at least, they don't overlap if the UVs are clamped), and you don't need to split the figure to do displacement (or indeed any form of texture editing).

WendyLuvsCatz

Matt_Castle said:

OnlyLuvsCatz mentioned overlapping UVs and needing to split the model into different surfaces. I haven't checked every different figure, but the UVs don't overlap (or at least, they don't overlap if the UVs are clamped), and you don't need to split the figure to do displacement (or indeed any form of texture editing).

you do for Xnormal

Dolce Saito

This is a little bit late for answering, but just for reference mcjTailorChalk partially does what you need via scripting. It collides selected objects with (also) subD faces individually, should base geometry has bigger faces than what you collide.

onix

Richard Haseltine said:

You could always write your own HD plug-in with the SDK, though it would not be able to read the Daz dhdm files. I believe the mesh data, post-SubD, is available to SDK and probably Script but it's not an area I have explored.

Yes, that's exactly what I was asking.  Thanks.

I am interested in accessing sub geometry from the script specifically to make small dents in the surface.

Although if it is possible to write plugin for that, it is  pretty trivial to make a plugin which replicate dhdm functionality