Can we make HD meshes with NON Genesis characters? ** aka better multires **

[Jasper29]

Blender 4.1.1 Diffeo v4.2.0.2174

Hey guys, sorry if this has been covered already, but recently I tried importing a DAZ Horse 2 character, Mount of the Abyss Mount of the Abyss HD for DAZ Horse 2 | Daz 3D with HD body morph using the same method as one would with a Genesis character (Geometry Editor, importing as HD) and I got the error below. I don’t remember if Diffeo can handle non genesis meshes (probably not) but just wanted to confirm. We can close this as invalid if so. Here is the error as well as steps to recreate:

steps to recreate:

1: Select Mount of the Abyss character with HD morph enabled in DAZ and set mesh resolution to 2.

2: With mesh selected enter geometry editor and save file as scene, then export to Blender as HD.

3: Easy Import.

‌

[Alessandro Padovani]

4.2.0.2174, blender 4.1

https://www.daz3d.com/daz-horse-2

https://www.daz3d.com/mount-of-the-abyss-hd-for-daz-horse-2

Yes we can import HD for any mesh. In this case it is not needed to enter the geometry editor since there’s no geografts. The triax warning is not an error, it simply states that the figure uses triax weights that will be approximated in blender since there’s no native support for triax.

bug for Thomas. multires. I can confirm the issue that the addon can’t rebuild subdivisions, normally this is expected since multires may fail, this is a blender limitation not a bug. But in this case I can rebuild subdivisions by hand without any error, so there must be something odd.

my steps:

1. in the global settings uncheck “add multires”
2. import the test scene h2.duf as HD
3. add a multires modifier and rebuild subdivisions
4. transfer the weights from the base mesh and apply the armature, everything works fine

‌

[Alessandro Padovani]

test scene for horse 2 HD

[Alessandro Padovani]

update. If I look at the vertex count for the multires and base meshes they are different, it’s 37656 vs 37652. So multires can rebuild subdivisions but the topology is probably not the same. We can still transfer weights and morphs by nearest vertex, that’s what I did and seems to work fine.

It is possible that other meshes are affected by this bug, where the addon reports a failure while it is possible to build and use the multires mesh. In this case though we have to keep the base mesh and transfer morphs by nearest vertex, since loading morphs directly on multires will fail because of the vertex count.

bug. transfer morphs. There’s a minor bug, that transferring morphs from the base mesh to multires works fine, but the morph slider doesn’t work, that is, I can input the values but I can’t scrabble the sliders as usual.

steps:

1. import some morphs to the base mesh
2. transfer morphs to multires by nearest vertex
3. check the sliders, we can input values but not scrabble as usual

‌

[Alessandro Padovani]

possible solution. In this case, instead of reporting an error “can’t rebuild subdivisions“ and abort, the addon could rebuild subdivisions, then transfer weights and morphs from the base mesh if any, then keep the base mesh, then throw a warning “multires vertex count mismatch, please transfer custom morphs from the base mesh“.

# import HD
rebuild subdivisions
if vertex count mismatch
  transfer weights and morphs by nearest vertex
  keep base mesh
  warning "multires vertex count mismatch, please transfer from base mesh"

‌

[Alessandro Padovani]

another solution. Xin addon. Or another solution in this case is to bake a displacement map for the base mesh with the Xin addon. That’s probably easier.

[Jasper29]

Thanks for looking into this Alessandro--yeah i know Xin’s addon would be the easier route but I just happened to do this through the importer first and figured I’d post it for confirmation whether Diffeo would do it. Quick question though, how do the morphs work when transfered from the base mesh to the multi-res/HD mesh if the vertex counts are different? I know you can delete genesis characters eyes (G8 eyes are part of main mesh) and still transfer morphs onto mesh even after merging geografts with vertex table enabled.

[Alessandro Padovani]

Morphs will work the same as they work for outfits, transferred by nearest vertex. If multires only differs a little from the base mesh it will work fine, that should be the case. Geografts have to be merged as a last step.

[Thomas Larsson]

I finally had a look at this. As Alessandro says, the problem is that the multires mesh has a different topology than the base mesh, so we cannot copy uv coordinates or vertex groups. In the last commit I changed the global multires setting to have three values:

• Ignore: Don't add multires modifier but keep the original HD mesh.
• Consistent: Only add multires modifier if the multires and base topologies are identical.
• Always: Always add multires modifier if possible. Vertex groups and materials may be assigned incorrectly.

‌

In this case we have to set Multires = Always. Also disable the Multiple UV Layers option, which tries to copy uv layers from the base mesh.

If Multires = Consistent, no multires is generated due to the vertex count mismatch, and we get the following warning.

‌

If Multires = Always, we get a warning that the plugin couldn’t copy vertex groups between meshes with different vertex count, so we have to do that manually with the Advanced Setup > Mesh > Copy Vertex Groups tool,

‌

The HD morphs work fine here, provided that we both copy shapekeys and vertex groups to the HD mesh.

‌

[Alessandro Padovani]

Thank you for looking at this. The new options can be useful to try and fit multires to difficult figures.

If @Jasper has nothing to add we can close as resolved.

[Thomas Larsson]

I looked a bit more into this and made some changes.

1. The multires option is a boolean again.
2. If rebuilding subdivisions succeeds but the vertex count is wrong, the plugin now uses data transfer to copy vertex groups, so the multires mesh is posable even in this case.
3. If Multiple UV Layers is disabled, the HD UVs in the dbz file are used.

This should give a useful multires mesh as long as there is only one uv layer, i.e. there are no shells. But now I notice that the data transfer modifier apparently can transfer uvs as well, so that it may be possible to overcome that limitation.

‌

[Alessandro Padovani]

Commit bbaab5f.

That’s even better, thank you. The materials seem to work fine from HD uvs.

bug. weight maps. Here the weight maps are not transferred though. Also it would be useful to get a warning when the vertex count doesn’t match, to be aware that an approximation is used with transfer instead of copy.

steps:

1. import HD with “multires” and without “multiple uv layers”

‌

update. triax ?

I see the HD mesh gets the triax weights, that’s why the armature doesn’t work. So I guess the transfer is done before triax conversion.

‌

[Thomas Larsson]

I didn’t see this problem because I normally keep the option to improve triax weights off. But now the HD mesh moves also with improved triax weights. Note that the multires modifier is first, because it cannot be moved past the vertex weight mix modifiers. This doesn’t seem to cause any problems.

[Alessandro Padovani]

Commit ed4c60f, blender 4.x.

bug. wrong error. I get an error if I don’t export the HD uvs, apart that everything works fine so the error doesn’t apply, I mean HD uvs are missing of course but multires is generated and vertex maps transferred so everything works fine.

steps:

1. export HD without HD uvs

‌

note. warning message please. I believe we need a warning message if multires doesn’t match with the base geometry, to be aware that vertex maps are transferred instead of copied, which is approximated and may generate artifacts on occasion. Same if transferred uvs are used instead of HD uvs.

“warning: multires vertex count mismatch, vertex maps are transferred instead of copied, there may be artifacts”

[Alessandro Padovani]

Commit ed4c60f, blender 4.x

bug. add armature to HD meshes. The tooltip tells this is “for true HD meshes”, but it seems we need this option for multires too, otherwise the armature is generated without weights so doesn’t work. For true HD meshes the option works fine when it is on, but we get an error when it is off. Tried both blender 4.1 and 4.2.

workaround. Always keep the option on.

steps:

1. import with “armature to HD“ off and “multires” on
2. the armature is generated without weights so doesn’t work

steps:

1. import with “armature to HD“ off and “multires” off
2. we get an error

‌

[Thomas Larsson]

Better warnings in last commit. The error seems to be Blender 4.2 specific, hopefully gone too.

I think it might be possible to do something better with HD geografts. Currently the suggestion is to export from the geometry editor, but then shells are missing.

[Alessandro Padovani]

Commit 43af5d8.

The error is gone and the warnings are fine, thank you for the fix.

As for HD geografts IIRC we can’t read HD uvs for shells, so I guess you should always transfer in this case. Anyway most geografts are not HD so they should be fine at base resolution. That is, we set the geograft at base resolution in daz studio if it is not HD, then when we enter the geometry editor it should have the base resolution uvs for shells, same as non HD.

possible bug. HD armatures. Even with “HD armatures“ off, the armature is always imported, though there’s no weight maps. That is, the armature is not linked to the mesh but it is always imported anyway, with no weight maps. Perhaps the expected behavior is to don’t import or delete the armature for HD meshes in this case. Unless the armature is needed for the base mesh when we “keep base meshes”. Let me know.

‌

[Thomas Larsson]

Now it is possible to import HD meshes with merged geografts and shells. You need to update theHD dbz exporter, because it now also exports the shell UVs which are imported as extra UV layers of the HD mesh. Vertex groups are copied with data transfer from the base mesh and base geografts if the vertex counts don’t match. This can give minor artifacts, but so far I haven’t noticed any.

So far it is limited to a single geograft with shell, and I have only tested with G8M with dicktator and pumping pole palette. I will write something about it when things become more stable.

I removed the keep base mesh option, because it led to some problems and it is easy enough to delete the base hierarchy in the outliner.

[Alessandro Padovani]

Thank you for your work, this is certainly a big step forward for HD figures. Personally I’m not a fan of HD but there’s a number of interesting figures. I’ll do some tests myself and let you know how it goes.

p.s. To “keep base mesh” is essential if we want to transfer custom morphs later. Otherwise we have to use daz favorites.

[Thomas Larsson]

Yes, now the base meshes are always kept. The user can easily get rid of them in the outliner.

[Alessandro Padovani]

Commit 3a91e46, blender 4.2 beta

I’m trying Queen of the Abyss with Futalicious.

https://www.daz3d.com/queen-of-the-abyss-hd-for-genesis-8-female

I fail to understand how “copy graft groups“ is supposed to be used.

• if I select the geograft then the HD figure as active it says “no base object selected“
• if I select the HD figure then the geograft as active I get a python crash

‌

p.s. The old workflow with the geometry editor works fine.

[Alessandro Padovani]

possible bug. transferred vs copied. In my test with “queen of the abyss“ I see that only the spikes mismatch while the figure itself doesn’t. In this case the uv map for the figure should be copied instead of transferred. Unless this is only a misspell in the dialog box in this case it’s acceptable. Let me know.

‌

[Alessandro Padovani]

possible simplification. If transfer works fine then HD uvs are only needed for true HD. Furthermore it is rare to have HD geografts most are non-HD. Thus for a workflow based on multires it is enough to transfer from the base mesh when there’s a mismatch. We could keep the geometry editor workflow and get back the “keep base mesh“ option, to switch off for easy import with daz favorites and merge geografts, thus having a simple and fast option for HD.

Let us know what you think.

[Thomas Larsson]

I found a number of bugs myself, but things are still in a flux.

The copy grafts groups tool requires that the HD mesh is active, and that both the grafts and the base mesh are selected. The base mesh is needed to select the graft part of the HD mesh. I assume that the graft part consists of the faces that have materials not found in the base mesh. Hence this tool does not work correctly if materials have been merged. But it is primarily intended to be part of easy import, where it is done first.

I suppose that the keep base mesh option can be useful. However, it should not be done during manual import as before, but at the very last step of easy import. This is to avoid problems with references to deleted objects, which is why the option was removed.

[Alessandro Padovani]

Commit 6770998.

bug. HD shapekeys. Ok “copy graft groups“ seems to work. In my test with “queen of abyss“ I selected some “futalicious“ morphs as daz favorites, they are imported to the base mesh and transferred to multires. However the shapekeys are not transferred so the HD morphs don’t work.

Let me know if you need a test scene I can provide mine with “queen of abyss“.

p.s. The standard workflow with the geometry editor works fine.

[Thomas Larsson]

Now shapekeys are tranferred and the keep base mesh option is reintroduced.

The drawback with the geometry editor workflow is that shells are missing, which is pretty significant for geografts.

[Alessandro Padovani]

Commit 176c3da, blender 4.2.0 beta.

bug. HD shapekeys. Now the figure shapekeys are transferred to multires, but the geograft shapekeys are not. Thus the geograft morphs don’t work.

steps:

1. in daz studio load a HD figure with a geograft, and set some daz favorites for the geograft
2. export HD without entering the geometry editor
3. in blender easy import as dbz, with “daz favorites” and “transfer to HD”
4. copy graft groups
5. the geograft shapekeys are not transferred to multires

As for missing shells with the geometry editor, that is only for true HD not for multires, since multires is always copied or transferred from the base mesh which has shells. Personally I never export HD uvs and never use true HD. True HD was a workaround if multires failed, but now that we can transfer this case should be rare.

Honestly I don’t see much use for true HD, this is why I proposed the “possible simplification“ above. Unless I miss something.

bug. python error. Now I get an error when trying the standard workflow with the geometry editor, with “keep base meshes“ off.

‌

bug. keep base meshes. It seems “keep base meshes“ off deletes all the base meshes, including geografts which don’t have a multires counterpart because they are not HD. Thus when easy import tries to merge geografts it doesn’t find them because they are deleted.

fix. Only base meshes with a multires counterpart should be deleted, as it was before. If we use the new workflow “keep base meshes“ must be on anyway so this doesn’t matter, the option is for the old workflow with the geometry editor. We could rename it “delete multires base meshes“ if it’s more clear this way.

[Alessandro Padovani]

Commit a821e29, blender 4.2.0 beta.

The python error is fixed, but the bugs are not. I'm including my test figure, she's a bit "extreme" but that's what I have easy by hand to show the issues. The figure uses some daz favorites for the geograft morphs.

https://www.daz3d.com/queen-of-the-abyss-hd-for-genesis-8-female

bug. HD shapekeys. With the new workflow, the geograft shapekeys are not transferred to multires.

steps:

1. in daz studio export as HD, without the geometry editor
2. check "keep base meshes"
3. easy import with "daz favorites" and "transfer to HD"
4. copy graft groups
5. the geograft shapekeys are not transferred to multires, thus morphs don't work

‌

bug. keep base meshes. With the old workflow, the non-HD geografts are deleted.

steps:

1. in daz studio export as HD, with the geometry editor
2. uncheck "keep base meshes"
3. easy import with "daz favorites" and "merge geografts"
4. the figure imports without geografts, because they are deleted by "keep base meshes"
5. the base mesh collection is not removed, everything should be in the HD collection

workaround. Import with “keep base meshes“ and without “merge geografts”. Then do by hand.

‌

[Alessandro Padovani]

test scene for HD figure

[Thomas Larsson]

It is not so easy to get all cases right, but I think we are closing in, at least for the old workflow. Some bugs remain for the new workflow.

[Alessandro Padovani]

Commit 63b498b.

bug. keep base meshes.

Now with the old workflow easy import doesn’t merge geografts. Steps as above. Futalicious is named as “HD” even if it isn’t. After merging the geograft by hand we get two favorites morphs doing the same thing.

You may want to read my notes above under “fix“. That is, “keep base meshes“ is only needed for the old workflow so it should be tailored to that.

‌

note. If it is too hard to get “keep base meshes“ and “merge geografts“ to work, then you may remove the options, the user can always do by hand. It is better to don’t have the options than having them not working. Then of course having them working would be better, if possible.

[Alessandro Padovani]

Commit ee07522.

I have the same bugs as the previous commit above. Merge geografts doesn’t work. Two favorites are generated for the same geograft.

workaround. Revert to commit a821e29 to avoid the duplicate favorites, then easy import with “keep base meshes“ on and “merge geografts“ off, then do by hand. It is also a possible fix to revert and remove the options. Though this would be a regression since options worked fine with the old workflow.

possible simplification. Again, the new workflow without the geometry editor is only needed for True HD, which personally I consider a workaround when multires doesn’t work. We only need the old workflow with the geometry editor and it will work fine in all cases now, improved with transfer when there’s a mismatch.

[Thomas Larsson]

I don’t have the queen of the abyss, but I don’t think it matters, since I see the same issues with other assets.

The duplication of favorite morphs is fixed.

The double geografts is on purpose. Now the objects in the base and HD collections are completely disjoint, so we can do things like merging geografts in one of them without affecting the other. In particular the HD graft remains even after the base graft has been merged or deleted. Then I can agree that it might be confusing that its name ends with “HD” when it is not.

The “HD” grafts are made from the base graft by making a new object with the same mesh. Graft shapekeys are not transferred to the HD objects, but since the meshes are the same it is not necessary in the old workflow. In the new workflow it is a limitation.

In the new workflow “HD” grafts are not created at all, since they are already part of the HD mesh.

[Alessandro Padovani]

Commit 88f17e5.

There's issues but I can work around by hand. Honestly it seems to me that the new workflow brings a lot of confusion and bugs. We may opt for the possible simplification explained above. But I understand others may have different needs.

Again thank you for your work on this, the new transfer improves a lot the old workflow which is what I personally will use.

[Jasper29]

Wow guys awesome work--just going to chime in here really quick (I’ve been glancing at this bug report’s process here and there) but just want to clarify from what I’m seeing there are now 2 ways to go about importing HD meshes (with and without geografts)?

[Alessandro Padovani]

No, the two ways are with and without the geometry editor. Both support geografts. The new way without the geometry editor is for True HD which didn’t export HD shells before. But for multires it is not needed.

[Jasper29]

Ok, thanks for clarifying

[Thomas Larsson]

I wrote a blog post about this.

https://diffeomorphic.blogspot.com/2024/07/improvements-to-hd-import.html

If there is nothing to add we can close this as resolved.

[Alessandro Padovani]

Point 3 in your blog post is confused. We can always use shells from the base resolution meshes, either by copy or transfer. HD shells are not needed for multires to work, they are only needed for true HD aka HD without multires.

Also you don't mention what are the options to be used, as don't merge materials, keep base meshes, transfer to HD etc. You could add a quick step by step example to show the difference with the old workflow. Or just link this discussion for anyone interested.

Also there's a regression because the old workflow doesn't work anymore, that is, merge geografts in easy import doesn't work as reported above. We can do things by hand of course, it is not a big deal, but this should be explained too.

If you want I can help with a blog post or add notes to the wiki, to better explain the new options. Let me know.

https://bitbucket.org/Diffeomorphic/import_daz/wiki/Advanced/HD Meshes

Other than that I don't have other notes, the actual implementation works fine once we know how to use it. Thank you again for your work on this that's a big improvement both for multires and true HD.

update. bug. shapekeys are not transferred to true HD.

4.2.0.2219, blender 4.2 beta

steps:

1. in daz studio set some favorites for the geograft
2. export as HD without the geometry editor
3. in global settings set “multires“ off and “keep base meshes“ on
4. easy import with "transfer to HD" and “daz favorites”, without “merge geografts“
5. advanced > HD > copy graft groups
6. check the geograft morphs, they don't work because shapekeys are not transferred

‌

[Thomas Larsson]

If you import the attached file as unmorphed, the shells are not created, although they are there in DS. Somehow something happens to the shells in the geometry editor. It is the same in the unstable version and 1.7.3, so it is no regression.

‌

[Alessandro Padovani]

The “regression” is that merge geografts doesn’t work anymore for the old workflow, as reported above. It worked before. As for “unmorphed shells”, I don’t see how this is relevant, since HD always requires the dbz. Unless I misunderstand what you mean.

steps:

1. in daz studio export as HD with the geometry editor
2. turn off “keep base meshes“ in global settings
3. easy import with merge geografts
4. the geografts are not merged

‌

[Thomas Larsson]

Merging geografts works as intended. If Merge Geografts is disabled, both the base and HD collections have the same number of objects. As explained above, the base and HD geografts are separate objects with the same mesh datablock.

‌

If we enable merge geografts, the base geografts are merged to the base character mesh. The HD geografts remain so the can still be used, e.g. for merging with the HD mesh. Perhaps they should be merged automatically as well.

‌

[Thomas Larsson]

Now I was able to import the shells. We need to use the geometry editor for the meshes, but use node selection for the shells. Using unmorphed is relevant because materials and uv layers for the base meshes don’t depend on the dbz file.

[Alessandro Padovani]

Yes that is exactly what I mean. Without “keep base meshes“ we get a HD mesh with no merged geografts, even if “merge geografts“ is on. Before they were merged. If this is the new intended behavior than it’s ok but should be explained that we have to merge by hand.

‌

As for shells, here they are correctly imported with your test scene. Of course the shells are on the geografts until we merge. As for unmorphed, if dbz is not relevant for shells then doesn’t matter how we import. Unless again I misunderstand what you mean.

steps:

1. in daz studio enter the geometry editor and export HD without uvs.
2. in blender import as dbz.

‌

p.s. Yes, when we enter the geometry editor in daz studio the shells are hidden, so they can’t be exported. But again it doesn’t matter for multires, since we get them from the base mesh. Exporting HD shells requires to don’t enter the geometry editor, but HD shells are only needed for true HD.

p.p.s. Anyway as explained above I don’t think any of this matters, it is only to be better explained since there’s no walkthrough for the new workflow, with the options to be used. What matters is the true HD bug reported above “shapekeys are not transferred to true HD”.

[Alessandro Padovani]

update. workaround for true HD.

4.2.0.2219, blender 4.2 beta

As reported above in “bug. shapekeys are not transferred to true HD“, “copy graft groups” doesn’t work for true HD. A possible workaround is to use “morphs > transfer shapekeys“ instead, which works fine to transfer the morphs from the geograft to the HD mesh.

p.s. Again, if this is the intended behaviour, then some walkthrough is needed to explain how to use the various tools and options together. I can do that in the wiki if you need some help. Let me know.

[Thomas Larsson]

If the merge geografts option is enabled, HD geografts are merged too in the last commit. That’s why two geograft objects are needed; one is merged with the base character and one with the HD one. There is still something strange with UV layers in the old framework, but that didn’t work befor either.

[Alessandro Padovani]

4.2.0.2223, blender 4.2 beta

bug. HD shapekeys. Ok, I adjusted your Alex scene to include some daz favorites so we have a common ground now. The geografts shapekeys are not transferred to the HD mesh so the morphs don’t work. Let me know.

steps for the test scene alex.duf:

1. in daz studio export HD without the geometry editor
2. in blender easy import with “daz favorites” and “transfer to HD“
3. copy grafts groups
4. check the shapekeys, they are imported in the geografts but not transferred to the HD mesh, so morphs don’t work

‌

[Alessandro Padovani]

test scene for HD figure with geografts

[Alessandro Padovani]

update. HD errant vertices.

There’s also issues exporting the HD mesh without the geometry editor, because in this case multires generates errant vertices as in #382. This issue can’t be fixed, but this doesn’t happen using the geometry editor with base resolution geografts, which is fine as most geografts are not HD.

steps:

1. set the viewport multires to 2 to reveal the errant vertices

‌

possible simplification. The old workflow with the geometry editor works fine, now improved with transfer which wasn’t available before. We may mark as experimental the new workflow without the geometry editor, or remove it entirely since there’s no way to fix the issue above. Let me know.

[Thomas Larsson]

Now I finally understand how to include shells in the old workflow:

1. Add geografts and shells in normal mode.
2. Save the duf file. It includes the shells.
3. Enter the geometry editor and click on everything.
4. Export HD dbz.
5. Close the file without saving.

It was probably obvious all the time, but it wasn’t to me. Shells are corrupted if you try to save the duf file after having been in the geo editor, even if you go back to normal mode.

‌

[Thomas Larsson]

Geograft morphs are not yet transferred to the HD mesh in the new workflow, but I just managed to do it by hand. The trick is that we must select the HD vertices that correspond to the graft, and only transfer shapekeys to selected vertices. Will fix.

[Alessandro Padovani]

daz studio 4.21.0.5, windows 10

I don’t get corrupted shells here. It may be a daz studio bug depending on gpu drivers or windows 7, if you don’t use windows 10.

See my example alex.duf, the geografts are set to base reolution because they are not HD, the shell visibility is fixed. Only real HD geografts need to be set to a high subdivision level, and you do it in normal mode outside the geometry editor. The shells are not visible in the geometry editor because shells are instances of actual geometry, so the geometry editor doesn’t edit shells.

note. To edit properties separately for the geografts you need to display separate items in the daz outliner. That may be your issue if you can’t.

‌

my steps:

1. Add geografts and shells in normal mode, set non HD geografts to base resolution, set true HD geografts to the desired subdivision same as the figure.
2. Save the duf file. It includes the shells.
3. Enter the geometry editor, don’t change anything, don’t click on anything.
4. Export HD dbz.
5. Exit the geometry editor then save the scene or don’t, it’s the same, there’s no corrupted shells. Have no idea what happens if you save without exiting the geometry editor, which may be your issue, but it makes no sense to do so in the first place.

‌

[Thomas Larsson]

Geograft shapekeys are transferred to the HD mesh now.

[Alessandro Padovani]

Commit 83c3184.

bug. Transfer to HD doesn’t work fine, below the example with my Alex scene. The workflow with the geometry editor works fine. Again, it may be a good idea to mark the workflow without the geometry editor as experimental, or drop it entirely since it has issues that we can’t fix as shown above.

The workflow with the geometry editor works fine, and it is improved with the new transfer which can handle multires when it doesn’t match. So this is what we can use.

‌

[Thomas Larsson]

That is not a problem with HD import per se, but rather a limitation of the transfer shapekeys tool. You will see the same issue if you transfer shapekeys from geografts to the HD mesh manually (selected verts and non-conforming meshes enabled). The transfer algorithm can fail in regions that are crammed with vertices. With the old workflow the base and HD grafts share the same mesh data block, so there is nothing to transfer.

There are not really two different workflows. The plugin always uses the old method if the multires modifier can rebuild subdivisions and the multires mesh has the same topology as the base mesh. If that fails, e.g. because the mesh has triangles or the file has been exported with geografts in normal mode, then the plugin has to fall back on the new method. Or fail to import the HD mesh entirely, which isn’t a good alternative IMO.

[Alessandro Padovani]

Thank you for the explanation. Ok, then the only difference is we have to enter the geometry editor to avoid transfers whenever possible, the importer itself doesn’t care if we do it or not. I believe these notes should be added to your blog post for users to be aware of the limitations, before they start to export without the geometry editor.

p.s. If there’s nothing to add we can close as resolved. I guess this is as good as it gets, it is important to be aware of the limitations.

[Alessandro Padovani]

4.2.0.2244, blender 4.2.0

https://www.daz3d.com/mount-of-the-abyss-hd-for-daz-horse-2

bug. transfer HD. There’s a bug with horse 2, again the shapekeys are not transferred. The alex scene works fine. The queen scene works fine. The difference could be that the horse is TriAx.

steps:

1. in daz studio export the test scene moa-hd.duf as HD
2. import in blender with “daz favorites” and “transfer hd”
3. the favorite morph works only for the bones, the shapekey is missing

‌

[Alessandro Padovani]

test scene for horse 2 hd with favorites

[Alessandro Padovani]

update. If I “keep base meshes“ then try to transfer by hand with “transfer shapekeys“, I get an error. I selected the HD mesh first then the base mesh as active, as usual.

steps:

1. transfer from base mesh to HD with “transfer shapekeys“

‌

[Thomas Larsson]

Both issues are fixed in the last commit.

Easy import treats Genesis figures specially, e.g. standard morphs can only be loaded to them. However, daz favorites can be added to a figure even if it is something else lika a horse. Now shapekeys are transferred from the first figure to later figures, which typically are children of the first. It is possible that you can set up a file that makes the plugin confused about when to transfer shapekeys, but normally it should work.

[Alessandro Padovani]

Commit 4e31176.

bug. transfer HD. The horse works fine if I “keep base meshes”, otherwise if I don’t “keep base meshes” the shapekeys are not transferred. Alex and Queen work fine, this bug is limited to the horse.

steps:

1. turn off “keep base meshes“
2. import with “daz favorites” and “transfer HD“

‌

[Thomas Larsson]

Fixed in last commit.

[Alessandro Padovani]

Commit 62e45d4 works great, tested the horse, Alex and the queen. Thank you for your work on this.