First things first, I would prefer this thread avoid any kind of software comparison war, because although I do want to discuss features that I'm pretty sure I've seen elsewhere, I want to get a grasp on whether they're feasible and useful to request as a future advancement for Poser, without being so difficult to implement that it's never done.

There have been plenty of arguments about what methods are necessary or unnecessary for good rigging of figures. Some have advocated for an absolute minimum of JCM to ease the transfer of figure shapes to clothing or promoting the concept that they are entirely unnecessary if the weight mapping and joint centre selection and mesh vertex layout are done "well enough". I am not personally a subscriber to this opinion, as it seems to be too restrictive of users with developing talents, rather than those in the full flower of their development skillsets. It also denies the possibility of a "quick fix" with a JCM, where a weight map isn't quite operating in the desired axis.

Anyway, the crux of my request for discussion is the concept of alternative algorithms for application of weight maps across the range of movement of a single joint axis. Looking at Poser CR2 files, joint parameter channels seem to have most of the features of normal channels, with the addition of their special methods defining algorithms and sphere zones and weight maps, and the exception (it appears to me) of making use of the channel value, since these are never keyframed, yet are also not static parameters.

I present, as example, a single joint parameter (with numerical values replaced to avoid any breach of copyright):

        jointX abdomen_jointx
            {
            name abdomen_jointx
            initValue 0
            hidden 1
            enabled 1
            forceLimits 1
            min -100000
            max 100000
            trackingScale 1
            keys
                {
                static  0
                k  0  0
                }
            interpStyleLocked 0
            algorithm 0
            angles [float] [float] [float] [float]
            otherActor abdomen:5
            matrixActor NULL
            center [float] [float] [float]
            algorithm 0
            flipped
            primaryParm jointx
            zones
                {
                weightmapzone
                    {
                    active 1
                    math 2
                    mapname 1498605728_12
                    }
                }
            doBulge 1
            posBulgeLeft [float]
            posBulgeRight [float]
            negBulgeLeft [float]
            negBulgeRight [float]
            jointMult 1
            useBulgeMapLeft 1
            useBulgeMapRight 1
            calcWeights
            }

It would be really useful to know what the various algorithm and math code numbers represent (I haven't found this in the documentation).

It occurs to me that if a valueOpKey operation could be applied to this channel, the weightmap could be driven in a non-linear fashion according to the keys set. I can imagine that this might be problematic or require new syntax to specify, since it would need to be an adjunct or override the existing math controlling the weight mapping. However, this proposal for new functionality seems to me as though it could indeed provide a weight mapping solution which would not require JCM correction.

Thoughts and criticism and civil debate would be appreciated before I elevate this to a formal feature request.

---

My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.