Recruiting for Makehumans Future!

[punkduck]

Meanwhile I made a small new material editor to allow first modifications of materials.

material editor

I want to fully support glTF materials because most game engines can read it, but also blender is reading it.

My own mh2b format uses the same settings as blenders glTF loader, but also creates a "look-alike" AOMap in Blender (it is a fake, but should demonstrate the usage of the texture with an effect at least).

gltF materials

For the corsage. vambraces, shield and also boots, there are areas of leather and others of metal, there is also different roughness. Both is done either by values or channeled textures in glTF.

The unchanged result after loading in blender looks like this, this is the eevee version:

eevee version

And this the cycles one:

cycles version

The own shader in MakeHuman is of course not yet able to handle all that ... this needs to be done later.

I am pretty sure the skeleton stuff for assets + exporting of weights and skeleton via glTF will be something, that will not be ready before vacation. I guess that will be done in autumn.

Greetings,
punkduck

[punkduck]

So I am back after a timeout in programming and slowly continue programming:

Weights now are created for assets also (or use a given weights-file like our standard shoes). Animation and pose now use the weights inside makehuman2 instead of the barycentric approximation method (originated in makeclothes).

I already continued to put them into glTF exporter. So for testing: Do not call the export with a skeleton selected except you want to be suprised ... yes they already somehow do something in Blender:

our new standard mesh :)

Meshes with deleted/hidden vertices will create problems, because the weights are not yet attached to the correct vertices of the "shortened" meshes.
And meshes using a different skeleton need to recalculate weights ... this is also not yet added,

The guy in the image uses a bunch of inverse bind matrices, which are not calculated yet (atm. I use the identity matrix before I start using my brain how to calculates these). And it uses only 4 weights per vertex as a maximum at the moment ... which is NOT the limit as I learnt in between.

About the limit of weights: glTF has the values WEIGHTS_0 and (keys) JOINTS_0 for the first 4 for weights, It would be WEIGHTS_1 and JOINTS_1 for the next 4. This can go up to 9 which means a maximum of 40 weights.
These values are packed into a VEC4 arrays of float32, so that the glTF file can be used as direct input for the graphics card.

I still use 4. 8 should be okay in the end. Maybe I can add a limiter in the menu, if you want 4, 8 or more. I remember Godot complained, but cannot remember if it was 4 or 8.

Anyway I hope I am able to fix the matrices and the deleted vertices problem first.

The leaf-bones in glTF will also not always show the correct direction/length for each bone (same problem when you import an FBX in Blender etc.). Try to export a glTF file with skeleton and do an import in Blender.
But when that is working correctly, the export for a game engine should always work.

The blender exporter will use a different technology for the bones and weights. We know bone-head and bone-tail inside makehuman, so I will re-export it correctly. Same goes for the weights, which are variable then.

Greetings
punkduck

[punkduck]

Hi folks

I really need more brain.

But finally I managed to get a skeleton (still not scaled and no feet on the ground) via glTF export to blender. I remember that I was pretty sure I can do that, but that was more complicated than I expected.

So yes, we have most of the components inside makehuman (also the old one). We need the inverse bind matrices for each bone, which can be derived from the global rest matrix.
We need transitions and rotations in local coordinates, which can be derived from the local rest matrix.

Do not expect, I knew all that. I found that out by comparing Blender output with my own output.

So yes, quaternions are needed for rotation and hey, we have an algorithm for that in old makehuman, let's reuse that algorithm.

A typical unreadable high efficency coding ... and wrong.

There is a non-precise mode, which let point the bones in all directions and there is a precise mode which crashes seven times on singularities with our skeleton. Well the reason for crash is rather obvious ...

Code: Select all

#  core/transformations.py, starting from line 1315 ... 

def quaternion_from_matrix(matrix, isprecise=False):
    ....
    q *= 0.5 / math.sqrt(t * M[3, 3])            # math.sqrt(t * M[3, 3]) might be zero :P and it was 7 times for our skeleton XD


Before again trying to understand why the non-precise mode creates chaos, I tried a more sophisticated solution.

https://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToQuaternion/

The lines in paragraph "Code" I implemented in python and no problems any more.

So next will be that the rest of the parameters of export work correctly, then more than 4 weights per vertex and then I try to "carefully" try a first replacement with another skeleton.
Later I need to add animations to glTF and maybe, also shape-keys.

Greetings
punkduck

[Ricardo2020]

Are those hands poking out where the eyes would normally be?

[punkduck]

Are those hands poking out where the eyes would normally be?

No these are the 3 eye-bones, they are just longer than in the blender version created with mhx2. As I wrote before, a bone needs no length and so there is no length saved in glTF.

As a proof, you can export a character imported by mhx2 with gltf in Blender and reload it. Of course you need to get rid of the stupid icospheres when character is standard size (decimeter), therefore deselect shapes in panel.
Exported in standard size (0.1 for glTF, this works since one hour ) ... the icospheres replace bones as shapes. I think the idea of using this in Blender is worse than the normal bones they had normally.

For the length of these bones they use the parent bone ... at least it looks like that. Our eyes are connected with two (not needed) dummy-bones to head bone. So the leaf bones will mostly be wrong. But you can also see differences with the neck bones.
It is just one representation of a bone. In FBX it is the same. They often add so-called leaf-bones which exactly had one purpose to show the length.

For the blender exporter I will add the length, makehuman internally knows headPosition and tailPosition of the bone, because that comes with the skeleton-definition. That is, btw. the only reason for the 3 cubes in front of the eyes, when you check our helper.

Needless to say that scaling and using an offset was creating a resized skeleton for glTF export because the complete rest matrices etc. had to be recalculated. And I thought adding a value would be enough for an offset, so the "I do that in half an hour" just changed to "it took the whole Sunday"

[Ricardo2020]

This is way outside not only my current skill set, but also, my understanding of things outside the MakeHuman and Blender workflows I use which do not include converting things for use in game engines since I do not game. However, I am following your efforts closely because I intend to jump into Pyside6 when I upgrade the OS on my main 'station. I am currently running Linux Mint Virgina but that will get upgraded to Linux Mint Wilma. I plan to keep the current setup on its SSD and get another SSD for the newer OS so that I can dual boot and keep both systems going. This might take some time since the WD Black 2TB SSD I want is expensive. Until then, I will watch and wait... Thanks for all your hard work my Good Sir.

[punkduck]

game skeleton export with gltf, odd bone-rolls included (partly)

So next step done. It looks like extra skeletons like CMU or Game skeleton seem to work in Blender export and glTF export also. We are not working with own weight-files in these cases. We are using reference entries for that, so like

Code: Select all

Forearm.L = [ lowerarm_01.L, lowerarm_02.L ]

So we have to sum up weights. Fore things like eyes we have to figure out the next existent bone in hierarchy, because our eyes consist of 6 vertex groups but none is referenced directly (the next back in hierarchy is head),
Then we have to append all these values per new bone, do a numpy.argsort and a numpy.unique ... And then we have the correct weights.

I do that a little different like before. I do that only when needed (so for export), since internally there is always one skeleton to pose character (except when we have own weights). It is always done with our default-skeleton, you can normally even pose without a skeleton in MakeHuman because it is always used internally.

At least it looks like I now had most topics at least done partly for a version similar to old one, although there are a few (unused?) features like calculation of rotation planes etc. But the blender exporter always exported head and tail position ... bone.roll .. well in my opinion there is/was some kind of issue with that anyway, when I tried the bento one.

I want to continue with a few openGL topics, then there will be no catmull-clark for a more smooth display in "render screen" (which is more or less a dummy still), since catmull-clark is not a subdivision algorithm for triangles. But there is so-called loop-subdivision which is for triangles. This needs to be implemented.

I will add a walk loop and I will hope I can do that different with curves. Just an idea from tutorials, where a walk-cycle was not done by bvh files or by Adobe but manually by an artist. These cycles result in curves in blender, mostly bezier and linear (when e.g. foot touches floor). When one tweaks these curves (or mathematically correct use parameters ) , the character not only changes speed, one can also change hip movement etc. Just an idea ...

Anyway, there will be one part in the menu later where poses can be made. Although I have not yet really an idea how to interact with the character in the graphic display directly. But that's another topic, first I need to figure out the algorithms ... ah yes, I also need to figure out how to export an animation in glTF, for blender I am quite sure how to do that ...

Greetings
Punkduck

[punkduck]

subdivision (smoothing) for triangles

So inside renderer, subdivision meanwhile partly works. it looks rather correct, but there are still glitches, some UVs are wrong (usually where the seams are), the jittering boundaries (hair) seem are not correct (because the first method I found had an error).

When you look carefully you can see where quads had been before. Some of the lines in inner mesh are not really straight, but others are, that could be another error somewhere or it is a problem of the algorithm itself.

it is mostly pure python, no numpy. I changed part or the calculation of normals to numpy and there will be changed more to be faster. Since numpy usually hides the algorithm I will add MD files later which should contain the "original code".

Subdivision will only be used in the renderer. It is simply too slow (and one cannot compare that to the old quad mesh). And of course this renderer will have a small amount of features, but it is not comparable with what a game engine or Blender can do. At the moment all graphics I used is still "just to see something".

The algorithm for triangles can be found here:
http://www.bespokegeometry.com/2015/01/29/mesh-subdivision-loop-and-catmull-clark/

Took me a week, but mostly to find a good way to calculate neighbours or even worse (and not yet correct) to find what will happen to UV boundaries for additional new vertices.

Greetings
Punlduck

[Ricardo2020]

Question:

Are we going to be using triangles instead of quads going forward in the new version of MakeHuman?

Another question:

Will the MPFB system also evolve to triangles?

[joepal]

Both MPFB and MakeHuman already supports tris. The base mesh is quad, and that is not likely to change.

The only limitation is that you can't mix tris and quads in an asset, but apart from that there should be no particular limitations when using either.