Different vertex count if 'Smooth' is selected in MakeHuman before import to Blender

[Hunanbean]

I could be wrong, but i thought that the smoothing in MakeHuman was just supposed to be a visual effect and not change the actual vertices when the model is imported to Blender. also, this may just affect additional geometry such as teeth. i do not really have the skill set to actually compare vertex for vertex. i am just going from error/information messages when i am working. to clarify, i mean the "Smooth" setting in MakeHuman, and not any Blender subdivison modifiers or such.

Example, i try to copy a shape key from a makehuman model that was imported in to blender without smoothing, to a makehuman model that was imported with smoothing. I get an error message that the vertex count is different. if i try to copy from smoothed to smoothed, or non smoothed to non smoothed there is no issue.

Thank you

[Hunanbean]

Further clarification. This may not apply to the body model it self. It does affect the teeth though. Imported teeth with the smooth setting enabled in MakeHuman have a different number of vertices than a set of teeth imported to blender when the smooth setting in MakeHuman is toggled off.

Not sure if this should be here with the plugin or under the main MakeHuman issue list.

Thanks and be well

[Aranuvir]

The smooth button does not change the shading, but works like a subdivision surface modifier. You can see the effect when you activate wire frame. TBH, I'm not sure if these are discussions for the bug tracker. We have a forum for that purpose: http://www.makehumancommunity.org/forum/index.php

[Hunanbean]

yes, but is it supposed to change the actual number or vertices when imported to blender? That's why i think this is a bug. It is changing the number of imported vertices on the teeth that are imported to blender if the smooth setting is enabled in MakeHuman.

[Hunanbean]

ok, i realize i have not been clear with my description for this report, so i will revise. Makehuman - with smooth disabled when imported into blender the hair, teeth, eyelashes, tongue, and eyes are not subdivided as expected the body is not subdivided, as expected

MakeHuman - with smooth enabled when imported into blender the hair, teeth, eyelashes, tongue, and eyes are subdivided the body is not subdivided

i expected everything to either be subdivided, or everything to not be subdivided based on the smooth setting, not a mix.

If this is expected behavior, please close, and or delete this issue.

Thank you

[Aranuvir]

That's indeed an unexpected behavior.

[black-punkduck]

We should solve this by changing the source, so the sender of the objects.

It does not make sense that MakeHuman exports with subdivision switched on. There are three problems:

• with a subdivided body all other tools (makeclothes, maketarget) will fail. This will again result in 100s of questions from the users. So best is, like Joel did.

• the algorithm was made for quads only. It works in old 1.1 version for triangles in geometry but implementation for UVs and texture is simply not usable. Additionally it had some problems with calculation of poles. So I simply switched it off for objects with triangles in the new version.

• the implementation of UVs is also a problem when small quads are direct neighbors of big ones. Best to see, when you look at the neck of the electric guitar in the assets. The makehuman mode is similar to blenders "sharp" mode.

So it would be better to export only non-smoothed meshes. And use blender subdiv.

The export should be changed then, it happens here:

https://github.com/makehumancommunity/community-plugins-socket/blob/master/8_server_socket/meshops.py

Unfortunately I am not able to do the same for the proxies (clothes etc.), what Joel did when he exported the body:

He used a method called "name mangling" to get the real body (_getbodymesh, line 130/131) because otherwise one cannot access human.__seedMesh - I am too much a newbie, so it took me me an hour to understand that method XD

When I tried the same with the proxies in line 463 with the attribute __proxyMesh (this should contain the non-subdivided version) I had no success, because parameter stayed non-existent .

So the reason for this behavior is 100% clear, but I can't change it with my knowledge. Maybe Joel will do that or maybe you, Aranuvir, if you are more familiar with this mangling or you can figure out where the information of the not subdivided mesh is stored

:)

[Aranuvir]

Sorry for my delayed answer, I'm a bit busy atm...

def _getProxyMesh(self, proxy):
      if proxy.type == "Proxymeshes":
          if not self.human.proxy is None and not self.human.proxy.name is None:
              return self.human._Object__proxyMesh
      return proxy.object.getSeedMesh()

Should do the trick. Though I cannot test the correctness thoroughly because of issue #62 (still investigating that one, it seems a problem with proxymeshes. And it's definitely not a rounding issue, value differences are huge). BTW, I'd strongly recommend to make use of Python's introspection capabilities. After installing ipython and qtconsole you will get a very versatile Python shell for realtime dubbing inside MakeHuman. For example you can do something like h = G.app.selectedHuman, than run dir(h). G is already exposed to the shell. There is no need to import it.

[black-punkduck]

okay, it was 50% of the solution. The meshes were used for calculation of num-vertices, faces etc also. I did a version in a punkduck_devel branch not to destroy the nightly builds. It looks good on my side. Now nothing is subdivided

the change is proposed for makehumancommunity/community-plugins-socket

Btw. without my additional change I got the assert messages. This time I printed the results and got 4 times as much vertices ... so that could have been a reason long time ago for issue #62

[Aranuvir]

Nice work, punkduck. I think it fixed #87 and #62. Suggesting to merge. Any objections?

[black-punkduck]

nope no objections. We only should mention to Joel that it is best NOT to export the high-poly meshes created by subdividing :) Just do the merge than...

[Aranuvir]

Doing a retest I see plenty of face index warnings. Any ideas?

[black-punkduck]

It complains when a body proxy is used. Took me some time, in 8_server_socket/meshops.py try this (approx line 506) I changed this:

# TODO: Figure out how to find hidden faces on clothes
            if p.type == "Proxymeshes":
                face_mask = self._boolsToRunLenghtIdx(mesh.face_mask)

Delete faces is not yet realized in case of a body proxy? Well okay, that's what the TODO indicates and of course nothing was deleted in my case.

Because it was self.human.mesh first I started with self.human._getBodyMesh().face_mask ... but that does NOT work. In this case the proxy-body-mesh is not fully created (when it is longer than the original body mesh).

[joepal1976]

Taking a look at this, I'm not sure I follow what the current status is. But since the punkduck_devel branch (in socket) seems to work with body proxies both with and without smooth when importing via mpfb, I've merged that to master (in socket).