HeyVern's scripts and tools - (focus on bones)

Moho allows users to write new tools and plugins. Discuss scripting ideas and problems here.

Moderators: Víctor Paredes, Belgarath, slowtiger

Post Reply
donnie
Posts: 111
Joined: Mon Oct 16, 2006 11:53 pm

Post by donnie »

Hey Vern, (Now I get it :D )

Just wanted to say thanks for your work on these scripts, they are fantastic!

I especially like your bone aimer script but was wondering if a version exists that does'nt have the 'scale limits' so that an aimer bone will also stretch out with the target bone rather than disconnecting?

Other than that though its great and Im sure Ill find some real good uses for it so thanks again!

Cheers,

D.

p.s oh yeah, is there per chance any update on whether you've got it to work on more than one bone layer in a single file as that would be really helpful.... thanks for your time and continued forum support!
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

I want to figure out a way to do this interactively with the bone name.

Until I do you can either comment out the code below or delete it entirely with a text editor.

Open any of the aim bone scripts you may have in Notepad or some simple plain text editor and look towards the bottom for the following 3 lines of code:

Code: Select all

                if (bscale > 1) then
                    bscale = 1
                end
You can delete those 3 lines or you can comment them out like this:

Code: Select all

                
--[[
                if (bscale > 1) then
                    bscale = 1
                end
--]]
That's the only part that limits the scaling.

When you save the file just make sure windows doesn't try to change or add to the extension. It should end with .lua and NOT .txt

Sometimes windows will try to change the extension. If it does just change it.

-vern
donnie
Posts: 111
Joined: Mon Oct 16, 2006 11:53 pm

Post by donnie »

Cheers Vern thats brilliant! Works perfect for me.

Yeah a way to enable it interactivley where something like .strch stretches the bone and .aim does what its doing right now would be another brilliant addition.

Thanks for the very speedy reply also- Your the best!

p.s Your leg rig is amazing but I can imagine its quite tricky to animate and keep track of all the control bones, or not- I don't really know enough about these complex bone rigs yet, and your results speak for themselves- I just know I would probably get into a right old tangle!
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Your leg rig is amazing but I can imagine its quite tricky to animate and keep track of all the control bones
You have no idea... ;)

Actually it is good and bad at the same time. With out the "external" controls I would constantly be selecting the wrong bones.

My latest version of the rig in progress has more bones now for the body and some are right on top of each other... so I HAVE to use external controls with constraints.

One of the tricks I have to use is to increase the "scale" of the constraints so I don't have to move the bones as far. Smaller movements means the control bones stay in a tighter unit. If I use a 1 to 1 control system the control bones get spaced out all over the place. ;)

The body part is working out pretty good.

But yes... the controls can get a bit confusing, but the more I use the easier it gets because I remember where the bones are. I wish to god AS had the ability to assign colors to bones... maybe I can script that. ;)

Ultimately no matter how messy the controls get it is still a dream to animate with! I am loving it!

-vern
donnie
Posts: 111
Joined: Mon Oct 16, 2006 11:53 pm

Post by donnie »

Ah, of course, increasing the Scale of the Constraints works much better for keeping them bones closer together-nice.

I agree it would be great to assign different colours to bones- Also even just giving the notes different colours would be good, and I can't tell you how much assigning layers different colours would help my workflow.
Some of my files have literally hundereds of layers and it would be nice to be able to 'group' layers with different colours according to what they are.

Hmmm, maybe another 'Feature Request' post is in order....

Man, I cant wait to see some tests of a fully rigged Larry in action, he looks fantastic! I am eager to see how you join your amazing 3d Head to his body and then these new legs/arms, and see him come alive! Wow.... exciting times ahead!
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

I feel a bit foolish.

Apparently the following code:

Code: Select all

IKAngleSolver(boneID, target, iterMultiplier=1)
Works for forcing a bone to point to a specific location. I made the stupid assumption that this code only worked when using the manipulate bone tool or when a bone was locked. I always ignored it.

BUT... it works fine with any type of bone and just translating the target. It also allows moving the "aimed" bone completely eliminating the need for most of the code in my aimer script.

Holy crap... oh well. This could used to simplify the script. I plan to play around with it. It is very cool.

-vern
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

Please share all the information you research! (like always you do, by the way)
It seems an interesting discovery.
-G
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Phew!

False alarm!!!

Yes it does work... but at a terrible price!!! It is slower than molasses in January (Genete this phrase means it is VERY VERY SLOW ;) ).

Apparently the IK solver uses up a lot more resources to calculate the new position of the aimer bone then what I'm doing with my code.

It takes several seconds for the screen to update using the IK solver.

This would work if it were just a few bones, and possibly bones in a "logical" chain, but with all the bones I'm moving and on every frame... yikes! OUCH!

-vern
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Yeeeeeehhaaaaaaa!!!

Another breakthrough!

I had trouble parenting one aimer bone to another aimer bone. Most of this it turns out is due to the order of the table list I was building! If the bones are created in a strange order then all the bone changes are out of sequence.

Once I reordered the table so the bones are processed in the correct order the whole thing works perfectly!!!!

Now I can create linked chains of bones and the joints don't disconnect!!!!

It will take me a bit to figure out exactly how this will effect the rig but I'm very happy!

-vern
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

That's a good new!
It would simplify the rig a lot!
-G
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Yeehaaaa! Again!

Another breakthrough!

Multiple aimer bones to one target. Turn scaling on and off for each bone during animation....

Have not updated the script yet but will soon. I have to change the instructions. New naming rules for the bones. Instead of aimer and target needing the same name the aimer is a sub list of bones. Works great!

-vern
Genete
Posts: 3483
Joined: Tue Oct 17, 2006 3:27 pm
Location: España / Spain

Post by Genete »

Please don't remove the previous working versions of the script. Maybe someone would like the first script more than the last one. Please make versions.

I wait your script anxiously.
-G
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

False alarm.

All my high hopes were dashed. My results were not "real". I am still getting bizarre looping feedback with aimer bones parented to aimer bones.

See the problem is that the looping is always changing the bones location and orientation.

When an aimer bone is a child of another aimer bone the parent is an aimer so that bone's fMovedMatrix is applied to the child aimer bone's offset.. but the parent is also an aimer so IT'S orientation is changed etc etc... this constantly feeds back and causes the bones to continuously change.

I just can't figure out a solution.

The current script works fine as long as you don't make an aimer a child of an aimer. I can't prevent some joint setups from "splitting" though.

I can still add multiple aimer bones for one target bone which is pretty cool.

-vern
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

This is weird and it may be a bug in AS and not in my code.

If I parent an aimer bone to another aimer bone it works fine... but only for the mesh controlled by the bones. The mesh moves and distorts correctly based on what I expect the bones to be doing.

However, the display for the bones on the screen is crazy. They wiggle around and aren't lined up with the mesh. If I pan or zoom the screen the bones fly all around and scale to different sizes even though the mesh never moves. It is like the mesh "knows" that the bones should be doing something else and just do what is correct.

If I turn OFF bone scaling in the script none of this happens. It has to do with whatever I'm using to calculate the vectors (distance and direction from the tip of the aim bone to the target bone) for the scaling compounded over several aimer bones that are in a parent child relationship... but... it's the same numbers I use for calculating the rotation which works great... so I'm at a loss.

This is what gave me false hope earlier. I forgot to turn scaling back on and thought that it was working. Once scaling is turned back on the display goes wacky.

It is probably just too much going on. The parent bone's scale is being adjusted on one loop of the script which moves the child bone which is also having the scale adjusted... or visa versa... all of these interrelated adjustments are causing some kind of bizarre feedback... and yet the script works as long as you ignore what the bones are doing on the screen.

-vern
User avatar
heyvern
Posts: 7035
Joined: Fri Sep 02, 2005 4:49 am

Post by heyvern »

Back to the drawing board!

The aimer script works fine as it is, but I realize it could be capable of so much more.

The mistake I've made is that the chains of bones for limbs need to be identified as chains. I can't just apply the motion willy nilly to any bone with the correct name. I need to identify which bone is at the top of a chain and which is at the bottom. I have to determine how each bone in the chain effects bones all the way down the chain. Once order is achieved everything should work as expected.

When working on Genete's 3D bone/point script I found a ton of useful Flash/Actionscript code that was simple enough to convert to lua. I have found a ton of free resources for this type of "IK" chains in Actionscript and will try to convert it to lua for use with AS.

-vern
Post Reply