HD morphs break the mesh
Issue #382
new
Hi, I sent the character in HD (I used the morph "Mouth Realism HD" and a couple more hd morphs for the mouth) and when opening the mouth (LowerJaw bone) I see a broken mesh. http://joxi.ru/RmzYBljFMk4Qxr.png
In daz, this looks correct: http://joxi.ru/GrqYlN8FGW9KOr.png
Multires does not display the hd mesh correctly.
I tried sending G8F and G8.1F, without any HD morphs at all, just one dev genesis 8.
And here's what Multires shows: http://joxi.ru/8Anzay1iyepkOA.png
It turns out that the mesh initially comes to blender broken. After that, other morphs are superimposed on it and we get what you see in the first picture.
Some vertexes just break. How do I fix this? Maybe I'm doing something wrong?
To play back:
- In daz, load G8F (subd 2), in the zero position.
- Export HD to Blender
- In the blender, open mouth (bone LowerJaw) by 20 degrees.
Comments (39)
-
repo owner
-
So this problem is caused by morph or weight-map with multiresolution un-subdivide process?
basically if we set sub-D in blender with multiresolution sub-D applied, (set sub-D as 2 or 3) I do not expect, it can show shape key correctly. (it may only work with base resolution with multiresolution modifier I suppose though I had not test seriously about HD)
to check how shape key or weight map change with multiresolution modifier sub-D, we need to check with non pose figure first. if it already show some corrupted verts, (with sub-D 0 and sub-D 3 etc) the multiresolution modifer un-subdivde process seems need to consider. I feel.
(I suspect, “unsubdivide” can not un-subdivide clean complex mesh from high sub-divided mesh , though we can not check it usually,, I suppose if it seems only happen, about pole verts or too close points)
-
repo owner
I wonder if there may be some rounding errors when the vertex groups are loaded. Here are some illustrations. First base mesh, without and with subsurf enabled.
HD mesh, without and with multires enabled.
-
repo owner
Multires at level 1 seems to be doing ok.
-
So it means Weight problem (vertex group) with multiresolution modifier?
-
Can you test same thing without any shape key and weight map effect? (so we can exclude case)
-
repo owner
Hm. I think it may have something to do with the multires modifier after all. Look at the vertex behind the last tooth at level 0, 1, and 2.
-
But I do not know why it happen,, that means when add on generate base by un-subdivide, it change mesh for high-resoluiton (sub-D level3) like your pic?
Or when we import high resolution mesh, by Add on HD option, it already have issue untill un subdivide, for current high resolution mesh?
(Though I do not think so,, add on may keep mesh correctly untill we un-subdivide,, )
-
repo owner
The plot thickens. If you apply the multires modifier, the stray vertices jump back into position. I have updated the bug report to Blender: https://developer.blender.org/T81645.
-
repo owner
Applying the multires modifier also removes the problem at the corner of the mouth. I think we can safely conclude that this is a problem with Blender and not with this plugin.
-
Would not you correct it with the sub-D level which used in daz studio. (sub D level 3 etc), by multiresolution reshape option? (though I do not think, the reshape option still work for posing mesh with armature modifier, so you may need to use reshape for zero posed figure. (then if it only happen with posed mesh, (deformed by armature modifier + multiresolution, I do not have way to solve it I feel.
-
A partial solution is if we export the mouth slightly opened, by rotating the lower jaw 5 degrees for example. In this case multires works fine. Below an example with the full open mouth by rotating the lower jaw bone in blender.
steps
- load a g8f in daz studio and subdivide 2x
- rotate the lower jaw 5 degrees
- export HD to blender
My wild guess is that multires may have troubles to unsubdivide special case areas, as twisted polygons that may happen at the edge of the mouth. No idea why the issue disappears once we apply multires though. I agree this seems a bug with multires itself.
-
Thomas
Though I do not say it should work for all case, but I actually download the file from blender dev forum with your link. then I test my -workflow, use reshape (which we applied multiresolution modifier but keep Armature) then overwrite sub-D 3 mesh (with multiresolution),
even though I use the applied mesh for reshape target, it now solve the issue too.
see this pic.
What I tried, first duplicate the mesh only (with keep armature modifer) as genesis3femaleHD.001.then apply the multiresolution modifer with sub-D2 for the duplicated mesh. it actually set the verts postion correctly. (I actually see slightly different postion for all verts, but I can ignore it I suppose)
after that, I select the HD.001 (clean), then select the problem HD. (with keep multiresolution sub-D as 2), then click Shape(not advanced, but Shape category of mutiresolution modifier)>reshape.. now it overwrite the problem parts by clean mesh, and it seems no issue with posing.. and it do not show problem even though I return as base.. (it is supposed so, because, reshape not effect base mesh, I think)
I think if I miss something important, but at least it can solve this issue I feel. (do not test with other morph etc though, And I feel the Reshape option is too powerful, because we can use it to change shape with keep armature modifier without problem (we can not do samething for posed shape as shape key I suppose)
As I said, it need more test actually you use it for add on though..
you may test with my blend file. or test same thing please. (I do not know other user can open the blend file as same as me)
-
- attached cleanmulti.7z
cleanversion with reshape -
Yes it actually return shape for the pose clean. but unfortunately now it seems deform for non posed shape (I can imagine it though) bad around jaw and lips area..
About multiresolution applied version (high dense mesh with armature modifier), not show this issue.I can suspect, I can reshape again for zero pose shape, but maybe (or mostly), it cause posed shape as bad deform again..^^; (I do not test it though)
===
And now I could confirm after reshape for zero pose, now posed (jaw rotate 30) return ugry shape again ^^; so it definetly vertex weight issue with multiresolution sub-D applied mesh. and we can not edit sub-Divide verts weight. = we have actually no way to correct it (without there is tool which can weight for sub-divided mesh of multiresolution, I suppose)
-
And I found if you change modifier order, mutiresolution with armature modifier, it solve issue.(though I do not think it is correct order to use armature, but about this case it solve issue
I sometimes feel I should use my toughness for more good thing ^^; I suppose the cheat way should work without you use reshape, and it do not show me problem with zero pose. (though I do not know after all it cause new issue or not to import shape key etc,, but if it work for render, we may only change order when we render image. -
I wonder if skinbinding after multires resolves the issue with HD geografts too. That’s
#223.https://bitbucket.org/Diffeomorphic/import_daz/commits/f3a71746178583b5641ef5090b72217763f8b14a
edit. I quikcly bypassed the removeMultires() function to get a test, and it seems the issue with HD geografts stills there. Bringing multires at top doesn’t seem to work in this case. But also I’m not able to import the HD geograft alone since I get an error. So once this is fixed I’ll try again. See
#383.
-
Actually I suppose if the order effect for many issue, but at frist, I hope OP may test it with real HD morph, and if it can solve issue or not.
-
When you apply the multires before the armature you are effectively moving the multires to the top of the modifier stack, that’s why the problem disappears in that case. Apply the armature first and you will see how the problem remains after applying the multires.
Moving the multires to the top of the modifier stack is not how daz applies subdivision, so the deformations will be different in general.
-
repo owner
Xin, thanks for pointing this out. If you apply armature then multires, the offending vertices are 204528 and 208935. The location of the first vertex and its nearest neighbors (those selected in picture below) are
41418 (0.02633 -0.02200 1.61317) 204527 (0.02452 -0.02216 1.61140) 204528 (0.01776 -0.02561 1.62735) *** 204529 (0.02578 -0.02123 1.61255) 204531 (0.02334 -0.02185 1.61031)Since G8F has 16556 vertices, the problem is a level 2 vertex, which has one level 1 and three level 2 neighbors.
-
Yes I see it not show same sub-D shape with posing when I change order. (all verts change position slightly) when I change modifier stack order.
But without change modifier order as I did, I suppose imported HD with multiresolution should cause this issue for sub-D verts with posing. (though I do not know it may only happen when we use un-subdivide to generate base, after all we can not avoid to use un-subdivide, with current add on HD mesh import.
Though it may change shape slightly with posing when compare with daz. but I feel it far better, than keep the broken verts without solution. it may need to compare with actual render with use same pose , and if it is too clear difference to ignore it,, we may simply need to wait , blender solve issue.
(but I do not expect it much. because there are not many case, blender user may un-subdivide mesh with armature moridifer, I suppose)
-
I can confirm that topping or applying multires doesn’t always work anyway. As example, I exported futalicious alone at subd 2 as HD figure. When I import it in blender I get the
#223issue with errant vertices. The news is, we don’t need to merge geografts, the errant vertices are there from the start. And applying multires doesn’t work.So this means
#223is not an issue specifically with HD geografts, it is an issue with any HD figure. That is, there may always be something in the geometry that triggers the errant vertices when converting to multires. This also means that the fix in commit f3a7174 is wrong, because some HD geografts may work fine.Test scene included futa-hd.duf
steps
- load the test scene futa-hd.duf, it’s futalicious alone at subd 2
- export as HD to blender
-
- attached futa-hd.duf
subdivided futalicious alone, exporting as HD generates errant vertices
-
Thomas, may be this has something to do with the HD precision in the dbz file. That is, in the futa-hd example above, if I use the degenerate dissolve tool on the HD geometry, it finds a number of degenerates, that are zero faces and edges. That sounds like a low precision issue to me.
steps
- load the test scene futa-hd.duf
- export as HD to blender
- import without “add multires” in global setting
- in edit mode use the degenerate dissolve tool, to see how many zero faces are there
-
repo owner
Vertex locations are written in the function doVertices in export_highdef_to_blender.dsa. There is no formatting, which I assume means maximum precision. And if you look in the dzb file, the hd vertices are written with around 16 digits, the first one being
[0, 91.94468688964844, -5.498121738433838],
So it is hard to believe that sufficient precision is lacking.
If I run the degenerate dissolve tool with merge distance = 0.000003 m = 3 um, no vertices are merged. With distance = 4 um one vertex is removed. Since 3 um = 0.0003 cm, the locations are specified with almost ten significant digits.
But it may very well be that the rebuild subdiv tool has a threshold.
-
As Thomas once said, I feel the #223 issue, flying vertex and this issue not same problem. (though I feel it related with re-build (un-subdivide) ,and set sub-D again. Then we can confrim, with zero pose, or with set base resolution, the problem has gone. (you can check it with change jaw angle in blender to 0 the verts try to locate the position with angle.
So it means, after re-build, then set sub-D as imported number, (this case sub-divide 2) the divided vert not have vertex weight correctly for deform bone.
At same time, we already know, if we generate base with multiresolution re-build, blender multiresolution change way how-subdivide mesh.
I test to confrim it, Keep imported mesh, then duplicate it.
After set zero pose, and change sub-D level as 0, and. remove all other sub-D cage once.
Then sub-divide by multires modifier 2 times. (generate sub-D1 and subD2)
I tested the new mesh (with multiresolution sub-D2) and posing, zero pose, not cause this issue. actually the mesh seems more smooth and clean than before I feel.
Of course, if we do so, it means, we change sub-D mesh. Then the mesh is not same as which we imported any-more with sub-D2 (because sub-D process change with multiresolution)
So we can confirm this issue is not caused by re-build mesh which generated by multiresolution modifier. (because, if we re-apply multiresolution modifier sub-D, it work correctly)
But the way how multiresolution modifier subdivide when we generate base by rebuild (un-subdivide).
-
It has been confirmed as a bug in the bug report Thomas made, so it’s very likely an issue with Blender.
-
Thomas can you add test option, which export HD mesh without multiresolution but keep bone weight map?
Why I hope to check it, if I do not use rebuild multiresolution, , then pose sub-D 2 applied mesh work correctly or not. At current, if I use HD option uncheck multires, it simply return non weight map mesh. (but parented to rig) so I can not apply same pose. (jaw rotate)
then if it work. I suppose I can use the import mesh as reshape target for the mesh, which not use re-build but apply multiresolution from base. (with the way, which I described above. Once mesh rebuild and sub-D this problem happen. so if not use re-build. It may not happen. (and I suppose I can still use reshape to get sub-D 2 geometry which we import by add on)
===============
I test reshape by use import sub-D mesh (without multires). but as we know it not keep vertex order already. so I can not reshape after all. (yes I remeber the multresolution modifier problem ,which change vertex order of sub-Ddivided mesh,,)
-
repo owner
The HD mesh is exported as it is. Multires is only created when the HD mesh is imported. And no, bone weights for the HD mesh will not be exported, because that would make the dbz file absolutely huge - many vertices times many vertex groups may increase the export time and size by a factor 100 or so.
The multires mesh gets vertex groups from the base mesh, since it has the same vertices at level 0.
-
repo owner
Alessandro, both DS and Blender appear to store vertex coordinates as 64-bit floats (16 digits = 50 bits for the mantissa). Some precision was indeed lost in the manipulations before the mesh was created (converting three floats to a mathutils Vector and multiplying by 0.01 for meters), which is fixed in the last commit.
However, this does not fix the problem. Even if we import the mesh with Z Up = False and Unit Scale = 1, the vertex flies off. And with 1 B.U. = 1 cm, there are no problems with degenerate dissolve.
-
Yes the HD mesh import (without multires) can keep vertex order. but without weight. = HD mesh
The HD mesh shape is what we need.
then import HD mesh with multires, rebuild and generated “base vertex order is same as daz base vertex order” but when set sub-d and use reshape for the sub-D mesh, it corrupt vertex order. (it means, the vertex order with sub-D not same as HD mesh) at same time the sub-D mesh show weight map problem , then when pose it break only about some verts.
(I can not confirm actually which verts may cause issue, eg the lip area small corruption , the base mesh is clean.. the large corruption area of back teeth, I easy find 6 pole verts, then it can easy cause issue I suppose with sub-D and weight)
Then if I apply multiresolution for base mesh, and sub-divide, the high resolution mesh not show weight problem . but the vertex order is not same as HD mesh. then we can not use reshape to return HD mesh shape.
-
Thomas it is my fault since I was running “degenerate dissolve” with the default threshold of 0.1 mm. I didn’t even notice there was a threshold, since the popup says “zero faces” I just trusted it. I’m sorry that I wasted your time.
But, my test with futa-hd.duf shows that the errant vertices are not due to merging HD geografts, they’re there from the start in the geograft. That may very well be any mesh since the geograft alone is a figure itself as any other figure. So the fix to
#223in commit f3a7174 is essentially wrong because it could be any mesh to cause the issue or not, depending on the geometry, not just geografts.Personally I’d remove the removeMultires() function, or at least make it an option. So we could import HD geografts and eventually fix them by hand. Below an example where I sculpted the errant vertices closer. Please forgive my bad attempt, I never used the sculpt mode before in blender, it is just to show that it is possible to fix it by hand in sculpt mode.
-
repo owner
OK, the call to removeMultires has been removed. It does not seem to make a difference anyway.
-
Hello guys sorry i’m completely new to the forum .. i just signed up ..to ask a question ..i’m kinda confused by the new material set up in the new version (1 .6 ) where the subsurface scattering settings go ? is there a way to change that in the new version ? Otherwise thank you very much for this great addon :)
-
oh man , sorry guys ..i posted my question in the wrong section
-
To get sss you have to choose the principled option in the global settings. Otherwise true volumetics is used with the bsdf option, the same as iray does.
-
ah ok , i didn’t know that, i need to explore more this new version ..thank you very much Alessandro :)
-
Issue
#948was marked as a duplicate of this issue. -
- marked as task
Marked as task since this is a limitation in the blender multires modifier, to be aware of, but not a bug in the addon.
- Log in to comment
Yes, I can confirm this behaviour. Unfortunately, we cannot easily compare with the HD mesh without multires, since the vertex groups are not readily available (they could in principle be exported from DS, but HD export is already slow, and slowing it down by a factor of 100 in order to export 250 HD vertex groups is not going to happen).
It could be due to bugs in Blender’s multiresolution modifier, which is known to have issues, cf. https://bitbucket.org/Diffeomorphic/import_daz/issues/218/genitalia-geograft-vertices-translate.
Edit: The problem with the multires modifier is that it seems to move some vertices to the origin, or perhaps halfway there, which does not seem to be the case here.