<<Full Monty BBQ>> Scrotum bone causes some problems

[Rob Inters]

Hello, Thomas and Alessandro. When I try to pose the Scrotum of <<Full Monty BBQ>> with the <<scrotum bone>>, the right testicle becomes deformed (see screenshot).

‌

[Rob Inters]

For now, I found a workaround for posing the Scrotum by using the <<Scrotum Back>> Morph, which I applied to the <<Futalicious Genitalia>> and then transferred the Shapekeys from the <<Futalicious Genitalia>> to the <<Full Monty BBQ>>.

So, posing with morphs works fine, but posing with the <<scrotum bone>> causes the right testicle to deform for some reason.

[Thomas Larsson]

The vertex groups for this asset seems off. Probably nobody noticed because people use morphs to pose in DS.

‌

[Rob Inters]

Hello, Thomas, thank you for looking into my problem, I now tried to <<Weight Paint>> the <<scrotum bone>> and I think, I got it quite symmetrical (see screenshot).

‌

‌

The deformation on the <<right testicle>> got smaller and therefore better, but I still get a little deformation (see screenshot)

‌

‌

This is the first time I do <<Weight Painting>> in Blender, so maybe I did something wrong, and therefore the deformation is still visible, how could I further improve the result, Thomas?

[Thomas Larsson]

I think there are other bones with wrong vertex groups that mess things up. Perhaps remove all vertex groups and do auto weighting. But I’m not an artist (that’s why I needed a way to import daz assets into blender), so others can make better answers.

[Alessandro Padovani]

note for @Thomas. In daz studio the testicle bones work fine though, so there’s probably something we miss with nested geografts. As a workaround I believe it is good to fix by hand since this is a rather unique case.

[Rob Inters]

Thank you once more, Thomas and Alessandro; yes, Thomas, you were correct, there were other bones that affected the scrotum; I discovered the <<shaft1>> bone that caused the deformation (see screenshot).

‌

‌

So, to fix this, I simply Weight Painted the right Testicle Blue, and now everything works as it should, with no deformations (see screenshot).

‌

‌

[Alessandro Padovani]

Ok I believe I got it.

If we look at the weight map brush in daz studio we see that full monty is triax weighted. This explains why the weight map is not imported correctly in blender, indeed triax is not supported. It is also “strange“ that triax is used since triax is for G1 G2 while G3 G8 use general weight, this is probably a flaw in the PA design. If we convert triax to general weight before exporting then everything works fine.

@Thomas If there’s nothing to add we may mark as resolved or invalid since this is a “design flaw” in the asset itself. Not a bug since triax is not supported. Unless we find a way to support triax or to convert triax to general when importing. Test scene included monty.duf. Let us know what you think.

steps:

1. convert triax to general weight: edit > figure > rigging > convert triax to general weight
2. export to blender

‌

[Alessandro Padovani]

test scene for the full monty triax weight

[Rob Inters]

Thank you Alessandro, I just tried it, converted the <<Full Monty BBQ>> from <<triax to general weight>>, and the scrotum posing works right away in Blender, and this method is also much faster than my manual approach from above.

[Alessandro Padovani]

Please @Thomas let us know if you can check for triax and throw a warning, so at least the user is aware.

[Thomas Larsson]

Triax weights are not the issue here, even if one could issue a warning about that. And the plugin does make an attempt to convert triax weights to node weights.

The problem is that futa and roasty have many verts in common. That is unusual, because normally they only share vertices along the boundary. Apparently the base mesh decides the vertex weights in DS, so trashy geograft weights don’t matter. But the plugin removes the masked base verts so the geograft weights win in Blender. The fix would be to copy base weights from the masked area before merging geografts.

‌

[Thomas Larsson]

Unfortunately, that won’t work. To copy vertex groups we must know which base and geograft verts belong together, and that info is only available for the selected verts below.

‌

[Alessandro Padovani]

@Thomas, I may be wrong but if you use my test scene you may see the issue better. Even if you load monty alone the issue is there, so it’s not, or not only, the interaction with other geografts. Also, we see that monty is triax and if we convert to general weight it works fine.

So, it may be a more complex issue as you say. But from a practical point of view converting to general weight works fine. If you can convert triax to general weight inside diffeomorphic that’s great. If the conversion has limitations compared to daz, a warning may also help the user.

[Alessandro Padovani]

@Thomas please let us know if you can add the triax warning so we can close as resolved.

[Thomas Larsson]

Hm. This asset has both general weights (node_weights) and triax weights (local_weights). The local weights are fine but the node weights are not. If I convert from triax I get a warning that general weights already exist. If I nevertheless proceed, DS recalculates the weights from the triax weights.

‌

The plugin can handle local weights, at least approximately, but it prefers node weights. So a solution for this asset would be to try local weights first and node weights second instead of the other way around. That would work for most modern assets which don’t have local weights, but I don’t think it is a good idea; node weights are native to Blender, and we cannot assume that triax weights are fine in general.

[Thomas Larsson]

Now the plugin issues a warning if something else than node weights is found; more precisely, it checks for local_weights and scale_weights. The problem is that the old weights are still there after we have converted to general weights in DS, so this warning may be confusing. But I don’t see how to overcome that. The Monty asset has both general and triax weights, both before and after conversion. The only difference is that the general weights are fine afterwards.

[Alessandro Padovani]

Commit e949355 works fine enough. But there are a couple minor issues please let me know if they can be addressed, or we may also be happy with the current fix.

1. NAMES. The plugin reports the daz id while the scene uses the daz label, this way on a complex scene the user may be confused as to what item has to be fixed for triax. It would be useful to report the daz label used in the scene to identify the item.

note. May be this kind of issue also affects other reported errors.

‌

2. TRIAX DETECTION. It is possible to convert triax to general in daz studio, but it is the user responsibility to delete the triax after that. Of course if triax is not deleted then the plugin will report triax maps. It is possible to convert and delete triax with the weight map brush.

‌

The issue is for some reason the plugin reports triax even if I delete it in daz studio. Test scene included monty-fix.duf. If we look at the duf we see that only the general weight is defined, and triax data is no more available. Yet the plugin reports triax weights. May be this is due to some confusion the plugin does with the url as opposed to the instanced asset, if so may be this is not possible to fix.

note. I also tried to save the fixed version as support asset but the plugin still reports triax weights.

‌

‌

[Alessandro Padovani]

monty converted to general weight with triax deleted

[Thomas Larsson]

Fixed in last commit. There are no local_weights in the file, but it still contains scale_weights which is why the plugin complained. The warning lists the object name with the .001 suffix, but that makes sense to me since that is what the mesh is called in Blender.

[Alessandro Padovani]

Commit 2b8882f works great thank you for the nice fix.