Facial expressions

[brkurt]

but thats just for windows right? im on a mac, thats why i prefer a old version with the facial expressions..

Mhx2 is pure python and does not use any special libraries except numpy, which is already deeply integrated into MH. So if MH and Blender works for you, there should not be any problems. But I cannot guarantee it, since I have only tested on windows.

also why do you guys took out such a great feature from this software? i know you are working on a better tool but during the time why dont let people use that option?

Don't blame me. If it had been possible to keep facial expressions inside MH, MHX2 would probably not have been released as an external plugin.

I was not making that question direct to you, i just found strange such a great and easy tool to just be cut out of the project, in the end i just want to animate my characters face (maybe put a smile?)


also the last nightly version for MAC was more than a month ago, can you guys update that?

If you will allow me, I think I can explain the design logic for this change, as I am heavily involved in analysis of facial expressions and their 3d animations.
The issue is interoperability; shape keys (morph targets) are notoriously proprietary. Each major 3d (DAZ, Poser) app has its own way of using them.
What is required for a open-source program is to advance along two fronts (always a problem in strategy): (1) to create facial expressions that are biophysically (genetically?) universal; (2) to ensure those facial expressions have some sort of standardization with respect to morphing.

For example, you want to create a simple smile. How will a designer/programmer know that their smile code is universally regarded as a smile? To do that, it must be a Duchenne (after the 19th century physician who first measured facial expressions) smile that engages the tiny muscles around the eyes called the obicularis oculi. Their contraction is commonly known as 'a twinkle in the eye'.
If these muscles are not taken into account, what you will get is a 'false smile' or grimace or rictus, which of course sends the exact opposite message to the viewer.

Right now, the 1.1 mesh and rig can create the basic (agreed-upon) facial expressions without shape keys simply by using poses; this is a superior solution because it means that the expressions can be uniquely tuned to a particular character using shape keys. The upshot of this is that I can export the 1.1 rig and mesh via Collada to a completely unrelated app such as Marvelous Designer, and my character can smile and lip-sync, even while I am focussed on garment creation. I don't use FBX, but I'm under the impression that the FBX export will integrate the rig poses with shape keys, and that puts Makehuman in a very good position.

[Solkar]

@brkurt

Your reasoning is solid concerning the - hypothetical - question "why are shape keys not part of the mh core model?".

But it does not explain why the exporter plugin that uses them - locally and restricted to its own target system "blender" only - is not part of mh anymore.

Every export plugin inherently has to take care of the requirements of the target format or app - even COLLADA .dae is just one format among others (although, given, it well may currently be primus inter pares).

[Mikel_J_Gee]

@brkurt
Every export plugin inherently has to take care of the requirements of the target format or app - even COLLADA .dae is just one format among others (although, given, it well may currently be primus inter pares).

Sorry, to "get into" this discussion, but - Solkar - this marked comment of You is "slightly" incorrect!

An export plugin has to take care to deliver the available sorce data considering the import format(s) of the target.

and that available simply means "what is there", gives an acceptable mimum target "is the same as on sorce" and not, what the target can use at a maximum.

If You export (only to give You another example) a BMP grafic-file to a TIFF file, You will never get (on TIFF-part) an alpha-channel, a CMYK-Colour sheme or something else of what TIFF is generally able to present.

If You have a picture in 8-Bit, no exporter on earth could export something into 24-bit colour depth. (just one other)

[Solkar]

An export plugin has to take care to deliver the available sorce data considering the import format(s) of the target. and that available simply means "what is there", gives an acceptable mimum target "is the same as on sorce" and not, what the target can use at a maximum.

That is besides the point. Blender shape keys are just the blender flavor of representing certain morph data, e.g such data as it is very well present in the current unstable model in .target files for expressions.
What and that additional data was bundled with that plugin is a different story that is about content and not about the interface technique itself.

[ThomasL]

If You have a picture in 8-Bit, no exporter on earth could export something into 24-bit colour depth. (just one other)

It could, provided that it is an export format for (variations of) a single picture only. Mhx2 is not an export format for a general mesh, but specifically for the MH mesh. E.g., the hair system uses the fact that vertex no 879 is located at the top of the skull. It would not be possible to add particle hair to an MH mesh exported with obj or collada, because then the vertex numbers cannot be trusted.

[duststorm]

In my experience, shapekeys for things like facial poses are not very portable across different faces.
We had an experiment of this in MH, it required a lot of data and the algorithm that fit them to other meshes, while it worked to some extent, had the side effect that it mostly "blurred" shapekeys together. This made the expressions a little unexpressive and averaged out. It got worse if you created faces that move away from the default macrotarget faces, and with some faces they just ruined the face.

We decided this approach was more trouble than it was worth, as it was not the tool to help us get quite the quality level we are aiming for.

We discovered that expression poses using a facial rig worked a lot better, they offered more definition and work for all faces, even the baby. So that's what will be used in the future releases.
They offer not only the advantage that the amount of data is seriously reduced, but exporting skeletons and poses is something that is present in many export formats, so we can get by with (fairly) standardized and known formats. In general, DCC tools with animation support allow you to mix in blendshapes and bone animations together. If you do require blendshapes, this could be supported by a script in the DCC host environment (eg a blender script) to convert from bones to vertex offsets. Another advantage of this is that we can now also support (game) engines that use skeletal animation for animating faces. It's easy to convert from skeletal animation to blendshapes, the other way around is a lot harder.

We prefer to move any tool-specific data and logic out of MH core and into scripts for that tool.

[Mikel_J_Gee]

We prefer to move any tool-specific data and logic out of MH core and into scripts for that tool.

And that's one of the best decisions MH core team could ever make: Not beeing "Jack of all Trades Device".

[brkurt]

We prefer to move any tool-specific data and logic out of MH core and into scripts for that tool.

And that's one of the best decisions MH core team could ever make: Not beeing "Jack of all Trades Device".

It's hard to express how much fun it is to create both poses and facial expressions using the MH mesh/rig when over in Marvelous Designer. It worked right 'out of the box' because MH and MD kept to the Collada standard, which last summer, DAZ did not.

The DAZ users were mighty furious! They made the Marvelous Designer programming team work round-the-clock, as both the users and the accountants were on their case.

[Mikel_J_Gee]

It's hard to express how much fun it is to create both poses and facial expressions using the MH mesh/rig when over in Marvelous Designer. It worked right 'out of the box' because MH and MD kept to the Collada standard, which last summer, DAZ did not.

The DAZ users were mighty furious! They made the Marvelous Designer programming team work round-the-clock, as both the users and the accountants were on their case.

Well, it's not SOO hard to imagine, as far as to look at the (let's say) "classical Marvelous Designer User", who is focused on creating clothing & access. - or should I say "a Fashion Designer, who needs Models, with expessions"....

But the discussions here are aiming into the fact, that there is the (so called) issue or declaration of missing or lost features within a software, which wasn't thought to be designed to serve the "whole wourld" - and!! - that's on top of all - at zero costs level!!

Sorry, if I look at the prices of Marvelours Designer, then I have to answer: "Well, if those custumers "rose their voices".., well, it's ok. Cause that team was payed for their work.

Who pays the enthusiasmn of the MH core team?!!