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.