Genete! Springy bones 3D rotation with one bone.

[heyvern]

Here will be the link to the latest version of the script:

http://www.lowrestv.com/moho_stuff/3Dgrid5.lua

You should also download the latest AS file that Genete is working on later in this thread.

________________________________________

Instructions
The bones are named as "sets" with the same bone name in front of a two letter extension where indicated:

Bones marked with * must exist in the file for the script to work.

(These 2 bones are not part of a set. They control all the sets of bones. No extension required.)
MasterY -- master Y rotation (alpha) *
This is the bone that controls the Y rotation

MasterX -- master X rotation (beta) *
This is the bone that controls the X rotation

Create multiple sets of bones by using a different name for each set.
(Rx and Ry are optional for each "set" but you must have at least one or the other. When either is missing the rotation "offset" defaults to 0 for that axis.)

bonename.Rx
This bone's length determines the distance of the "point" bone from the center of the front view. For example, the sides of a nose or the corners of a mouth.

boneame.Ry
This bone's length and rotation determine the "point" bone's location in 3D space from the side view. For example, the distance from the "center" of rotation to the tip of the nose or the chin.

bonename.pt *
This bone represents a 3D point in space.

________________________________________

And here children is how this story began...

Once upon a time...

(the picture gets all wiggly and fades to Vern typing on the keyboard. He has been drinking a lot of coffee and it is either very late at night... or very early in the morning... depending on your point of view.)

~~~~~~~~~~~~~~~~

Genete,

I came up with a cool idea with some simple scripting. I need to pull the concept out of another script but here's the basic idea.

Remember when you were doing those full head and full body rotations with your springy bones? You needed a lot of individual springs at different locations and sizes to create the 3D rotation for each point in the 3D space.

One of the reasons I leaned away from this was the complexity of positioning all of the bones and the number of bones needed.

What I've done with scripting using that math lesson you gave me, is the possibility of creating multiple points of 3D space based on just a few bones.

Based on this:

X=X0+L*sin(alpha)

With L being a variable that could be changed dynamically for each point in the 3D space. There could be as many or as few spots as needed based on the number of bones. Completely flexible.

By creating a table in the script of a whole set of points each bone could be named to move in that spot. All of it driven by ONE BONE'S ROTATION. You wouldn't need all of those spring bones. This would be calculated in the script automatically. X and Y translation would be handled separately for each bone.

It could be based on the number of bones and some kind of user setting on a bone to determine the distance from a central point.

The trouble I have is figuring out the math to create the 3D "grid".

If this could be done with a script... it would be simple to set up a 3D space and bind points to bones, or whatever, even region binding would work. Add in the layer flipping and it's even cooler.

Let me know what you think.

So far my test script works FANTASTIC! I linked the L variable in the formula to the scale of a bone so I can change it on the fly. I did this for testing purposes. In actual use this should work very smoothly. At least as well as doing it with constraints.

Maybe this could be the way to customize the 3D... by just changing the scale or length of a small set of bones to define the points in space.

This might be the full side to side turn solution we've all been looking for.

-vern

[Genete]

See the answer in the other thread. Now I have to go.
Be patient.
I understand you perfectly. But it is not so simple. We have to discuss some things before we attack the X and Y rotations together.
Bye!

[Genete]

Let me know what you think.

That's what I think:

1) Simple Springy mechanisms and double Springy mechanisms can be substituted by an script that have all the math inside.

2) The substitution of the springy mechanisms by the "mathy" script only saves the amount of bones. For a single axis rotation the amount of bones is 4 for each point (2 for the script) and for a double axis rotation the amount of bones is 15 (at last) for each point (only three for your future script!!!). But the script doesn't save you on creating the mesh.

3) My two axis rotation emulation is a mixture of maths and fake. It don't follow the canonical spherical coordinate system. It is due to the artifacts I needed to use due to the limitation of the mechanic tools I have (2D bones). In fact, in a pure spherical coordinate system (two angles and a radius), every projected coordinates (X and Y) of a point in 3D space is a function of the two angles (lets say alpha and beta) and the radius of rotation. In my fake system the variables are two radius and a angle. Also that fake rotation is exactly what we need for head rotation because the X rotation of a human head also rotates when rotates by the Y axis so it is the more similar copy of rotation of a human head.

4) I want to develop with you the math formulation and the method to achieve the 3D mesh.

5) It is not as simple as "do the same with the Y axis as done with the X axis". They are linked together. So Y rotation have influence into X rotation and vice versa. The full formulation for the 3D fake I did with the springy and double springy (see the 3D eye) is:

X= Rx*cos(beta) + Ry*sin(alpha + alpha0)*sin(beta)
Y= Ry*cos(alpha+alpha0)

Where
alpha and beta: are the two controlling angle of the two masters bones.
alpha 0: initial (frame 0 or 1) angle of rotation for a particular point. It is a parameter that defines the point in the mesh (different for every point in the mesh)
Rx: Rotation radius for the Y axis rotation. (Yes it is Y axis; it is not a mistake...). It is a parameter that defines the point in the mesh.
Ry: The rotation radius around the X axis (called simply R in the other formula). This is a parameter that defines the point in the mesh.

6) I need to have your agreement in nomenclature. It is getting more complicated every time we introduce more variables and it could be very confusing if we don't define the nomenclature: please agree or refuse this:

Mesh: A amount of points that represents a 3D surface. Usually the mesh is done with the points of shapes that share common outlines.

Master X: the master bone that defines the whole mesh rotation around the X axis. Its length is not important. At frame 0 (1) its angle must be 0 degrees (zero). When it increases its angle value modify accordingly the alpha value. Its name can be ####.X

Master Y: the master bone that defines the whole mesh rotation around the Y axis. Its length is not important. At frame 0 (1) its angle must be -90 degrees (or 270). When it increases its angle value modify accordingly the beta value. I have choose -90 to distinguish from the other master bone and to emulate as if we were looking the bone from the top view. Anyway it is not important. Its name can be ####.Y. in this case #### is the same as for the other master. For example we can call it NOSE.X and NOSE.Y

Target bone: To use in the script it should have a name to easily let the user create the bones for the mesh. Anyway you can have it without name and use its Id (what is unique). It can be done easily if you modify the select bone tool to show in a text box the ID for the current selected bone. Te use of this bone is initially create a binding region (or flexible) that move one (or more) points of the mesh. As well as the target bone is moved (translated) as an slave by the masters ones and the script it will drag the point(s) with him. Scale and rotation can be used for further mesh deformation. But that is other story. About his name: It can be called accordingly to its masters for example we can call it $$$$.#### where #### is the name of its couple of masters. Example: left.NOSE, right.NOSE and so on.

There is a pair of bones what we need to store the others values that define the mesh. Rx, Ry and alpha0. As well as they are associated to the target bone I propose to you name them in this way:

$$$$.Rx and $$$$.Ry and store the math values of Rx and Ry at:
Rx=the current length of the bone called $$$$.Rx
alpha0=the current angle of the bone called $$$$.Rx
Ry= the current length of the bone called $$$$.Ry

We have to put a generic name to refer to that type of bones. Please make me a proposal. (helper bone?)

7) Create a mesh is a complex issue. First you have to create the mesh thinking on:
a) having as less points as possible.
b) the points should achieve a good side profile. When you turn the points the curvature is playing a bad role in this mesh due the curvature of every point is not prepared to achieve a side view but a front view.
c) Don't try to rig ALL the points of the mesh. It would create a very mechanical turn. Although you have the ability of morph every single point of the mesh during the rotation, it could have some limitations. For example you have to change the scale, angle and scale of the "helper" bones to perform a 2D movement what easily can be achieved by point motion. It is more clever use a combination of 3D mesh and point motion (remember Greykid words: "as less bones as possible")

8.) I want to develop with you a method to create the mesh from scratch. But for that I need the script already done to make a video of a demo.

9) I have a very interesting proposal: If you don't plan to morph dynamically the mesh in animation (for example a build) you can store the Rx, Ry, and alpha 0 at the internal values of the bone dynamic (torque, dump and spring). With this you save more bones and you will have only "one point , one bone". It can be done after creating the mesh with the standard method we are developing and once done store those values into the bones and delete the non functional ones. Just be sure that the check box for bone dynamic is off.

What's your opinion about this long post?

-G

[heyvern]

What's your opinion about this long post?

It sounds... cooool!

I am going to respond to a few things with this post and will come back and respond to other things as I go along.

What I need to do is create ONE set of bones controlling ONE point for testing purposes. Then once I get that working I can expand it.

These formulas a cool as heck! They are like Legos. I can understand them when I see them but I don't have the knowledge to create them.

The key for me to make this work is that I understand what needs to be done to each point based on all the variables. Then I create a table grid of bones with all of the values and run it through a function.

You give me the math and I can make it do all the work.

I am going to implement your suggestions for nomenclature as my starting point. If along the way I find I need to change anything I will let you know. This happened with my "combo" flipper script and the flip layer script. As I went along it became clear that naming bones in a certain way made it easier and more flexible.

(Keep in mind we could use multiple suffixes to define a bone. Like "BoneName.left.a.b.c". This might be a way to store additional information. I could just create the list of bones from sub strings of the name.)

Master X: the master bone that defines the whole mesh rotation around the X axis.

Master Y: the master bone that defines the whole mesh rotation around the Y axis.

These would be "invisible". I plan to link their control to one translation bone. I am thinking I can "hide" bones using the script during animation. I have to see if that will work. All of the tools in AS are built with the same scripting I am using so I should have the ability to do this.

you can store the Rx, Ry, and alpha 0 at the internal values of the bone dynamic (torque, dump and spring). With this you save more bones and you will have only "one point , one bone"...

I LOVE that idea!!! Use properties that are wasted anyway in most cases. No one should put dynamics on ANY of these bones as far as I'm concerned.

Here's one for you that might be implemented later... it's kind of scary.

I could create a special tool specifically for this rig. Those values could be added to the value storage bones using the existing tools without a problem, but...

I could copy and edit pieces of existing tools and make a NEW one that does the exact same thing but the values would have different labels that we define!!!

So when setting up the bones for the rig you select the "2.5D Rig Tool". Instead of listing values for "Torque, Spring, Damping" or "length, angle" it would list "Rx, Ry, Alpha" or whatever we call them. You could set all those bone values with one tool!!! That would save time.

I will save that idea for later after the thing is working.

I have a big project to finish up before the end of the month but will try to work on this over the weekend. My goal is to get your formulas plugged into a simple simple prototype script to move one set of bone/points. If I can get one bone/point to move in 3D space that is half the battle.

-vern

[heyvern]

Just in case this might be helpful here is a list of all the math functions available in lua:

http://lua-users.org/wiki/MathLibraryTutorial

I have no idea if any of these will help us... I don't have a clue honestly. There seems to be some interesting things in there involving angles and tangents which might help us.

I do know that lua is used a lot in 3D type games.

-vern

[Genete]

These (Master X and Master Y) would be "invisible". I plan to link their control to one translation bone

It is OK but I think best is to concentrate first into achieve the 3D movement of a bone and later hide all the controls by other custom scripts.

I could create a special tool specifically for this rig. Those values could be added to the value storage bones using the existing tools without a problem, but...

I could copy and edit pieces of existing tools and make a NEW one that does the exact same thing but the values would have different labels that we define!!!

So when setting up the bones for the rig you select the "2.5D Rig Tool". Instead of listing values for "Torque, Spring, Damping" or "length, angle" it would list "Rx, Ry, Alpha" or whatever we call them. You could set all those bone values with one tool!!! That would save time.

Woaauu. It sounds very well!. Take notes for further depelovment. It could be a non trivial task.

If I can get one bone/point to move in 3D space that is half the battle.

Thats what I did in all those experiments that so few people understood long time ago (spring, elliptical rotation, variable length rotation). All of them finally conducted me to the 3D hand and all the 3D stuff you already know.

From my side you have all the encouragement possible to achieve that initial script. Once done please let me play with it and try to show you how to create the mesh.

Cheer up!

[heyvern]

Genete,

Can you help me out a little bit with this? I am having a bit of trouble determining which bones do what. I sort of have it but not quite. It isn't behaving in the way I expect it to.

Here is my very simple request:

Create a very simple AS file with one set of bones to control one point. This would be an "imaginary" file. Pretend my script exists as you imagine it and create the bones as you think they should work. Name them so I know what values for each bone get used according to your suggestion.

Create the "helper" bones, the "Master.x" and "Master.y" bones, the "Target" bone. Stuff like that. And let me know which value of which bone should be placed in the formula.

I am thinking something like your original eyeball file with one point to start with. Imagine one point in that file using the script that works with out any of those spring bones.

The file doesn't need a mesh. It doesn't need to "do" anything. I just want to make sure I am targeting the correct bones in the script.

The problem I'm having is that I don't quite understand which bones are scaled and rotated dynamically using the X Y master bones and the math to create a proper 3D simulation.

One area that always confuses me is the values that define the points location in the 3D mesh. This would be the value that comes from viewing the "object" from the "imaginary" top and front views.

I may be setting up my AS file incorrectly. It would be best for me if you set up the bones according to how you think it would work.

This would be a HUGE help. I am so close but I think my "trial and error" approach isn't helping.

-vern

[Genete]

I have trying to setup some bones to do the 3D rotation form the point of view of a FRONT (or current target) and at the same time the SIDE and the TOP views.
I' have only achieved the side one. The top one involves double springy bones for each single springy bone in the front view and I have not achieved it yet. I'm doing it "by eye" but have to get aid from the hard maths.

This was only to make you an example of 3D turning. If I achieve it I will show you.

----------

On the other hand I have a further step with springy (please don't try to understand it) that I showed you in other post.
I have renamed the bones accordingly to the name convention.

http://darthfurby.com/genete/Scripting/RxRyAlpha.anme

If you play with the file you can see that you can:

1) Rotate alpha0 (from the helper bone named "helper (Rx and alpha0)")
2) Scale Rx (from the helper bone named "helper (Rx and alpha0)")
3) Scale Ry (from the helper bone named "helper (Rx)")

That's the behavior you should achieve with the script.

At frame 1 play with alpha0 Rx and Ry. Later at other frames play with master X and master Y to perform the rotation maintaining the other values quiet. As it were a solid rigged point. If you want to morph the point position meanwhile you are rotating it with the masters bones you can do it easily just touching the helper bones.

Hope it helps you.
Best

-G

[heyvern]

This file works just like what I did previously. So I know my script works.

What confuses me is that the rotations don't appear "spherical" at all.

When ever I rotate the master bones the translation is the same "radius". The contolled bone always travels the same distance.

In the eyeball file the points/bones followed the surface of the sphere. I may be mistaken buy that is what I thought we were trying to achieve.

At least I know I got it correct after all.

-vern

[Genete]

Yes the rig is not like spherical because as I have explained several times the X rotation axis rotates with the model when you rotate the model by the Y axis.

Anyway if you look to the 3D eye it moves the points sphericaly becasue they are in the surface of an sphere but not for the rig. In fact due to the rig the rotation of the 3D eye is strange: An Y rotation always produce a straight line in projection and a X rotation produces an ellipse (circle or line depending on the Y rotation value).

It was done in that way because It was the only way I found to achieve this stuff only with bones!!!
Maybe using the script it can be possible to achieve an spherical rig but I think will be very similar.

You can check out here the spherical coordinate system to understand what I'm talking about.

Can you then post the script to play with it?

Best
Genete

[heyvern]

Yes I will post the script later tonight now that I know it works properly. My script does exactly what the rig you just posted does but with out most of the bones.

I am intrigued by the spherical rotation... the connection of the Y and X rotations.

I will look at that wikipedia article to see if I can figure it out on my own. If you have any ideas (another "magic" formula? ) I would appreciate it.

I ABSOLUTELY CAN DO THIS WITH A SCRIPT!

If the relationship between X and Y is a based on math it can be automated in a script... I guarantee this. The fact that the eyeball works proves this can be done.

-vern

[Genete]

Please check out this file:
http://darthfurby.com/genete/3DrigTutor ... -view.anme

That's the file I mentioned in a previous post in this thread where I have placed a visual aid to understand how the point moves in the 3D space.

The green lines divides the views. The top view is obtained looking the model from the far high sky (bird eye view). The side view is obtained looking the model from far away positive X axis.

Hope it helps to understand the behavior of this semi - spheric rig.

Look to the top view and you can see that a rotation in X axis always produces a straight line (the direction depends on Y rotation but in top projection is always a straight line. In the front and side views the X rotation produces a ellipse (circle or line depending on Y rotation).
In the top view Y rotation always produces a circle (parallel to the XZ plane) and same rotation produces a straight line on side and front projections. The circle is bigger or smaller depending on X rotation.

I think that my rig is definitively the same as a spherical rig. The main difference is that I have split the the rotation radius R into Rx and Ry. but when managing the angles of the master bones you obtain the same behavior than an spherical rig. It is only different from the point of view of creating the initial values. In a spherical rig you should have R, alpha0 and beta0 ad with my model you have Rx, Ry and alpha0 as the variables that defines a point in the 3D space.

-G

[heyvern]

Genete,

Here's a zip file with the script.

http://www.lowrestv.com/moho_stuff/RxRy ... ripted.zip

I based it on the RxRyAlpha.anme file you created. I did make a lot of changes and highlighted some bones.

The bones are named as "sets" with the same bone name in front of a two letter extension as follows:

(These 2 bones are not part of a set. They control all the sets of bones)
MasterY -- master Y rotation alpha
MasterX -- master X rotation beta

Create multiple sets of bones by using a different name for each set.

bonename.Rx -- the Rx bone
boneame.Ry -- this is also alpha0

bonename.pt -- the controlled "point" bone

I probably got this completely wrong. I have two sets of bones in the file as an example. You could add as many as you want. However all the sets are controlled by the same "MasterX" and "MasterY" bones... is this correct? Or should each set have it's own Y and X masters? That is easy to change. I just make the X and Y masters part of the same set. Would require more bones.

Also I can not figure out yet how to have the center of rotation any place but the center point of the layer!

All the translations are based on 0. So the "point bone" always goes to the center of the AS document. It also starts at what ever point the length * scale is of the Rx/alpha0 bone.

I just can't figure out the math to "offset" the bones center rotation. I can offset the translation but then it just changes the amount of rotation around the center of the document.

I think this has to do with using the absolute values of the angles of the bones. I just need to figure out a way to modify them so the center of rotation can be based on a different point in the AS document.

I should add the offset value? This would just compound the rotation from the center point... <sigh>

I'll figure it out eventually. This is important because you could actually have eyeballs that rotate on a different pivot point on a face. The parent of the eyeballs could be linked to one of the "head" control bones.

You could check my math in the script if you feel brave. I commented the code a little.

p.s. I still have no clue how to link the X and Y rotations to do that "eyeball" trick. I was going to do some "trial and error" to reduce and increase the amount of translation of the X rotation based on some value of the Y. It would be a complete shot in the dark for me though.

-vern

[Genete]

However all the sets are controlled by the same "MasterX" and "MasterY" bones... is this correct?

Yes and not. Yes if the model would be a complete rig (for example a humnan nose)and Not if the model have moving parts. Then there would be as pair of masters bones as limbs or moving parts are in the rig. Remember the 3D hand? I have a couple of masters per finger/phalanx. Well, really in the 3D hand I had one masterY for each finger and several masterX for each phalanx.

Also I can not figure out yet how to have the center of rotation any place but the center point of the layer!

The center of rotation depends on the bone position in the front projection and its initial values (angle and the two radius). You can have perfectly rigged all the points (correct individual initial Rx, Ry and alpha0) but if the bone is not in the correct position in relation to the others at frame 1 then they rotate as they have different rotation center.
But, why don't you refer all the "bonename.pt" bones to a central one? I mean link them using the link tool to a central bone that you position in the origin of the rotation and then that origin bone could be moved and all the rig moves with it!!! Use relative coordinates not absolutes. It is possible within the script?. Using springy bones is quite easy because I link all the chains (the begining of one with the end of other to rig a bone in relation to another bone. In this way if the central bone moves (due to a rotation for example) all the rig that is linked to it also moves. That's the way I made the fingers in the 3D hand.
Let me think about it and redefine the fomulation.

I can offset the translation but then it just changes the amount of rotation around the center of the document.

Let me review the script and see what can I do.

I'll figure it out eventually. This is important because you could actually have eyeballs that rotate on a different pivot point on a face. The parent of the eyeballs could be linked to one of the "head" control bones.

That's the clue! rig with relative corrdinates not absolutes. Later make the center of rotation bone part of another complex rig.

For example: a rig of a head could be done with:
1) A mesh for the head surface
2) A point for the nose.
3) One point per eye.
4) One point for the mouth
5) One point per ear

Also every single part of the head can have its own rig.
1) One for each eye mesh.
2) One for the nose mesh
3) One for the mouth mesh. Maybe one for each lip.
and so on.


The big problem will come when you try to make a shape order meanwhile the head is turning. You cannot make it automatic... For instance in a mesh that represent the head surface ... how many shapes yould you have? When should be each shape be z translated? Now you have two rotations... not so simple as flipby bones...

Don't loose time making it by eye! you can get lost when have more than three points. Better lets make a very robust rig with a single point (understanding its behavior) and then add more points (but one each time...)

I'll review the file this night.
Cheers!

[Genete]

(Imitating you)
Woooohooooo!!!
You did it!

http://www.darthfurby.com/genete/Script ... inked.anme

Look that file!
I have added a link between "points bones" And works like a charm!!
You can define your own rotation center! just link the bones, link the bones link the bones... link the bones!!!!!!!!!!!!!

The white circle is the rotation center What is not at the center of the layer!!! You move it and you obtain a movement of the other two points also!!!!!

heyvern! We have to consolidate this. I want to show you more ideas (include the beta0 also for the helper bones). With that you can use four variables to define a point in space (instead of three) what can be a little confusing but have to study it carefully.
Also I want to show you some ideas about modeling or mesh starting with a already front and side view of the model.
Can you draw for me a front view and a side view of a simple face, define its rotation center and let me make the rig??? Please, please, please, please, please, please, please, please, please, please, .....
Now I have to go to the dentist...

Bye!