Inconsistent clothing helper deformations between base phenotypes.

[angavrilov]

This is actually a common MH issue rather than something MPFB specific.

It can be observed that MH asset packs provide different assets for male and female. This may seem perfectly logical at first sight. However, there is a deeper reason than just fashion why it is simply impossible to make a good unisex asset.

This is because unless the clothing helper deformations are specifically made consistent between the phenotypes, it causes in-plane distortions, i.e. unjustified bunching up and stretching of the mesh in various places. As a result, even if the mesh is low poly enough that the shape would happen to be acceptable, the UV mapping won't be.

Unfortunately, doing something about this would require reviewing fixing all targets, and breaks backward compatibility with some or all assets.

I mainly want to discuss how much of a problem this is, and what can be done about it.

[angavrilov]

@joepal1976 I've been wanting to look into polishing up the targets a bit for a while, so I want to ask what degree of backward incompatible changes to the core targets used to create assets (iirc the young caucasian male & female?) could be acceptable, along the axis of:

• None.
• Small changes in fringe areas - e.g. the clothing helpers don't fit well at the neck and wrist boundaries, exhibiting things like inconsistent distance from the base mesh, sometimes even intersecting it.
• Any changes acceptable.

For the male-female switch case, a compromise solution could be to make some kind of clothing fix targets to allow an asset author to transfer the asset to the opposite sex target for rebinding easier. However there are some local weird areas even in the base targets themselves, like the neck.

[joepal1976]

In general, I'm in favor of fixing these things now before there has been a stable release of mpfb2. This even if it causes some glitches in existing assets. It is not necessary that all clothes look exactly the same when loaded after the targets have been updated.

It'd be unfortunate if large parts of the asset database became completely unusable though.

If the required changes are large, then maybe an optional backwards-compat functionality could be added to the clothes loading functionality, to adjust clothes vertices to compensate for the changes in core targets.

Concerning secondary targets that might be affected by changes in macro details, I guess it should be possible to recalculate some of them automatically.

As a side note, my plan is to drop support for blender 3.6 before the release of mpfb2 beta 1. At some point, I'll merge the blender4 branch to master. Until that happens it is probably best to do PRs against the blender4 branch rather than against master.

[joepal1976]

@angavrilov : As a head's up, there has been a commit for fixing other strangenesses in targets in MakeHuman: https://github.com/makehumancommunity/makehuman/commit/570790caf70ac52c35b49e985159e67b12f60f8a

This should ideally be merged to MPFB too at some point.

[angavrilov]

@joepal1976 While thinking about this, I had an idea of an option to support real-time asset fitting via geometry nodes. I think it is doable by storing the fitting data in attributes and using a geometry node setup to apply the fitting calculations; however it would be necessary to move the mask modifiers that hide helpers from the actual base mesh to a 'display mesh' object and exclude the actual base mesh from display. I wonder what do you think about having such an option?

[joepal1976]

@angavrilov:

I have way too little experience with geometry nodes to give a believable comment regarding the viability of the solution.

But regarding the mask and display mesh... The worry I would have is that the solution grows more complicated and hard to understand for end users. This particularly for those whose end game is exporting a project from Blender to, for example, a game engine. The helper geometry and the existing mask modifiers are already leading to confusion in this regard.

This said, if it is probable that these things could be solved with good UX, I wouldn't mind seeing a proof-of-concept kind of experiment. That would make it easier to evaluate if it is a good idea.