Leg deform

[Solkar]

Or are the drivers programmatically breeded up-from-scratch on export?

[...]Try mhx_drivers.py

Nice one.
Pls guess what pattern I had used for a 'find' of driver-related stuff pls
'*driver*'?
Got it!

mhx_drivers.py is about how drivers are written to the export file; but I wanted to know

but where are data files for the drivers

or where the drivers are calc'ed.

I fear that they are buried in some .py source file in shared/mhx/

So it appears.
(But there is "Nothing to Fear" at all as every old Depeche Mode fan knows.)

Trying e.g.

Code: Select all

find $CURRENT_MH_VERSION_DIR  | xargs grep -i arms-back-70

took me to shared/mhx/rig_shoulder_25.py ($CURRENT_MH_VERSION_DIR valid for my env only)

Code: Select all

479 if False:
480     ShoulderTargetDrivers = []
481 else:
482     expr70 = "%.3f*(1-%.3f*x1)" % (90.0/70.0, 2/pi)
483     expr70_60 = "%.3f*max(1-%.3f*x1,0)*max(1-%.3f*x2,0)" % (90.0/70.0, 2/pi, 3/pi)
484
485     ShoulderTargetDrivers = [
486     ("arms-up-70", "LR", expr70_60,
487         [("UpArmVec", "DirShldrUp"),
488          ("UpArm", "UpArmVec")]),
489     ("arms-up-70-pos-60", "LR", expr70_60,
490         [("UpArmVec", "DirShldrUp"),
491          ("UpArm", "UpArmVecPos")]),
492     ("arms-up-70-neg-60", "LR", expr70_60,
493         [("UpArmVec", "DirShldrUp"),
494          ("UpArm", "UpArmVecNeg")]),
495
496     ("arms-down-70", "LR", expr70_60,
497         [("UpArmVec", "DirShldrDown"),
498          ("UpArm", "UpArmVec")]),
499     ("arms-down-70-pos-60", "LR", expr70_60,
500         [("UpArmVec", "DirShldrDown"),
501          ("UpArm", "UpArmVecPos")]),
502     ("arms-down-70-neg-60", "LR", expr70_60,
503         [("UpArmVec", "DirShldrDown"),
504          ("UpArm", "UpArmVecNeg")]),
505
506     ("arms-forward-70", "LR", expr70_60,
507         [("UpArmVec", "DirShldrFwd"),
508          ("UpArm", "UpArmVec")]),
509     ("arms-forward-70-pos-60", "LR", expr70_60,
510         [("UpArmVec", "DirShldrFwd"),
511          ("UpArm", "UpArmVecPos")]),
512     ("arms-forward-70-neg-60", "LR", expr70_60,
513         [("UpArmVec", "DirShldrFwd"),
514          ("UpArm", "UpArmVecNeg")]),
515
516     ("arms-back-70", "LR", expr70_60,
517         [("UpArmVec", "DirShldrBack"),
518          ("UpArm", "UpArmVec")]),
519     ("arms-back-70-pos-60", "LR", expr70_60,
520         [("UpArmVec", "DirShldrBack"),
521          ("UpArm", "UpArmVecPos")]),
522     ("arms-back-70-neg-60", "LR", expr70_60,
523         [("UpArmVec", "DirShldrBack"),
524          ("UpArm", "UpArmVecNeg")]),
525
526     ("arms-twist-pos-60", "LR", expr70_60,
527         [("UpArmVec", "DirShldrOut"),
528          ("UpArm", "UpArmVecPos")]),
529     ("arms-twist-neg-60", "LR", expr70_60,
530         [("UpArmVec", "DirShldrOut"),
531          ("UpArm", "UpArmVecNeg")]),


and that seems to be the input for the mhx_drivers.py/CDriver c'tor

Code: Select all

class CDriver:
    def __init__(self, cond, drvdata, extra, channel, index, coeffs, variables):
        self.cond = cond       
        try:
            (self.drvtype, self.expr) = drvdata
        except:
            self.drvtype = drvdata

So I would assume
- placing sth like a e.g. "rig_legbend.py" in shared/mhx/
- along with targets shared/mhx/targets/correctives/*
would be conforming to current concepts.

Or am I mistaken?

Regards, S.

[duststorm]

So I would assume
- placing sth like a e.g. "rig_legbend.py" in shared/mhx/
- along with targets shared/mhx/targets/correctives/*
would be conforming to current concepts.

Or am I mistaken?

Probably. Thomas is the only one who can give you a good answer.
But know that this code will soon change or be removed completely, as we will start using the new basemesh. At this point it is impossible to tell whether we will continue to use shapekeys in the future.

[Solkar]

[...]new basemesh. At this point it is impossible to tell whether we will continue to use shapekeys in the future.

So I think a patch of the kind we're discussing here should have a two layer design
- determining the required morph istself
- and means to generate different representations for that.

Just brainstoming a little:
Sth I recently got reminded by Krishnamurthy et al 's [KL96] comes to my mind; they propose a partly manual workflow, in their case interactively "painting" boundary curves.

The insight that one can do sth manually is not exactly brilliant, but sometimes one (at least me) tends to disregard that when it comes to refactoring.
Those insight comes in quite handy here - however a new basemesh may look - we can reasonably presume it will be possible to manually select respective vertices in (whatever) mesh editor

In addition
- "it" will still will have legs
- and those legs will between buttocks and ankles still will each roughly
2 * harmonics x deformed ellipses + ball for the knee
shaped,
- and there will be bones,

so a solution can start at manually created respective vertexgroups and can rely on the existence of (whatever) means of "mapping" dof of leg-bones to morphs.

Also, the current shape key target data format is quite versatile
e.g.

Code: Select all

$> head shared/mhx/targets/correctives/shoulder/caucasian/male-young/arms-twist-neg-60.target
2603 0.003092 0.024586 -0.006634
2604 0.001319 -0.003036 0.000666
2605 0.015129 0.050598 -0.057570
2606 0.003615 0.024313 0.030486
2623 -0.013900 -0.005656 0.026610
2624 -0.003766 0.010610 0.027800
2629 -0.024650 -0.001628 -0.023300
2633 -0.025440 -0.023810 -0.038390
2850 0.002073 0.027088 -0.007189
2851 0.008305 0.009259 -0.003140

so that can be used to encode whatever morphs of whatever vertices - if it does not conform directly to the concept to-be it can at least be parsed trivially.


[KL96] Krishnamurthy, V. & Levoy, M. Fitting smooth surfaces to dense polygon meshes. Proceedings of the 23rd annual conference on Computer graphics and interactive techniques, ACM, 1996, 313-324. doi:10.1145/237170.237270 http://graphics.stanford.edu/papers/surfacefitting/