Dickdator UV Map. Can not find a solution

[Jochen Sutter]

I’m trying the get the dicktator in any way to the HD figures in Blender. Everything works exept the UV-Map. The Dicktator cock has not the UV-Map wich I can use with the textures, In DAZ you must do this with the shell. But as soon I activate the geometry editor this shell UV-Map doesn’t works anymore and is not exported to Blender. So I did the UV-Map by hand. This was much work and as I tried to transfer the UV-Map to another Dicktator, but Blender makes a mess.

The picture left is the hand made UV-Map (I haven’t used the original textures here). the picture right is the result of the UV-Map transfer in Blender. It does not work correctly.

‌

Is there any way to get the UV-Map to the Dicktator to use the original textures in Blender? Or Is there a way how I can exchange the Dicktator Mesh itself of a figure? I tryed so many things in between. I could not figure out a solution wich I can use for every new figures. To make it by hand for every new figure is to much work.
Another solution would be to export the cock as a separated figure with its own bones etc. (this was a solution in Poser for me). But I could not export the cock separated with bones and morphs.

‌

[Alessandro Padovani]

The plugin does import shells, and dicktator works fine here. What doesn’t work for you ?

[garden]

You need to export the character with geografts and everything else WITHOUT HD.
After that, you should export the HD character WITHOUT geografts, geoshells, and everything else.
After that, put the character's HD mesh in the first collection (removing the base mesh as well).
After that, delete the second collection.

I use this method all the time, everything is imported correctly, with all UV and textures.

[Alessandro Padovani]

Well the “official” way is to enter the geometry editor before exporting to HD. That does everything you need in a single step.

http://diffeomorphic.blogspot.com/2020/09/hd-meshes-and-geografts-revisited.html

[garden]

Alessandro Padovani, As far as I remember, this method does not send UV from the geoshell, so here is this list.

[Alessandro Padovani]

Again, there isn’t any issue with shells. Or may be I don’t get what you mean. If there’s a bug please report it with some examples.

[Thomas Larsson]

I made a little tool that copies uv sets between identical meshes: Advanced Setup > Copy UV Set. Sound like it could solve Jochen’s original problem. Such a tool should be standard in Blender, but I didn’t find any. But maybe I didn’t look hard enough.

[Alessandro Padovani]

Thomas the tool to copy uv maps already exists in blender. And I’d be glad to understand what’s the issue here I don’t see any.

https://docs.blender.org/manual/en/2.80/editors/uv/layout_management.html

[engetudouiti]

btw blender default tool need to keep vertex order so if 2 mesh change vert order (like multiresolution)

it cause issue.. (though actually I can not test original issue , I seldom use daz product shell)

[Jochen Sutter]

Thank you for your answers. I will retry it. But my experience till here is the same like garden discribes. With the geometry editor activated, the  UV Map for the geoshell does not work anymore. But not only when exporting, the UV map of the Geoschell already no longer works in the DAZ Studio.

[engetudouiti]

I am not good about HD things, but I can suppose with geometry editor activated it not keep UV map anymore for shell.

because the reason why use geometry editor is, separate auto merge grafted mesh in daz studio as individual mesh.

with editor non active, shell need to cover merged mesh, then may need to create uv for the merged mesh.

but once activate geometry editor, now shell change. when I tell about geometry editor, I do not suppose shell UV things at all.

Then I understand what Jochen Sutter say, no longer works in daz studio. because, uv map only made for the merged shell.

‌

[Alessandro Padovani]

Again, if there’s a bug please provide a test scene, as simple as possible, and the steps to reproduce it. So may be Thomas can fix it. Personally I can’t find any issue with shells they seem to work fine here. But may be you’re trying something different.

[Jochen Sutter]

I don’t know if it’s a bug of the DAZ Importer (1.5.1). It’s just in DAZ Studio as soon I activate the Geometry-Editor the Geoshell UV Map doesn’t work.

‌

This is a render in DAZ. In the left pic is the Geometry Editor off. In the right pic it’s activated.

‌

For HD export to Blender the Geometry editor must be activated. Otherwise I get this error when I import to Blender

It still works anyhow, but I get this result. It looks as if there was 2 meshes into each other.

‌

[Alessandro Padovani]

SOLUTION

Ok I believe I got it. I didn't catch it before because I was trying with a subdivided mesh instead of a HD mesh. That is, if you export as HD a subdivided mesh the issue doesn't arise.

The issue is that for some reason the HD mesh doesn't get all the uv maps of the base mesh. I suppose that's why Thomas provided the "copy uv set" tool. Though it's not entirerly clear in his short note what to do with it. Again the tool is not needed because blender provides its own already.

Below an example with futalicious on Mutation HD for G8F, but it's the same with other HD figures. We see that the base mesh gets two uv maps while the HD mesh only gets one uv map. To fix the issue we have to copy the missing uv maps from the base mesh to the HD mesh.

https://www.daz3d.com/mutation-morphs-hd-for-genesis-8-female

https://www.renderotica.com/store/sku/57453_Futalicious-For-Genesis-8-Female

steps:

1. in daz studio load mutation HD and futalicious
2. enter the geometry editor and export HD
3. import in blender and check the uv maps, you’ll see the HD figure misses one and the rendering doesn’t work

‌

@engetudouiti , please note that the vertex order is the same so we can use the blender tool.

‌

steps:

1. Copy the missing uv maps from the base mesh to the HD mesh.

‌

@Thomas Larsson , instead of providing the “copy uv set” tool, that's not needed because blender already gets its own that does the same. May you check and copy the missing uv maps on import, so the issue doesn't arise in the first place ?

edit. important. Please note that the issue arises only if the HD figure gets multiple uv maps, as in the Mutation HD case above. If the HD figure gets a single uv map then everything works fine. For example Victoria 8 HD doesn’t get any issue.

[Jochen Sutter]

The other issue with the UV-Map transfer I’ve found out why it doesn’t work. It was the Vertex order. If I export the object with the original UV-Map to transfer I must check “keep vertex order “ and uncheck “apply modifyers”

You find the tool to transfer the UV-Map under “object / make links / transfer UV-Maps”

[Alessandro Padovani]

Jochen, that the shell is not visible in daz studio when you enter the geometry editor doesn’t matter. Because diffeomorphic gets the materials from the duf file. The geometry editor is only needed to bake separate meshes from the viewport.

As for the double geometry you probably didn’t delete the base mesh.

[Jochen Sutter]

@Alessandro Padovani In my case the HD-Version of the figure does not work if I have not activated the “geometry editor” when exporting HD from DAZ. I have no multres (the mesh is imorted in HD-single resolution) and the bones are not conected with the HD mesh. This double mesh of the cock is connected with the mainbody of the figure, I can’t delete it. And I get this error while importing.

only the LD-Figure works normal in this case

[Alessandro Padovani]

I suppose you may provide a test scene for Thomas to check. Unless he can guess what it is by the error itself.

@Thomas Larsson May you please fix the case with multiple uvs explained above ? It’s marked “solution” it explains what to do to fix it. Or if you’re not interested please let me know it so I can treat this case as a known issue. That is, HD works fine only for single uvs.

[Alessandro Padovani]

Jochen please note that you can’t upload blend files because the daz eula doesn’t allow it. Also in this case it is not useful because Thomas needs the duf file for testing, plus the steps you follow.

As for the errors, the first may be normal because it is not always possible to unsubdivide an object for multires. Depending on the object geometry. I’m not sure about the second.

[Jochen Sutter]

Ok, I have deleted it, if it’s not allowed. But I can explain in less steps what I’ve done

1. Load genesis 8 basic male
2. Load 1_Dicktator Genitalia 0.3
3. Load Dicktator Material
4. Load Dicktator Shell
5. Klick on Dicktator shell in scene
6. Load Shell DK Textur set 1_IRAY
7. set Genesis 8 and Dicktator genitalia to subD Level 3

‌

So that’s the situation so far

‌

‌

1. Then save as scene while Geometrie Editor is not activated
2. Export HD tp Blender
3. In Blender Import DAZ with Version 1.6.0.0339

‌

in in Blender The genesis 8 Male_HD mesh is joined with the dicktaor and the UV Map doesn’t work.

‌

[Jochen Sutter]

If I do the same procedure with activated Geometry Editor I get no error message in Blender and everything workes fine, exept the Dicktator has not the UV-Map of the Geoshell.

It’s not a problem for me at the moment, because I can use my hand made UV-Map wich I can transfer to the Dicktator so I can use my old Textures from a Cock I used in Poser before.

[Alessandro Padovani]

Yes if I follow your procedure I get the same error but it’s not the way to do it. Then if I use the geometry editor everything works fine including the dicktator uv that I can see in the uv maps and the shell works fine too. So again I can’t understand what’s your problem here.

As a side note either G8M and dicktator are not HD so you don’t need the HD export in this case. So I guess this is for test purposes only.

As another side note please avoid depiction of genitals if not necessary. It’s ok for me that is I don’t get offended myself but this forum gets no age restriction so you may be careful.

steps:

1. in daz studio load g8m and dicktator and subdivide as you like
2. enter the geometry editor and export HD
3. import in blender and delete the base resolution meshes that you don’t need
4. merge rigs then merge geografts

‌

‌

[Jochen Sutter]

It was just a simple example with the G8M base figure. Otherwise I use hd characters. I need the HD export. Maybe I don’t understand it not good enough to know what’s the issue.

But easy. I’ve found the way how to transfer my hand-made UV-Map to the Cock. So I think I have solved all my relavant issues to use the HD characters in Blender so far. I’m shure there will be enough other questions to solve. For the moment I’m happy. Thank you very much for your help.

[Jochen Sutter]

Sorry for posting the pictures. I’ve deleted it.

[Alessandro Padovani]

Thomas please let us know if you may want to fix the case with multiple uvs as described in “solution” above. Otherwise Jochen may mark as resolved so we close this one.

[Thomas Larsson]

I had forgotten about this issue, but now the extra UV layers are added. However, only if the HD mesh has an multires modifier. Adding extra UV layers to true HD meshes means that they have to be exported from DS first. This would not be the same performance distaster as exporting HD vertex groups, since we only expect a few extra UV layers, but I would rather not mess with the HD export code. In the multires case the extra layers can be copied from the base mesh in Blender.

[Alessandro Padovani]

Thomas, commit c96f6d4 doesn't seem to work fine. That is, the uv maps are not copied correctly. Below an example with mutation + futalicious. Test scene included muta.duf.

steps:

1. load muta.duf in daz studio, enter the geometry editor and export to HD.
2. import muta.duf in blender
3. check the uv maps for the base resolution version, they're good
4. check the uv maps for the HD version, you'll see the maps are copied wrong, for example "Mutomorph_Female_UV" seems copied to "Base Female".

Below an example where I selected the face material to show the uv map. We see the base resolution is good, while the HD version gets the "Mutomorph_Female_UV" map copied to "Base Female".

‌

‌

I suspect you may not use the "copy uv maps" tool right. To copy uv maps in blender we have to first create the new uv map then copy the uv coordinates. This way the map is copied correctly.

For example if I want to copy "Base Female" to the HD version.

steps:

1. in "Genesis 8 Female Mesh" select the "Base Female" uv map
2. in "Genesis 8 Female HD" create the new uv map "Base Female" and select it
3. select "Genesis 8 Female HD" then crl select "Genesis 8 Female Mesh", the selection order is important
4. object > link/transfer data > copy uv maps

‌

[Alessandro Padovani]

test scene for multires HD uv maps

[Thomas Larsson]

Fixed in last commit. The HD export script exports the active uv map, and the importer was confused because the active uv map was not the first one in the muta case. Now the uv map in the dbz file is only used if multires is turned off (or fails for some other reason). With multires all uv maps are copied from the base mesh, which gives all uv maps in the right order.

Note that this problem only arose with several uv maps and active is not first. So the genitalia case worked ok because the background body uvs were both active and first.

[Thomas Larsson]

Correction: The exported uv map is a mixture of the two uv maps for the base mesh, depending on material assignment. This means that there are problems with materials that refer to the uv maps by name.

‌

[Alessandro Padovani]

daz studio 4.15, blender 2.93, commit 17aadae

Thomas, I’m not sure to understand what you mean. As for commit 17aadae it doesn’t seem to work fine though.

It’s quite odd. The uv maps seem fine, but the rendering gets strange blocks as if the vertex order is not preserved or something. At this time I have not a solution to this or a clear idea of what it could be.

Below the test scene muta.duf as rendered in cycles.

‌

[Thomas Larsson]

The HD materials are the same as the base materials. That leads to problems with uv and normal map nodes, which refer to the uv map by name, if there are multiple uv maps. But this is only a problem for the true HD mesh; the multires mesh has several uv maps.

Your problem is a different one though, perhaps related to #589. If multires inverts some normals there isn’t much I can do, I suppose.

[Alessandro Padovani]

update. important. possible solution.

Thomas, commit 828ff63 doesn’t fix the issue. But it seems it’s not the multires modifier. That is, if I disable multires in the global settings, then I add the multires modifier myself and unsubdivide, then the materials work fine.

I guess it must be something when you transfer the weightmaps and morphs.

‌

edit. Since the multires vertex order is the same, I can get a rigged mesh by just copying the vertex groups and adding the armature modifier. This way the materials work fine and the HD mesh is rigged. That is, I don’t need to use the transfer modifier I just copy the vertex groups.

‌

[Thomas Larsson]

The previous commit solved a different problem, namely that the true HD meshes must have materials that are different from the base materials, since they refer to different uv sets. I now added a new option Use Multiple UV Sets, default off, so we can use the single imported uv set for multires meshes too. Again, that means separate HD materials. This seems to do the trick.

Apparently copying the uv set from the base mesh to the multires mesh does not work properly. If we compare the uv sets created by the two methods, we see that they differ slightly, which may explain the discrepancy.

‌

[Thomas Larsson]

Also note that materials that use multiple uv sets, typically materials with shell nodes, will not work with HD meshes.

[Alessandro Padovani]

Commit 4c910a5 works great thank you Thomas for the fast fix. If Jochen has nothing to add I’d mark as resolved.

I’m not sure to understand what the new option “use multiple uv sets“ is for. I mean, if I check it then the issue is back so it seems to me that this option is broken and not useful. Or is there a case where it works fine ?

edit. I can confirm that “copy uv” seems to produce a slightly different map as in your example. Not sure why or if there’s a fix.

[Thomas Larsson]

Yes, I agree that the option is quite useless. If there is no simple way to fix it, I’ll remove it. But it is a pity if shells don’t work with HD meshes.

[Thomas Larsson]

Option removed.

[东方夕惕]

The “Copy UV Maps“ command of blender seems not work fine when transfer UV of base mesh to multires HD mesh generared by import_daz.

I remove subdivision modifier of base mesh and multires modifier of HD mesh. I find them have same vertex number and vertex order.

Then I select both of them, make base mesh is active, then hit “Ctlr L“ chose “Copy UV Maps“.

The result UV layout of HD mesh look same as base mesh, but the render is strange like Alessandro posted.

I select a vertex of face in viewport, but there are four vertex highlighted in UV editor. It seems some faces in UV are rotated and not connect to each other.

I think the UV should be transfered right since they have same vertex number and order, but it doesn’t transfer correctly. It’s very strange.

‌

‌

[东方夕惕]

I linked a test blend file without textures. If you want to test, you should find missing files in your computer with G81F textures.

https://drive.google.com/file/d/19cBF_I8Bt7_xFB2QWvdU1gG0pwqeupyO/view?usp=sharing

[Alessandro Padovani]

Thank you Xiti for reporting this. I can reproduce the same behaviour here. It seems multires somewhat “scrambles” the geometry faces, even if the vertex order is the same. May be this is also the cause for #382. Unfortunately if this is the case I feel there’s nothing we can do since it’s a flaw in the inner workings of multires. I mean other than reporting the “bug“ to the blender team.

Also please @Xin let us know your opinion since you are often confident with the inner workings of blender.

edit. The interesting point is that on point 2 below the uv map is good in the multires version. So just adding multires somewhat preserves the uv map. Then the uv map gets scrambled in point 3 when I copy uvs.

edit. Thomas, may be you could try to write your own copy uv as “multires compatible“, to see if you can fix this ?

steps

1. import G8F at base resolution
2. duplicate, then add and apply subdivision, then add multires and unsubdivide
3. on the duplicate delete the uv map, then create a new one, then copy uvs from base to duplicate
4. select a vertex

‌

[Alessandro Padovani]

update. important. Please note that using the HD addon by Xin we preserve the multiple uv maps on the HD figure. This is because the HD mesh is derived by subdivision from the base mesh importing the dhdm, so “copy uv” is not used.

[Xin]

Oh, I hadn’t seen this issue before. I will check later what could be the cause.

If face order is different for some reason (use face selection mode to see face order), then there will be a problem because Blender’s Copy UVs tool depends on both face order and vertex order. In that case, a tool could be written such that UVs are copied by only matching vertex order, removing the face order dependency. I will check it later.

[Alessandro Padovani]

Xin, nope in my tests it seems both the vertex order and the face order and the edge order is preserved by multires. Nevertheless “copy uv” is able to make a mess. If you can write a “copy uv” that works fine it’s great so we can have multiple uv maps with multires too.

‌

[Xin]

Ok, the attached script seems to work fine. The issue seems to be some inconsistency between meshes regarding the “loop” indices that Blender uses internally. You can sidestep that by pre-creating a map from “face id and vertex number” to “loop index” as the script does.

[Alessandro Padovani]

Xin, thank you so much that is excellent. I modified the script parameters for G8F and it works great here. Thomas, can you use the script by Xin to get back multiple uv maps for multires please ?

‌

[Alessandro Padovani]

Thomas, I feel like you just skipped this so this is s head up. Or please let us know your opinion, that is, if there’s any reason why the “uv copy” by Xin can’t be used.

[Thomas Larsson]

Yes, you were right, I lost track of this thread. Xin’s algorithm is implemented in the last commit, and the result is better, I think. However, it is not the same as what you get when you import a single UV map, and I don’t think it can be. I previously pointed out that the base and HD UV coordinates are not the same for some vertices https://bitbucket.org/repo/d6jezKE/images/1364530490-muta-uvs2.png. No amount of reshuffling loop indices can fix that.

‌

[Alessandro Padovani]

As for commit 3f02277 the uv maps are preserved, but they’re not selected right. That is, the active uv map is not right. Below an example with mutation + futalicious, test scene included muta.duf.

The face uv map should be “mutomorph female uv“ and not “base female“. Same for the other mutation materials.

steps:

1. in daz studio enter the geometry editor and export the muta.duf test scene as HD
2. in blender import the muta.duf tests scene, then merge rigs and geografts
3. check the materials

‌

As a minor side note, instead of using the “uv map” node, it would be better when possible to use the “texture coordinate” node with the active uv map selected in the object properties. Otherwise the material preview doesn’t work and that’s rather annoying especially for material editing if we don’t get the preview.

We could always use “texture coordinate“ and use “uv map“ only for shells. This way the material preview will work for all the materials but shells.

‌

[Alessandro Padovani]

test scene for HD figure with multiple uv maps

[Xin]

The reason why the match is not perfect is the same reason why the unsuibdivided multires mesh itself is not perfectly the base mesh. The multires “unsuibdivision” process won’t give you the exact same result as a base import, either with the mesh or the UVs. But the match is close enough it doesn’t matter.

‌

[Thomas Larsson]

Alessandro, I pointed out in https://bitbucket.org/repo/d6jezKE/images/340292519-muta-multires-uvs.png that the HD UVs are a mix of the two UV maps. Some materials (eyes and teeth) use the Base Female UVs and they are previewed correctly. You could perhaps use some heuristics and say that it is more important to pick the UVs of the skin materials, but that would be prone to errors.

Or I could write a tool that changes the render UV map and update the materials.

[Thomas Larsson]

Xin, in some cases it does matter.

‌

[Thomas Larsson]

Merging geografts will be problematic anyway, since the gens UVs line up with Base Female, not with Muta. If you uncheck the Merge UV Layers option you can avoid white patches, but looks good it does not.

[Xin]

Ok, I checked and I can’t reproduce the second result from above when you do what Alessandro pointed out: changing the UV map in the materials to “Mutomorph_Female_UV”. The issue is that the second result from above seems to be using the “Base Female” UV, and of course that one will render wrong.

I don’t think the issue here is the small multires unsubdivide discrepancy.

[Thomas Larsson]

No, the UV set only affects the material preview. The UV map nodes pick the right named UV set irrespective of which is the active one.

[Alessandro Padovani]

Thomas, you are right that some materials use different uv maps. But we don’t need to use heuristics for that, the uv map to use is found in the geometry properties of the daz material. So for example for the “face“ material you can see that the right uv map to use is “mutomorph female uv“ and not “base female“.

Again commit 3f02277 is using the wrong uv map. As Xin reported the bad render in your “multi layers“ example is due to using the wrong uv map, not to the small difference in the uv mapping. Please check.

‌

edit. Now I understand what you mean that’s not possible to select the right uv map for the preview when there are multiple uv maps. Because the preview uv map in “texture coordinate” is per object, and not per material. As heuristic I’d point to use the face material that’s perhaps the most important.

Nevertheless the uv map nodes use the wrong uv map this can be fixed because they are per material.

[Thomas Larsson]

Not sure what I was thinking yesterday. Now I agree that the UV map wrong. Corrected in last commit.

[Alessandro Padovani]

Commit 5f9146a works fine here, so we get multiple uv maps for HD figures too. Thank you Xin and Thomas for this nice update.

[Xin]

Since the multires HD doesn’t use the exported UVs with this method, maybe ignoring the UVs during the HD export from daz could make the exporting faster.

[Thomas Larsson]

Perhaps, but I’m not really fluent in Javascript which is the scripting language of DS, so I wouldn’t try it. Besides, if multires fails or you want the true HD mesh for some reason, the true HD UVs are needed.

[Alessandro Padovani]

Out of curiosity I did a little test and removing the uvs I get from 20 to 15 seconds to export mutomorph HD. As for the code it seems it’s enough to remove doUVs() and everything seems to work fine here.

Then I agree that having a HD mesh with materials may be useful in some cases, for example if one wants to export a static HD scene just for rendering. But we could just provide two export scripts with and without HD uvs, where the deafult is without UVs that are not usually needed.

// in export_highdef_to_blender.dsa remove doUVs() at line 159
// doUVs(fp, geom, "hd ");

# in objfile.py remove "hd uvs" at line 177
# uvs = figure["hd uvs"]

‌

[Thomas Larsson]

I would rather not maintain and document two scripts that do essentially the same thing. In Blender I would add an option to the file selector so the user can decide if the UVs should be exported or not, but I don’t know how to do that in Dazscript. I think I saw something about building custom dialogs once, but not how to combine that with a file selector.

[Xin]

I don’t really know anything about the daz api, so I looked it up a little and I think the attached script does what you want.

[Alessandro Padovani]

Tested the scrtipt and it works fine here, apart that objfile.py needs to be modified to handle the case with no uvs. Also may be the global setting for “add multires“ can be omitted now since we already get the option in the export panel. I mean we add multires if there are no uvs.

‌

[Thomas Larsson]

Xin’s script has been included and some errors from the missing uv data have been cleaned up. It is not super elegant to have to deal with two popups, but I much prefer that over two copies of the code.

[Thomas Larsson]

Alessandro, we still want to be able to import a HD mesh with multires and a single UV layer. Yes, it takes longer to export the UVs, but once in Blender it will consume less resources. Two UV layers uses twice the memory than a single one.

The export option has been renamed for this reason. It is now called “Export HD UVs”, which more accurately describes what it does.

[Alessandro Padovani]

Commit 406e4ce doesn’t seem to work fine. It doesn’t handle the case with a true HD mesh and geografts. Not sure if I miss something may be this is a limitation that I’m not aware of.

If I test mutation without futalicious then it works fine.

steps:

1. in daz studio load the muta.duf test scene, that's mutation plus futalicious
2. do not enter the geometry editor and export to HD with “export hd uvs” checked
3. in blender uncheck “add multires“ in the global settings
4. import the muta.duf test scene and render the HD mesh, you’ll see some uv map is missing in the legs and arms, other than in the geograft area.

‌

[Xin]

Thanks Thomas for the changes. I think all daz exporters work with two popups like that, I don’t think daz has a Blender-like type of interface.

Alessandro, if that problem didn’t exist before then it could be an issue with the new Python code in Blender.

[Thomas Larsson]

This bug didn’t have anything to do with the recent changes but has been around for a long time. For some reason the materials were reordered in the mesh with joined geografts. In the new commit the materials should appear in the right order. At least the body materials. The geografts materials are searched for in bpy.data and might perhaps be confused in some situation, although it works in this case and probably most of the time.

[Alessandro Padovani]

As for the true HD mesh commit e8cdf51 is better. That is, the figure materials seem to work fine. As for the geograft shell, the textures are imported correctly but they use the figure uv map instead of the geograft uv map. That is, the shell uv map is not imported and not used.

Below we can see futalicious using the “base female“ uv map, that’s correct for the geograft materials, but not for the shell materials that use the “futalicious uvs v2“ uv map in daz studio.

That is, the shell textures are imported fine, but the shell uv map is not.

Again mutation without futalicious works fine and multires works fine. This is only for the true HD mesh with geografts.

‌

[Thomas Larsson]

This will be difficult to fix, I think, because DS and the plugin treat shells differently. In DS the cached geometry has unique UVs, which is the body UVs because they are needed for the background torso textures. The futa UVs and textures are located in the futa shell, which is a mesh at base resolution. The shell is then somehow projected onto the base render. In Blender we need the futa UVs at high resolution, because the shell has become a node group. But the HD futa UVs don’t seem to be available in DS, so they cannot be exported.

When testing this I encountered another problem, which may be related to #649. The script crashes in the script editor because a QObject had been deleted. When run directly it seems to work fine, presumably because the data still resides in memory even if it has been deallocated. If I enter the geometry editor the code works fine both directly and from the script editor.

[Alessandro Padovani]

I was expecting the shell HD uvs to be available in the viewport data the same as the figure HD uvs. If this is not the case then I understand it can’t be exported.

May be it can help to set the geograft to the same subdivision level as the figure before exporting. To see if this forces the HD uvs for the geograft too. Otherwise we just report the limitation in the docs that shells are not supported for true HD figures.

As a side note the HD addon by Xin is much better at handling true HD figures, since it also provides a rig with HD jcms. So we may also drop true HD in favor of multires and leave true HD to Xin.

‌

[Thomas Larsson]

I like the idea of leaving true HD to Xin. It isn’t anything that I use myself, and besides I want to draw a line and not add any new features until after the release of version 1.6.0.