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.

Just throwing this out there, you can already animate some of the weight map channels. The issue, is an easy way to edit them.

As far as a weight mapping system to eliminate jcms, you need to be able to move vertices on the 3rd dimension to the joint. Which again can be partially done already, but has many issues and consumes channels normally used for something else.

Oddly, I don't know of a single joint system that doesn't need jcm's. Even implicit rigging uses them....

@shvrdavid, that's pretty much my experience. I'm really looking at the situation where joint movement starts with a nearly linear muscle flexion until the joint gets to a point where a nearby bone starts to influence the shape, and things need to be non-linear, or even start introducing additional bulge. Even cases where the muscle shape change starts to reverse as other muscles take over the joint movement.

I know that a significant proportion of JCM effects could probably be replaced with additional ghost bones and weight mappings, but then that seems it's additional complexity for no necessary gain that couldn't be delivered by non-linear JCMs, since the valueOperations controlling the JCM can just as easily control a ghost bone and it's dependent weight maps.

I suppose it would be nice if there was a definitive report on what the performance overheads of the two systems are, if any. Something that's almost impossible to measure without hooks into the Poser source code. I know that the joint bending process has the ability to multi-thread. I assume this applies equally to weight maps and morphs.