Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nemyax]

When the "locked" effectors are animated (I'm working on this now ) they will move in a manner similar to any other key-animated point, along with the position of the figure.

This is excellent news. Thanks for clearing it up.

A better term might be "active" or "enabled" or "". Any ideas?

"Enabled" sounds fine.

Steve
If I may be so bold as to request something big =) You're now working on animated transforms for effectors, so they are going to have the power to float about. Chained bones don't have this power in Anim8or. So how about making it possible to start bone chains from effectors, like you can do now from the root bone? This would enable the user to move skeleton parts about freely (not as far as IK lets them, but anywhere at all), while retaining the chained nature of bones.

[daniel99]

johnar Steve To be honest, I have no problem naming it lock, or hold, or keep, or block, or stop, or anything else, as long as it eases the animation process and works correctly. I dunno how it's called in other programs because I do not use other programs.

[Steve]

nemyax: Currently effector are implemented as goals for where the end of a bone should be. But the bone structure is still just a single tree starting at the root. Adding the ability to start a bone hierarchy at the goal position would probably be as much work as supporting arbitrary bone hierarchies - something that I certainly see the value in but I want to hold off on adding until I get all the things I'm working on now more or less finished.

I'd like to start concentrating on getting another "official" release out, with updated documentation and web site - then on to better bone structures, etc.

[nemyax]

arbitrary bone hierarchies - something that I certainly see the value in but I want to hold off on adding until I get all the things I'm working on now more or less finished.

I'd like to start concentrating on getting another "official" release out, with updated documentation and web site - then on to better bone structures, etc.

Fair enough! It's good to know you've got arbitrary hierarchies in the back of your mind.

[daniel99]

Steve A new official release would be nice. I've seen there are people who do not know there are many new builds for anim8or, because they don't check the forum
Anyhow, me personally, I would have the end-effectors lock position/rotation for the latest bone in the chains added, and fix for the "wiggle" before a new official release...but that's just me.

[justiceiro]

wow, the development of this program has come a far way, hmm. Congrats steve!

[neirao]

yes Steve,
i gree with daniel99,
in last week im in facebook 3D group, and talk about Anim8or, some users tellme about think  that Anim8or no have news versions... so i tell hers about the  new versions only in the forum!!

[johnar]

Firstly, i'd like to agree that these updates are amazing. Excellent stuff steve.
 The IK is behaving a lot better, but still some  problems.
 Have been trying first to understand the best way to use it, or, how it works best.
 Below is a clip  showing feet locked in place using the IK system in 'poser', and dragging the robot around by the hip. His feet will actually leave the ground, but will return to the initial 'locked position' once the legs can again reach the ground.
 (please try ignore the 2nd 'still' robot. Just a setting i couldn't find)

 This next 1 is Froyd, in anim8or, with both feet locked to the ground, and moving the root bone to move him around.
 Please ignore the 'toes'. He's locked at the heal, so the toes are fixable, and no real concern.
 Froyd, (anim8or) is acting very similar to robot. (poser)

 Well done steve. That's absolutely awesome.
 Please note tho, 1 problem i'm seeing.
 You'll see with the poser example, the feet are clearly locked to their positions, even when dragged away from the ground, they nearly 'snap' back to where they should be, just as soon as they are capable of reaching those positions again.
 But if you have a look at froyd, his right foot starts at the locked position, is dragged off the ground, and returns to a higher position when it should really return back to the original 'locked position'.
 This is a fairly mild example.
 I guess what i'm saying is, it's really, really close to behaving as it should, but still showing some oddities, as above.
 So, all in all, coming along really well, but maybe  still some work needed on 'solidly' locking those end effectors into place?


 EDIT: steve.  I'll keep playing with it, maybe i'm missing something, or just doing something wrong here.  Does take a bit of learning. Thanks heaps.
Would be good to hear if anyone else is getting any strange behaviour....

[nemyax]

Yes, animated end effectors shouldn't snap to bone ends automatically. A manual snap command would be good enough for when you really need this.

[johnar]

yes. (maybe a good idea)
 Tho i was really only meaning "nearly snaps", as in 'it goes straight back to the exact same spot it was locked too, and then just doesn't budge from there'.
 What i'm really noticing is 'drift'.
 I've seen you and steve discussing the idea of less keys. (?)
 I'm seeing now that using IK is creating a lot of keys, and wondering if maybe, perhaps, the drifting is happening from influence from a key further along the chain. ?.
Could be completely wrong, of course,.....

[daniel99]

Yes, johnar. Good example.
But my concern is the orientation of the feet. Like Steve said, he's gonna try and fix this too.
In some cases, only one bone will be used for the foot (take for example an elephant). That bone being the end-effector keeps it's position when it's locked...but it also should keep it's orientation locked.
In the poser example you provided, the robot's feet remain fixed on the ground, and the toes do not get 'into' the ground. Froyd's toes do.
But I have enough confidence in Steve. I'm sure the next release will have this fixed. Ani8or Rocks

[Steve]

johnar: "and returns to a higher position", i.e. the "drift". Yes, this certainly is a bug. The locked position shouldn't move unless you specifically move it, so once the figure returns to within range the effector should lock-in exactly where it started.

I working on additional constraints like keeping the orientation of the foot flat (so the toe doesn't go into the ground), and a true "locked" effector. I plan to keep the current "goal" effector as well since both can be useful.

I thought the second robot was intentional - it's a good reference for the motion.

[daniel99]

Steve: I was thinking ... an easy way would be to have something similar to the Lock Position checkbox....Lock Orientation Checkbox

[Steve]

daniel9: Thanks! But the dialog isn't the difficult part

[daniel99]

Yes, I know!