Bone linking and per-axis weighting.

JD_MortalJD_Mortal Posts: 760
edited August 2015 in Product Suggestions

I seem to have hit a major development hindrance stemming from the inability to "Link bone-values", and/or "Define per-axis shared weighting" for bones.

I need the ability to link Bone-A to Bone-B, preferably with the ability to designate which modifications are linked to one another, or a control that can link to multiple bones, designated manipulation functions.

EG, A slider that allows me to manipulate Bone-A (-X Translation) and also Bone-B (+Y Rotation). Or, Bone A, B, and C's X-Translate, all at once... One slider, not three. Setting the ZERO base value for each, and setting the MIN/MAX end-values, or a ratio + and a ratio -, as they may not be the same values. (Honestly, I would settle for one link that just matched the value of all controlled manipulation values, but when mixing rotations with translations and scales, you need those extra values and limits.)

The second request, which would be better to have for everyone, as it will allow realistic articulation response that is not robotic... Would be "per-axis shared weighting", that could and should extend to all manipulate functions... Translate, Scale, Rotate, on X, Y, and Z. Naturally, as a selectable option, where all values are selected by default, as that is how the program operates now. Shared, as in... We can weight a point on X and on Y and on ROTATE and on TRANSLATE, where the shared value is only "mixed", when two competing values are faced. EG, if one bone modifies X and the other only modifies Y translation, that shared surface moves X from the one bone, and also moves Y from the other bone. However, if it moves X from one bone, and X from another, the value is simply the average of the two, the delta.

EG, Mapping the elbow to Y-Rotation, but mapping the side of the elbow more on the X-Rotation and Y-Rotation, so that the elbow stretches when bent, and the side-arm only twists when twisted, or does not twist when twisted... or twists opposite, with negative values. (Oh, add negative-mapping to that list. Get rid of bulge. Negative mapping = bulge. Instead of skin on the bicep bending into a fold, it should be bending outward to form the muscle-bulge when flexed, as the triceps should naturally bulge when the arm is returned away from bending. Similar situation with the wrist and elbow, our skin does not twist there, it twists along the forearm, thus, the isolated X-Rotation there, for weight-mapping, while that part does not "stretch" like our elbow does, as we bend our arms.)

I'll take bone-linking first... If I get a choice. That simple addition, which requires nothing more than an adaptation to your "ghost bones", to simply alter more than one bone... However, Bones should just be called bones, period, to reduce clutter. If we want to make it a ghost, we should just select it and second-mouse-click to alter that bones attributes to "Daughter of..." or "Ghost of..." or "Child of", naturally defaulting to a child-of prior bones created or the selected bone. (Duplicated in the bones property page, in the tools... "Ghost of..." etc...)

P.S. We need group-link manipulators too, for NON-FIGURE objects, such as doors and cars and streetlights... Stuff that adding bones is overkill and bloated hacks just to get simple self-manipulations of sub-object components. That, or kill "objects", and make everything that imports into a "Figure", instead of telling us we have to turn it into a figure before adding bones or doing half the common editing things that should be possible on things that only have the original node/bone. (Your double-bone system that breaks most external editors. Talking about the primary invisible node/bone that requires a physical node/bone that can't be manipulated like a bone, because it manipulates the object the exact same way that the invisible node/bone does, and is thus, redundant, in the editor and in code and in manipulation.)

P.P.S. Fix the translucent surfaces so they "Render back-faces"... Ten years, and that is still an issue with all transparent hair, rendering the back-sides and not the front sides, when it should be rendering both, because you see both sides on transparent GL objects. (It comes before the PUSH and POP.) :P

Post edited by JD_Mortal on

Comments

  • JD_MortalJD_Mortal Posts: 760
    edited August 2015

    Some real-world examples of this being used with objects are the following...

    Animation, a simple "second timer", Used to control anything that needs time-based modification in the animation... (This shoud be a core-bone of all animations, that any bone can link to.)

    - Clocks, (Second hand rotates 360-deg 1/60th to match the 1-second frame-time of 60FPS, 1/60th), or the Hour hand, or minute hand, at respective rotations and ratios of 1/216000 or 1/3600

    - Car wheels, Turning at a ratio, in time, in the animation, to simulate 25MPH, 100MPH, or motion of passing by 100MPH by linking to translate. (Instead of guessing positions.)

    - Car wheels, in relation to steering wheels, the steering wheel turns 720-deg, the wheels only turn a ratio of 1/30th of that... 24-deg. (For example)

    - Car windows, the crank spins 8x 360-deg, but the window doesn't spin around, it translates on Z and possibly tilts-back to fit inside the car door without clipping through the window-trim, since it is a curved or angled surface.

    - Walking, bending joints, we don't usually bend only one joint at once, it is a combination of multiple bends to simulate "raising a leg" or "extending an arm", as opposed to "bend elbow" or "bend knee", relative to something like poses or minor adjustments. (Same with twisting arms, we rarely twist just our fore-arms, we twist our whole arm, at respective ratios, on a "twist" of our wrists.

    - Trunk-tops and cabinet doors. Many have secondary shelving or trays that extend out as the doors open. Fixed-mounted trays that travel in linear paths or a path and an arch, which would not be handled by just a rotation.

    - Trash-cans with foot pedals. You step on the pedal, the lid opens by a back-jointed extension on a pivot.

    - Drawers open outward, but drop-down a little, as you open them, at the extended limit.

     

    Those are just a few of the billions of places that a simple bone-link or per-axis mapping, or both, would come in handy. Some things can be done with morphs, others can not. Morphs are bulky bloat and not quite the same, but similar... Since they do just that, but with shapes, not just bones. This would be better unseen, as the primary universal action, of the core model, not something a user has to adjust. The model should just function that way, when you rotate it, or move it, or pose it, without a secondary morph. (Which is why I asked for the request.)

    Post edited by JD_Mortal on
  • These are handled with ERC as long as all of the properties are on the same figure (they can be on different bones though); it's possible to do this with parented props but requires manual configuration.

    Set the properties so they are correctly related - for yuour clock, for example, set the second hand to a full rotation and the minute hand to a one minute rotation.

    Right-click on the Parameters pane and set it to Edit mode.

    Right-click on the controlling parameter (in this case the rotation on the minute hand) and select ERC Freeze.

    The controller should be listed at the top, the panel at the bottom should list everything that is to be controlled - in this case just the rotation on the second hand. Click Accept.

    Test, if it's working add the next link (minute slaved to hour perhaps).

    Once done, save as a figure (or if you've already done that use File>Save as>Support Assets>Save Modified Assets).

  • JD_MortalJD_Mortal Posts: 760
    edited August 2015

    Love all your suggestions, BTW.

     

    I saw one slider modify multiple values... Though it is external, that is technically a "multi-bone-link", as I see it. (Just doesn't work in reverse, by modifying the bones, via one or the other and you can't see which bones are linked, or have links.)

    I am digging through all the files that are not encoded or some kind of custom DB-lib of data, and seeing how others have done some of these tricks. The problem is two-fold... Finding someone who did a trick like this, and then reverse-engineering how they did it. xD.

    Post edited by JD_Mortal on
  • DS does support one-to-one matching between controls, wheer changing one changes both, but circular ERC - where one control influences the value of another, which itself influences the first - is prohibited. If it were allowed a change to x would change y would chnage x would change y and so on - it would be a recursive loop that would drive the values to their limit or to infinity.

  • JD_MortalJD_Mortal Posts: 760

    DS does support one-to-one matching between controls, wheer changing one changes both, but circular ERC - where one control influences the value of another, which itself influences the first - is prohibited. If it were allowed a change to x would change y would chnage x would change y and so on - it would be a recursive loop that would drive the values to their limit or to infinity.

    No, I was thinking more like...

    "MyControl"

    SetValueAlters ((xRotate[object1]+12)*4), ((yTranslate[object1]*-1)-300), (yScale[object2])

    EG, Slider value 400, alters the above, as formulated... Three individual values.

    As for xRotate altering xRotate on itself, that is impossible, the value would remain 0 or = in formula. In code, altering xRotate of Object1 from Object2, from Object1, is easily also avoidable, prior to "Saving" the links. Just don't allow back-linking. Linking is singular between bones Source-Target, or grouped, one-way Source-Target. Backlinking would be the other way, but that is still Source-Target, and would not IK.

    By the way, you just described the "issue with IK". The infinate spinning twisting body parts. They handle that well... UNDO. xD.

    This would "Solve" the IK issue, and reduce our need for it, since it doesn't work anyways, 90% of the time. Whch actually stems from the fact that the HIP is the center and not the foot-base in the IK chain. It has to reverse calculate where the toes should be, when you move your arms... if you pull your hip back, and that is why our feet flutter and can't pin-down correctly, and stay still. (Added to the odd manipulation motions they translate the mouse-moves into, which are a nightmare to attempt to manipulate anything with, except on some micro motion or solid linear axis.)

Sign In or Register to comment.