Scalar rigging in general

[Solkar]

Consider a humanoid starting in base position, then kneeling, finally sitting on heels.
The respective vertices of the Mesh will follow the down-movement and the bending of the upper and lower legs.

BUT what will happen to the skin above e.g. the m. vascus lateralis, m. miceps femoris and m. gastrocnemius?
In reality, they are deformed so the thighs and lower leg are broader than they were in the upright position.

All can be given a weight related to the lower leg rotation, but because the direction of the mentioned deformation is normal to the plane of its rotation, this deformation cannot be implemented by weights of the knee's rotational dof.

In the old mh 0.9 "animorph"-compatible data set concepts like this were realized by the combination of rotational and translational weights which were assigned to a sorts of synthetical rotations which were composed of xyz limb rotations and transl. morphs. Unfortunately, that rig is not overly IK-friendly and has other drawbacks, too.

Is a refined concept like this implemented or is it planned this be implemented in future mh versions?

[duststorm]

Is a refined concept like this implemented or is it planned this be implemented in future mh versions?

We are planning/experimenting with a muscle rig that will have realistic muscle deformations. The new basemesh will be in an A-shape rest pose instead of a T-pose which will make poses look more natural in most cases as well, without the need of complex corrective shapekeys to correct the shoulder errors.

[Solkar]

From what I've experienced, assignment of simply scalar weights only to rot. dofs is a general conceptual issue of major related standards, like COLLADA, X3D hanim etc.

Over the time I re-implemented the animorph-algorithm once in plain C++, once in Fortran as an MPI-binary for a C++-client for the purpose of ingrating it into a modular production pipeline and to speed it up.
Doing that I was considering condensing the animorph dataset into a more plain rigging scheme, but found no suitable standard for that purpose.

Maybe one could consider a COLLADA extension for
- assigning a single initial deform vector v_ to each vertex affected by a certain rot. dof.
- along with a second (third? fourth?) order polynomial approx for dv_/dθ, dv_/dψ, dv_/dφ (θ, ψ, φ Euler angles)?

What do you think?

[duststorm]

[quote="Solkar"Maybe one could consider a COLLADA extension for
- assigning a single initial deform vector v_ to each vertex affected by a certain rot. dof.
- along with a second (third? fourth?) order polynomial approx for dv_/dθ, dv_/dψ, dv_/dφ (θ, ψ, φ Euler angles)?

What do you think?[/quote]
I think that we are not in a position to propose extensions to the COLLADA format and actually make it count.
For it to be useful, the big commercial software packages need to adopt it.

If COLLADA does not offer these means, maybe FBX does? It's not a full solution, but a lot of tools have adopted the FBX format.

[Solkar]

I think that we are not in a position to propose extensions to the COLLADA format and actually make it count.
For it to be useful, the big commercial software packages need to adopt it.

I don't think one even has to ask someone for approval before getting started.

Provide an Easy Integration Mechanism
Goal: To provide an easy integration mechanism that enables all the data to be available through COLLADA.

• Design the COLLADA API and future enhancements to COLLADA to ease the extension process by making full use of XML schema capabilities and rapid code generation.
• Encourage DCC vendors to make exporters and importers that can be easily extended.
• If developers need functionality that is not yet ready to be in the COMMON profile, encourage vendors to add this functionality as a vendor-specific extension to their exporters and importers.

And there is this "profile_X", <technique_X>" and "<extra>" mechanism available for vendor extensions ("X" meaning whatever shorthand).

If that is later included in upcoming standard versions is a different issue,

• Collect this information and lead the working group to solve the problem in the COMMON profile for the next version of COLLADA.

which does not need to be taken as conditio sine qua non for the question whether to get started or not.

Just my pov, of course.

Regards, S.
[Khr08]Khronos Group. "COLLADA – Digital Asset Schema Release 1.5.0 Specification." Apr. 2008. http://www.khronos.org/files/collada_spec_1_5.pdf

[duststorm]

Of course we can add our own extensions, but what tool will support them? At least, without us having to write the importers for all the tools we wish to make MH compatible with.

[Solkar]

Thar's why I'm considering "<extra>" tags.

If a tool does not support that muscle-deform aware rigging of that to-be-created "profile"/"technique" , it can still use the standard rigging as it is of today and just disregard what's "extra".
But if it does it gets a better quality - that's motivating incorporation, isn't it?