Dear Vern,
I still looking for a way to perform limbs with this scripted 3D mesh. I tried the example I posted in the previous post (with beta0) in the formula and it don't work as spected.
If you look again to my 3D hand thread there are 2 versions of it. One that is completely rigged in the same bone layer and other with a bone layer for each finger.
With the currect script we have here (version 5) we can rig a bunch of 3D points relative to an origin. This origin can be also a bone as I have shown with the giraffe. Also we can morph the points that are rigged to the same origin in the way that its coordinates are different but they all move as a solid rigged when the masters bones rotates (alpha and beta).
What I want is that the masters bones moves a group of points in space (lets call them joints) and other group of points move in the space in a relative way to those joint points. With the current script it is not possible. I've been thinking a lot about how to do it and I think I have some solution. This evening I'll show you a pseudocode to perform that task and let me what do you think.
Meanwhile I let you work in the select bone tool. Hope you can solve those strange messages.
Best from my side.
-G
Genete! Springy bones 3D rotation with one bone.
Moderators: Víctor Paredes, Belgarath, slowtiger
Two issues:
A) Fixing the wrong code in the script.
It probably was my fault but the masters were reversed and its behavior some odd. Please look into the lua file and tell me if you agree with me.
http://www.darthfurby.com/genete/Script ... -fixed.lua
B) Trying to create limbs.
Regarding to limbs I have added some code to the file but not used for the moment. You can delete it. It is very commented an easy to delete. To create limbs I need from you to answer me a question:
Do you agree to have an additional pair of bones that locally control a portion of the mesh?
I have thought to call them bonename.mX and bonename.mY where bonename.pt is the name of the root bone that have attached a portion of the rest of pt bones.
Then for example masterX and masterY rotates a portion of bones (included the bonename.pt in the example) and bonename.mX and bonename.mY rotates other portion of pt bones like if bonename.pt were the center of rotation. Also that portion of pt bones must be linked to bonename.pt to perform the local translation.
As well as there should not be lot of pt bones that acts like center of rotation bones, there wouldn't be a lot of extra pairs of .mX and .mY bones.
If your answer is yes then I have a solution to make limbs and therefore a 3D hand for instance.
Best.
-G
A) Fixing the wrong code in the script.
It probably was my fault but the masters were reversed and its behavior some odd. Please look into the lua file and tell me if you agree with me.
http://www.darthfurby.com/genete/Script ... -fixed.lua
B) Trying to create limbs.
Regarding to limbs I have added some code to the file but not used for the moment. You can delete it. It is very commented an easy to delete. To create limbs I need from you to answer me a question:
Do you agree to have an additional pair of bones that locally control a portion of the mesh?
I have thought to call them bonename.mX and bonename.mY where bonename.pt is the name of the root bone that have attached a portion of the rest of pt bones.
Then for example masterX and masterY rotates a portion of bones (included the bonename.pt in the example) and bonename.mX and bonename.mY rotates other portion of pt bones like if bonename.pt were the center of rotation. Also that portion of pt bones must be linked to bonename.pt to perform the local translation.
As well as there should not be lot of pt bones that acts like center of rotation bones, there wouldn't be a lot of extra pairs of .mX and .mY bones.
If your answer is yes then I have a solution to make limbs and therefore a 3D hand for instance.
Best.
-G
I have no problems with the changes.
Is it possible that I got confused and switched the X and Y bones in the equation? I wouldn't be surprised.
I will play around with the new variables you added and see how it works. As far as I know it looks okay to me... except for a bit of slow performance I have seen when rotating the bones... this might be my system and not related to the script. I should reboot my compute to make sure
I say try out your limb rotation idea with the code you put in. If it doesn't work we can change it.
-vern
Is it possible that I got confused and switched the X and Y bones in the equation? I wouldn't be surprised.
I will play around with the new variables you added and see how it works. As far as I know it looks okay to me... except for a bit of slow performance I have seen when rotating the bones... this might be my system and not related to the script. I should reboot my compute to make sure
I say try out your limb rotation idea with the code you put in. If it doesn't work we can change it.
-vern
If you could post the "new" equation for the mX and mY bones I would love to plug that into the script.
I also may need to see a file with how these bones relate to the pt bones or how addition pt bone children work.
Another thing I need to know is what happens to those new things you added when the parent IS NOT a pt bone?
If we use those new values in an equation they need to have a value or be ignored.
Maybe there are two separate equations depending on if pt.fParent exists. There would be cases where it would and wouldn't be applied in the equation.
Look forward to some more input on the math.
-vern
I also may need to see a file with how these bones relate to the pt bones or how addition pt bone children work.
Another thing I need to know is what happens to those new things you added when the parent IS NOT a pt bone?
If we use those new values in an equation they need to have a value or be ignored.
Maybe there are two separate equations depending on if pt.fParent exists. There would be cases where it would and wouldn't be applied in the equation.
Look forward to some more input on the math.
-vern
You have to forget the alphaParent and betaParent values. As they represent angles of the Rx and Ry helper bones they could not be never "local masters" of the target pt bone. Forget them.
I mean,
if a pt bone have a pt parent it means that the pt parent is a origin of rotation center for those pt points that are its chlidren. So its children should rotate as pt parent is rotated by its masters.
So, there is not new equation, only substitute beta and alpha (from masterY and masterX respectively) with bonename.mX and bonename.mY angle values (if the parent pt bone has a name of "bonename.pt"). Just pick up the values and substitute alpha and beta for those values. The equation don't change.
If you do only that, then a portion of the grid (mesh) is rotated by masterX and masterY and the other portion of the grid (mesh) is traslated by the position of the bonename.pt bone and rotated by its bonename.mX and bonename.mY bone angle values. Same with any other portion of mesh linked to a child pt bone (like the phalanxs of the fingers)
This is the way the 3D hand works. If you rotate the hand the fingers will remain parallel to themselves. You need to rotate every finger individuallt to the desired position. If you rotate a phalanx the upper (child) phalanxs remain parallel to themselves.
But if you have a look to a normal bone chain (yes, the normal bone chains from a flat bone skeleton ...) then of you rotate intermediate bone (rotate not IK manipulate) the child bones rotates also as a solid rigid (because they are locally linked not only in position but also in relative angle). Our 3D rig can have only linked the position becasue the angle is relative to the masters bones and they are stand alone bones.
What happen if we wrap the global angle of a master bone (the super master masterX or masterY or a sub master bonename.mX bonename.mY) instead of the local angle?. I mean, when you read the alpha and beta values from the masters bones with this code
you are reading the local angle if it is a child bone (is linked to other).
So if you can convert the local angle to the global angle and store it to alpha and beta then we can link masters bones like in a traditional skeleton. Then when you rotate a master bone all its children sub-master bones would rotate also and then can send that message to the script and all the sub portions of the mesh would rotate as a solid rigged.
Later if you rotate a child master bone in relation to its parent master bone it will only rotate its portion of the mesh and send all the informatin to the sub linked portions od the mesh.
In this way we can have a very true 3D ekeleton working as it should work.
Phew! What a sermon!
-G
I mean,
if a pt bone have a pt parent it means that the pt parent is a origin of rotation center for those pt points that are its chlidren. So its children should rotate as pt parent is rotated by its masters.
So, there is not new equation, only substitute beta and alpha (from masterY and masterX respectively) with bonename.mX and bonename.mY angle values (if the parent pt bone has a name of "bonename.pt"). Just pick up the values and substitute alpha and beta for those values. The equation don't change.
If you do only that, then a portion of the grid (mesh) is rotated by masterX and masterY and the other portion of the grid (mesh) is traslated by the position of the bonename.pt bone and rotated by its bonename.mX and bonename.mY bone angle values. Same with any other portion of mesh linked to a child pt bone (like the phalanxs of the fingers)
This is the way the 3D hand works. If you rotate the hand the fingers will remain parallel to themselves. You need to rotate every finger individuallt to the desired position. If you rotate a phalanx the upper (child) phalanxs remain parallel to themselves.
But if you have a look to a normal bone chain (yes, the normal bone chains from a flat bone skeleton ...) then of you rotate intermediate bone (rotate not IK manipulate) the child bones rotates also as a solid rigid (because they are locally linked not only in position but also in relative angle). Our 3D rig can have only linked the position becasue the angle is relative to the masters bones and they are stand alone bones.
What happen if we wrap the global angle of a master bone (the super master masterX or masterY or a sub master bonename.mX bonename.mY) instead of the local angle?. I mean, when you read the alpha and beta values from the masters bones with this code
Code: Select all
local alpha = Balpha.fAngle
local beta = Bbeta.fAngle So if you can convert the local angle to the global angle and store it to alpha and beta then we can link masters bones like in a traditional skeleton. Then when you rotate a master bone all its children sub-master bones would rotate also and then can send that message to the script and all the sub portions of the mesh would rotate as a solid rigged.
Later if you rotate a child master bone in relation to its parent master bone it will only rotate its portion of the mesh and send all the informatin to the sub linked portions od the mesh.
In this way we can have a very true 3D ekeleton working as it should work.
Phew! What a sermon!
-G
Woooooohoooo!!
Woooooohoooo!!
Woooooohoooo!!
(again)
Woooooohoooo!!
Woooooohoooo!!
Woooooohoooo!!
Listen
:
Can you draw a side and a front view of a model? Do the model have the same amount of points and they are the same points in one mesh than in other?
Rigging of a model can be automated!!!!!!
I'm sure! You can do it with a menu script or a script tool!!!.
Imagine:
a) Draw a model in the front view
b) Make a copy of the model and pan it far enough to not overlap with the original model (just for make easier the job)
c) Morph the model copy to convert it to a side view. You can do just the opposite start with the side and finish with the front. Do it in another frame than 0 to make it more visual. Test if it works as a 90 degrees turn for your model just playing the animation. WARNING this morph job must maintain the y coordinate of the points. You have to use the original translate points tool and press SHIFT to do that. (a custom tool can be done for that). Only morph by x coordinates of the points. Copy the model at frame bigger than 0 to frame 0. Then you have at frame 0 both models front and side.
As well as the model is a copy of the original THE POINTS ARE THE SAME AND STORED IN THE SAME ORDER AND INTERNAL ID NUMBER (if this is not true my theory don't work. PLEASE LET ME KNOW).
e) Place two bones that are at the rotation center of each model view. They should be any length but angle 0. Root bones. Call them side_center and front_center.
f) Select the points of the front view of the model. Select the front_center bone.
g) Call a script tool / menu that does the following:
Lets call
Xc = the x coordinate of the front_center bone
Yc = the y coordinate of the front_center bone
for each 'q' point in Selected points table
-take the xq and yq coordinate of the 'q' point
-add a root bone placed at xq and yq coordinates. Call it to 'q.pt'. Predefined length and angle 0.
-make q.pt to be a child of front_center bone (it will not change its absolute position, only its relative coordinates)
-Bind the point q to the bone q.pt
-Add a new root bone placed at x=Xc, y=yq, angle 0 and length = xq-Xc. Its length will be negative if xq < Xc. If xq == Xc then don't add it. == means in this case 'similar to" and a small tolerance should be defined.
-Call this new bone q.Rx (he he are you imagining my method?
)
end for
h) Repeat same process with the side view. In this case the selected bone should be the side_center one and the points the ones of the side view.
i) Call other menu ot tool script that do the following:
Lets call
Xc = the x coordinate of the side_center bone
Yc = the y coordinate of the side_center bone
for each 'q' point in Selected points table
-take the xq and yq coordinate of the 'q' point
-add a root bone placed at Xc and Yc coordinates. Call it to 'q.Ry'.
- make its angle and length to be:
angle = math.atan2(xq-Xc, yq-Yc)
length = math.pow((xq-Xc)*(xq-Xc) + (yq-Yc)*(yq-Yc), 0.5)
(If length is less than a given small tolerance then don't add the bone.)
end for
THAT's ALL the model is rigged!!!!!!
I'm happiest than Mike in Mikedog's HappyLand in a sunny day with all his friends around
Woooooohoooo!!
Woooooohoooo!!
Woooooohoooo!!
-G
Woooooohoooo!!
Woooooohoooo!!
(again)
Woooooohoooo!!
Woooooohoooo!!
Woooooohoooo!!
Listen
:Can you draw a side and a front view of a model? Do the model have the same amount of points and they are the same points in one mesh than in other?
Rigging of a model can be automated!!!!!!
I'm sure! You can do it with a menu script or a script tool!!!.
Imagine:
a) Draw a model in the front view
b) Make a copy of the model and pan it far enough to not overlap with the original model (just for make easier the job)
c) Morph the model copy to convert it to a side view. You can do just the opposite start with the side and finish with the front. Do it in another frame than 0 to make it more visual. Test if it works as a 90 degrees turn for your model just playing the animation. WARNING this morph job must maintain the y coordinate of the points. You have to use the original translate points tool and press SHIFT to do that. (a custom tool can be done for that). Only morph by x coordinates of the points. Copy the model at frame bigger than 0 to frame 0. Then you have at frame 0 both models front and side.
As well as the model is a copy of the original THE POINTS ARE THE SAME AND STORED IN THE SAME ORDER AND INTERNAL ID NUMBER (if this is not true my theory don't work. PLEASE LET ME KNOW).
e) Place two bones that are at the rotation center of each model view. They should be any length but angle 0. Root bones. Call them side_center and front_center.
f) Select the points of the front view of the model. Select the front_center bone.
g) Call a script tool / menu that does the following:
Lets call
Xc = the x coordinate of the front_center bone
Yc = the y coordinate of the front_center bone
for each 'q' point in Selected points table
-take the xq and yq coordinate of the 'q' point
-add a root bone placed at xq and yq coordinates. Call it to 'q.pt'. Predefined length and angle 0.
-make q.pt to be a child of front_center bone (it will not change its absolute position, only its relative coordinates)
-Bind the point q to the bone q.pt
-Add a new root bone placed at x=Xc, y=yq, angle 0 and length = xq-Xc. Its length will be negative if xq < Xc. If xq == Xc then don't add it. == means in this case 'similar to" and a small tolerance should be defined.
-Call this new bone q.Rx (he he are you imagining my method?
)end for
h) Repeat same process with the side view. In this case the selected bone should be the side_center one and the points the ones of the side view.
i) Call other menu ot tool script that do the following:
Lets call
Xc = the x coordinate of the side_center bone
Yc = the y coordinate of the side_center bone
for each 'q' point in Selected points table
-take the xq and yq coordinate of the 'q' point
-add a root bone placed at Xc and Yc coordinates. Call it to 'q.Ry'.
- make its angle and length to be:
angle = math.atan2(xq-Xc, yq-Yc)
length = math.pow((xq-Xc)*(xq-Xc) + (yq-Yc)*(yq-Yc), 0.5)
(If length is less than a given small tolerance then don't add the bone.)
end for
THAT's ALL the model is rigged!!!!!!
I'm happiest than Mike in Mikedog's HappyLand in a sunny day with all his friends around
Woooooohoooo!!
Woooooohoooo!!
Woooooohoooo!!
-G
If you copy the layer and only move the points they absolutely will stay exactly the same. this is how switch layer interpolation works.
It might be easier though to just use one mesh layer for the rig. Do the side view on another frame. Get the locations from the point offsets of the 0 frame and the side view frame.
You could use onion skinning to help in the drawing process.
I hope you are up to the challenge. Creating all those bones in a script will be fun. Of course with this type of script performance won't even be an issue. It won't matter if it takes a few minutes to process (I doubt it would unless the mesh is really complex).
p.s. What has happened to Rasheed? I keep thinking he would get a kick out of this. He kind of started the whole thing when he wrote that RotateTrans script.
-vern
It might be easier though to just use one mesh layer for the rig. Do the side view on another frame. Get the locations from the point offsets of the 0 frame and the side view frame.
You could use onion skinning to help in the drawing process.
I hope you are up to the challenge. Creating all those bones in a script will be fun. Of course with this type of script performance won't even be an issue. It won't matter if it takes a few minutes to process (I doubt it would unless the mesh is really complex).
p.s. What has happened to Rasheed? I keep thinking he would get a kick out of this. He kind of started the whole thing when he wrote that RotateTrans script.
-vern
The script for the front view finished.
http://www.darthfurby.com/genete/Script ... _3Drig.lua
The side one should be very easy based in this one.
Please make a test.
When you embed the 3Dgrid script you should add manually the masterX and masterY bones.
It was very fun!
Tomorrow I'll try the side view.
Cheers!
-G
http://www.darthfurby.com/genete/Script ... _3Drig.lua
The side one should be very easy based in this one.
Please make a test.
When you embed the 3Dgrid script you should add manually the masterX and masterY bones.
It was very fun!
Tomorrow I'll try the side view.
Cheers!
-G
If I understand you correctly, the answer is No.Genete wrote:Can you draw a side and a front view of a model? Do the model have the same amount of points and they are the same points in one mesh than in other?
Rigging of a model can be automated!!!!!!
This will NOT work.
You can't simply create a smooth morph from a frontal view to a profile.
Well, you can, but you will be bitterly disappointed by the distorted shapes which appear during the tweens.
You're not providing enough data.
You're not modeling the intermediate 3d surfaces which exist during the head turn.
Human,
Genete doesn't need the side view to be a head turn "morph". The side view is a "guide" to determine the distance of points in 3D space.
All that he needs to know is that the order or ID of the points will be the same as the front. The points only translate horizontally to create the side view.
For instance the nose. Each character could have a long nose, or a short nose. Whatever. The side view would show that distance and the angle from a center reference point. That is the key to creating the "3D" rig.
Once that angle and distance is obtained the bone can be created that describes that point in 3D space.
It is like 3D cad software that creates a 3 dimensional object from a top, side and front views.
You couldn't create 3D turns from those views, but with the right "math" you can.
Once that bone rig is created and say the front view is moved to a 3/4 view, then a morph of those points to the side view could be achieved using an action. This would give a complete front to side turn.
-vern
Genete doesn't need the side view to be a head turn "morph". The side view is a "guide" to determine the distance of points in 3D space.
All that he needs to know is that the order or ID of the points will be the same as the front. The points only translate horizontally to create the side view.
For instance the nose. Each character could have a long nose, or a short nose. Whatever. The side view would show that distance and the angle from a center reference point. That is the key to creating the "3D" rig.
Once that angle and distance is obtained the bone can be created that describes that point in 3D space.
It is like 3D cad software that creates a 3 dimensional object from a top, side and front views.
You couldn't create 3D turns from those views, but with the right "math" you can.
Once that bone rig is created and say the front view is moved to a 3/4 view, then a morph of those points to the side view could be achieved using an action. This would give a complete front to side turn.
-vern
Yeeehaaaaa!!!Genete wrote:The script for the front view finished.
http://www.darthfurby.com/genete/Script ... _3Drig.lua
The side one should be very easy based in this one.
Please make a test.
When you embed the 3Dgrid script you should add manually the masterX and masterY bones.
It was very fun!
Tomorrow I'll try the side view.
Cheers!
-G
I didn't know you could program in lua??? I plan to steal your genius once again. I want to use this concept for modifying the positions of bones in my own rig.
One of the problems are the mouth and eye bones and the amount of effort needed to adjust those for different characters. I could use this "technique" to automatically adjust those bones based on the positions of a user modified mouth position/width or eye bones.
This is WONDERFUL!!!! It took me a few minutes to figure it out but THE DARN THING WORKS!!!
It would take at minimum 30 minutes to an hour to place all those bones even on a SIMPLE mesh.
YEEEEHAAAAAA!!!!
-vern