What would be the possibility of making a visual node editor like NME but for Weighted Animation States?
Kinda like Unity’s character controller?
2 Likes
Heya P8… interesting thought. I am originally from Wisconsin, and believe me, it is a state with some SERIOUSLY weighted animation. hahah… ahem.
Ok, stupid joke done… pryme-ary reason for my post… completed. Now for some REALLY worthless crap…
Butt seriously, don’t you feel/sense that things like NME… are tools for “packagers”? The NME will not become widely-used by the general populous. The material packages that were created WITH IT, will be widely used… maybe. Agree? Thoughts?
Now, weighted animations… as that term is used in Unity and Unreal… is a “layer” thing… and it means "the amount of influence (weight) that “extra” (different layer) animations… will have upon the “master animation”. One master animation, and 1-to-many “slave” or “outside-influence” animations… each with a single number in their bind-togethers (between layers). That number… is the weight. The amount of influence a slave anim… is allowed to have upon a master anim.
And naturally, mad scientists will “cascade” these… having a slave anim… be a master to other slaves, who could each be or have-been masters for/to THEIR slaves, etc, etc. Only the lowest of slave animations… “the primitives”… (the pryme-8’s?) 
…won’t ever be masters. Other anims will be masters of THEIR layer, but still used as slaves to higher layers, or lower layers, depending upon your point of view. Do you see… that there will be many pre-made “packages” in THAT world, too, and only “the people who like making packages”… will be using a viz-editor (like the NME) for that, too?
There is another “weighter” that folks hate thinking-about. User input. The difference between a character “marching in-place” animation… and a walking-to-some-location animation… is a drag-influence or keypress. When you bring IK into the ball game, the difference between a natural walking arm-swing, and a raised arm, is a click on the hand and then a click in the air above the player’s head. The natural arm-swing anim… got “weighted” by the hand-drag, or by the select-hand-and-then-click-where-you-want-it-to-animate-to action.
Then, there’s scene items… hills… collisions, all sorts of physics, and the actions/anims of other players in the same scene… all can be considered as “weighting-factors” for currently-in-running-state animations. But still, there is only a single actual weight value involved in the binding of these outside-influences… and that’s a percentage. How much influence on the current master animation state… is allowed from THIS outside influence. BUT, that influence allowance… can change each frame. An influencer… can actually change the weight values for OTHER active influencers… maybe. I don’t know if we will allow influencers to influence the amount of weight exerted by other active influencers. That’s a bit imposing. 
But, already we see… animations be interrupted/stopped… when user input is seen (gamepad button, for example)… so it is not so far fetched to think that MANY influences will lessen the weight of other already-bound influences. A physics action is a great example. Characters might quit ALL current-state animations… when a 5000 Lb. soft-body blob lands atop them (a Wisconsin girl). Then, ya KNOW the user will try to do an IK drag on the hand that is sticking out of the blob… and try to drag the character out from under the soft-body, and thus programmer will have to run the “user rips off arm of character” animation… and… you know… lots of weights get involved in all that weight.
Ok, I have no idea where I’m going with all this crap. It seems that editors like the NME… are for a niche populous… not for the stampede-o-puppies. The herd-o-puppies (which actually contains some girls, which we rarely see in BJS land) wants easy plug’n’play snap-on/off Duplo blocks.
None of what I say here… affects the validity and justification of your query/idea. If anything, it affects the packaging/modularity of the PRODUCT made with NME-like node-editors. When you are dragging “weighters” (influencing factors) out-onto your NME-like canvas… and you drag the gamepad node, and the collisions-with-other-mesh node, and the physics engine node… out-onto that canvas… what did you do? Did you cause something new and fresh? Was it a new and fresh massive migraine headache?
Just thinkin’. What IS a weight/influencer? When user does an IK drag of the fingertips of the walk-swinging-hand… into the air… but with not enough weight/influence to complete the task, does the arm raise part-way, and keep walk-swinging… but now somewhat in the air? Or does the IK drag animation… keep reducing the weight of the arm-swing animation and keep increasing its OWN influencing weight… until the master arm-swing animation has NO more influence, and the IK drag has it all? Do we shut-off the arm swing animation when its influence nears/hits 0-weight?
Should influencers be allowed to decrease the amount of influencing weight… of other already-applied influencers? Will we see “weighter wars”? Will character arms be willing to put-up-with such tug-o-wars? Does the physics engine ALWAYS WIN, no matter how many weighters are yanking on the character’s arm? Where’s it all going? Do we follow the herd-o-puppies to popularity-ville? Dumb it down? Or keep them in their place in Duplo-land, while the “real men”(-only) hang-out in full-power land? Will we EVER see girls in full-power land? heh.
Skeletal Muscle Contraction Simulation: A Comparison in Modeling There we go. Muscle-fiber and tendon modelling. erf. No standard animations on those avatars/armatures. Instead, programmable sequences of muscle/tendon contractions with various elasticities/abilities. All character movements are “requests” and not “orders”. FUN!
Muscular and Skeletal Systems Easy, they’re all just another kind of physics force that affects physics joints. But the animation… comes from requests, and thus the “fighting” that easily happens when two or more “forced-animations” compete to be primary influencer… is minimized. Instead, everything cooperates… because everything… communicates its “hopes”… and abilities to influence.
Arm swing is actually a no-force thing… the arm is often free-wheeling. When the request to raise arm arrives, many values are checked to see how much forcing is allowed… by the new request. Arms won’t rip-off when user IK-pulls on the hand protruding from beneath the blob. A drag REQUESTS influence… and if all the other factors allow it… including max tendon/joint strength, then the action happens, and maybe only partially. NOW we’re “getting real”, eh?
Just a couple JS physics classes… AI/fuzzy… bone transform requesters… about 20 precisely-placed applyImpulse generators per joint. Easy. In JS… frame rates around 5. 
“soft-animating”. Asking for something to go to work - never forcing.
1 Like
hahah what a fun read this morning, it’s nice to see you are still active bud! I can’t think of the last time we talked.
and yeah I believe you are right, I think it is kinda niche but it does open up the ability for visual debugging which in a visual medium is very very useful. Plus its kinds becoming something that is pretty much the only thing you can find when you look for “Programing Character Controller”, is Unitys state manager.
I look at it more as a tool for make full scale projects with BJS an easier to achieve goal, so it might not really be something that every user uses, but people who are looking to have dynamically weighted animations on characters and things will be grateful.
1 Like
I’m glad you laughed. Have you looked “under the hood” of the NME, yet? i would think that it’s basic framework can be adapted to many other applications. Have you thought about the properties you want to wire-up?
With animation SO-based upon time-(code)… you could discover that the visual editor you dream-about… is not very similar to the NME-style thing. The time-line is the boss, and you COULD drag’n’drop animation event-nodes onto a visual timeline, but, the similarities to NME… probably end there. There seems to be no need for “wires”. The visual timeline could use the entire bottom-half of the screen… and be many strata layers tall (rows). Many animation events could happen at the same time… stacks.
And there’s this other issue. With lerps, next animation step !== certain time. So… IS IT a timeline you are editing? Or is it… the lerp-steps. onNextLerpStepObserver? Do we really care about time (other than total run-time)? Don’t we more care-about each step in the interpolation, because that’s what BJS engine cares-about?
I’ve played with the animation system/editor in 3dsMax a bit… older 2013 version, but I can’t imagine that a webby editor would look much different. Just a whole lot of dragging items onto a timeline, and hitting PLAY and seeing what happens to the model. I’m just not sure such an editor… would look-like the NME very much. The NME can do its compiling at its own rate, and its products wire themselves-up… just as fast as the NME-produced JS-code… will run at runtime.
But an animation editor… has quite different priorties and time-dictated characteristics. I’m not sure how much would cross-over. Certainly, our NME team has webby menus and draggable graphics/svg/html/whatever it is… well-mastered. That part… you could steal for ANY vis-editor. But the functionality… quite different. I dunno.
I hope I didn’t ruin the thread with my yapping… and I hope some “Team NME” devvers comment. I’m completely un-quailified to talk about this stuff, but it sure is a thing I think-about… often… especially when a pup comes rolling thru asking “How can I make my player walk and jump and throw bombs?”
Well, kid… first, hook these electrodes to your head. Set the voltage/amperage to HIGH. Now, push that big red button, there. bvvvvrrrrrrrt. There, problem gone, mark this as “solution”… bye. hehe
I killed the thread. Cool, huh? Admin should peel-off my yammering and spawn it in a Projects and Demos thread… maybe labeled soft-animating, because I’d like to discuss that, more.
In many ways, soft-animating (SA)… is like the 2nd parameter on a physics joint setMotor(speed, maxForce). The maxForce is the amount of slippage, allowed.
From some spacecraft folding landing-gear experiments with physics setMotor tests, I know that the maxForce parameter affect both maximum motor torque/grip, but ALSO tendency to back-slide.
In many cases, we want the motor to lift a mass as much as it can, and then LATCH at that point… no back-slide. But our current physics-joint motors… don’t latch. The motor will move the mass (against gravity) as far as maxForce will allow… PLUS the residual mass momentum. The amount of momentum at motor-slip time… is affected by the speed of the mass at the time maxForce was hit.
In short, our physics motors… when lifting against gravity (as in a one-sided teeter-totter or front-end loader)… WILL backslide a small amount… after reaching point of maxForce. Continued motor-run will result in a “bobbing” or bouncing… near the point of lift where maxForce was reached.
We MAY see a setting on physics joint motors, someday, that allows an automatic latch-in-place at point of max-force. THEN… we can shut off the motor, and the mass will remain in place. But really… this motor latch-in-place device… might be a bit of a physics item itself. It could bend, it could break, it could slip (based upon its friction, etc). And of course, it must have an un-latch method.
PERHAPS… one of the features of this new hinge joint “latchAtMaxForce” class… is to activate a motor and set its speed and maxForce to some precise values… so that when we unlatch this mass… it stays in place as if it were still latched/locked (in a gravity-affected or high-winds-affected scene, of course).
When we animate using limited-slip physics, and say goodbye to “hard/forced animating” such as keyframe interpolated “poking values”… we have entered a different world.
IF someone were to take that step… that deep dive into ONLY animating armatures via soft physics (requests to move, not orders to move)… THEN an NME-like editor might come-into-play a bit more.
Even the “wires” that connect the nodes… they could return in all their glory! Drag-out a hinge node, a motor node, a speedNode, a maxForce node… and wire 'em together… with “weight” values on the wires/bindings. It’s really… a visual physics editor… but using it on an armature joint… would be commonplace… WHEN DOING SOFT-ANIMATING (physics movements only).
A highly-advanced physics-only soft-animated walking armature… would essentially be a “stream” of applyForce/applyImpulse commands, probably “marshaled” by an artificial avatar balance system (a software gyro).
That would be performance heavy. But what-if… we had lightening-fast and precise-powering control over limited-slip joint motors? It would APPEAR that the joints each had 20 points of applyImpulse to keep things operating (simulating muscles, tendons, ligaments). But no… we are, instead, nearly-streaming motor commands (essentially bone transform soft-REQUESTS).
Keep in mind… it is the limited-slip of the motor’s maxForce feature… that keeps the motor being a SOFT animator. If the maxforce were allowed to be set to infinity, that would be hard-animating, again… no good. We need to allow our walking animation… to be interrupted by an inbound beer truck, right? (or a “massive” blob from above). Ragdolls with muscles (or sim-muscles using many/fast limited-slip setMotor commands - which are actually requests and not commands, due to maxForce).
The quickest way to make an armature look badly faked… is to make it fight forces… like a fixed keyframe animation… fighting against a physics interaction. If the keyframe animation never “gives way” (goes soft, allows influencing from other forces)… it will look fake. The animations must give-way to more powerful influences. All movements… must be requests.
So, admin/pryme8, feel free to glean-away my yapping to another thread somewhere, and let’s talk about the new Physics Animation Node Editor. Thoughts, anyone? Sorry about contaminating the thread with questionable on-topic-ness.
1 Like
It’s all on topic depending on your perspective.
If you wanna start a thread about motors and joints and things, Id be glad to hop in on that.
1 Like