Vern,
I'm having problems with the amount of bones....
the monitor that I have now only support 1024x768 maximum and my main window is very small. The drop down menu from the select bone tool have now six rows and is filling all the main window. If the amount of bones increases I cannot select them by the drop down menu. It is not a big problem but make more difficult to achieve the target.
Have you got some kind of script that allow select a bone from a scrolled list instead of a full list?.
-G
Genete! Springy bones 3D rotation with one bone.
Moderators: Víctor Paredes, Belgarath, slowtiger
No, I don't.
I was working on that for a copy/paste bones script but ran into troubles and had to stop. I can take another look at it and see if I could make it work just as a bone selection tool.
Would it help if we cut down on the number of bones in some way? Remember that we talked about putting some of the information into the dynamics data. Imagine if you just used a single bone for angle or length info on the Rx bone. That bone is wasted since the angle isn't used. It would be nice if the Rx length could be placed in the dynamics of the Ry bone. That would get rid of at least a third of the bones.
Also maybe try using a LOT fewer bones. I was playing with your file and found using region binding instead of point binding the bones still worked.
Just a thought.
-vern
I was working on that for a copy/paste bones script but ran into troubles and had to stop. I can take another look at it and see if I could make it work just as a bone selection tool.
Would it help if we cut down on the number of bones in some way? Remember that we talked about putting some of the information into the dynamics data. Imagine if you just used a single bone for angle or length info on the Rx bone. That bone is wasted since the angle isn't used. It would be nice if the Rx length could be placed in the dynamics of the Ry bone. That would get rid of at least a third of the bones.
Also maybe try using a LOT fewer bones. I was playing with your file and found using region binding instead of point binding the bones still worked.
Just a thought.
-vern
Yes a lot of bones. But the result is amazing... And you know if I have one point one bone it doesn't matter if it is flexible or region binding. All the points have manual binding to its corresponding bone.
The problem about the store of the Rx value is that to create the model it is very useful to use the front and side views to find the values of the Rx, Ry and alpha0. If we store Rx from the beginning into a variable of RY bone it should be very difficult to create the rig.
Maybe a menu script that store that values once the rig is done. Also a second script can delete the useless bones. And a third script to substitute the embedded one.
If we push it a little more we can eliminate the Ry also (as I said before) storing Rx, Ry and alpha0 into the .pt bone. Valid only for non flexible rigs...
I want to record into actions the different mouth positions to make the model speak in 3D using the lip sync with actions instead of switches. For that I need the helper bones available.
Maybe we can think in a hybrid rig. "If any of the pt stored values Rx, Rx and alpha0 are zero then search for a helper bone if not then make it zero". I don't want to complicate so much the script because if not it would be useless.
Also I have a feature request for the script.
Once the rig is done and no more pt bones are going to be added it could be possible to make an script that write the table of found bones into a file and make it part of the embedded script?. With this we can avoid the loop of searching and organizing the table of helper bones and its corresponding pt. Then the embedded script is just a loop to walk through an existing table to move the pt bones according to the masters and helper bones. I think you cna store the Id of the bones only. It would be very quick for a just created rig.
What do you think?
-G
The problem about the store of the Rx value is that to create the model it is very useful to use the front and side views to find the values of the Rx, Ry and alpha0. If we store Rx from the beginning into a variable of RY bone it should be very difficult to create the rig.
Maybe a menu script that store that values once the rig is done. Also a second script can delete the useless bones. And a third script to substitute the embedded one.
If we push it a little more we can eliminate the Ry also (as I said before) storing Rx, Ry and alpha0 into the .pt bone. Valid only for non flexible rigs...
I want to record into actions the different mouth positions to make the model speak in 3D using the lip sync with actions instead of switches. For that I need the helper bones available.
Maybe we can think in a hybrid rig. "If any of the pt stored values Rx, Rx and alpha0 are zero then search for a helper bone if not then make it zero". I don't want to complicate so much the script because if not it would be useless.
Also I have a feature request for the script.
Once the rig is done and no more pt bones are going to be added it could be possible to make an script that write the table of found bones into a file and make it part of the embedded script?. With this we can avoid the loop of searching and organizing the table of helper bones and its corresponding pt. Then the embedded script is just a loop to walk through an existing table to move the pt bones according to the masters and helper bones. I think you cna store the Id of the bones only. It would be very quick for a just created rig.
What do you think?
-G
Yes but the points inside the region binding are static with the bone. Maybe a combination of what you say and scale the .pt bone and manual move the points could help.Also maybe try using a LOT fewer bones. I was playing with your file and found using region binding instead of point binding the bones still worked.
Example of application of this technique...
http://www.darthfurby.com/genete/Other/ ... rafa12.mov
http://www.darthfurby.com/genete/Other/ ... afa12.anme
You can follow this thread for further progresses...
-G
http://www.darthfurby.com/genete/Other/ ... rafa12.mov
http://www.darthfurby.com/genete/Other/ ... afa12.anme
You can follow this thread for further progresses...
-G
Not if the bone influence is high on all the bones and the points are "shared" between two bones.Yes but the points inside the region binding are static with the bone.
For example you have 2 bones instead of 4 but they aren't in the "exact" spot of the points, they are "in between". The bones influence will pull equally at the same point. the shared influence will create similar motion to having a bone on that exact point.
Do you remember that circular scale rig? 4 bones that had strength overlapping a circle. When one scaled they all scaled and you have uniform scaling of the circle or shape.
What I'm suggesting is you cut down on the bones, place them in between the points and increase the strength.
This is exactly how my original face rig worked. Overlapping bone strength that had blended influence over many points. I also used this with the body rig and deforming the torso on the turn.
This isn't a "perfect" solution but it might be compromise to writing more scripts to deal with a bazillion bones.
At this point the rig looks fantastic but is almost too complex for most people to deal with... especially with all the bones.
I will see what I can do with a scrolling list for bone selection but I'm also going to play with the point bone "sharing" idea.
-------
I have another crazy idea.
It is possible to create a custom tool that draws on the screen. For instance if all of the helper bone data is stored in the point bone dynamics information a special tool could read those values and "draw" a "fake" bone on the screen that would update as the values are changed.
Like when you have rotation limits and you see those red lines indicating max and min rotation.
You would use the special tool and click on a point bone. On the screen would be drawn the locations of Ry Rx. When you modify the values for the point bone's dynamics (which aren't used for that anymore) you would see these fake bones change.
This one is crazy. I haven't even tried using that part of the script interface yet. Fazek was able to do this when testing bezier curve handles.
--------
Yes, this could be a menu script run at the end of the process. The only drawback would be making changes to the rig later. If you did this you would need a backup to make changes. If you already created a bunch of actions then you would lose those. Have to think about this one.Once the rig is done and no more pt bones are going to be added it could be possible to make an script that write the table of found bones into a file and make it part of the embedded script?
-vern
I understand what you said but it is valid only for points aligned in a straight line.Not if the bone influence is high on all the bones and the points are "shared" between two bones.
Remember that in the front view the points loose its Z dimension (given only by its corresponding Ry bone). If the middle point have a Z dimension outside of the straight line between the two extreme points the model will fail. And if the point is in the straight line of the extreme points then it is really useless... unless it holds a shape break line. But usually if you break a shape into two is due that it is not flat (speaking in terms of this thread)
Anyway, can you post an example of that?
I want to see your progresses 
Every revolution starts with a "crazy" idea...It is possible to create a custom tool that draws on the screen. For instance if all of the helper bone data is stored in the point bone dynamics information a special tool could read those values and "draw" a "fake" bone on the screen that would update as the values are changed.
Like when you have rotation limits and you see those red lines indicating max and min rotation.
You would use the special tool and click on a point bone. On the screen would be drawn the locations of Ry Rx. When you modify the values for the point bone's dynamics (which aren't used for that anymore) you would see these fake bones change.
Please if you start something like this don't do all by your self. I have a lot of ideas boiling in my mind...
For example: the "fake drawn bones" can have its origin to the origin layer or the immediate root bone of the .pt bone.
The custom script tool only would draw the "fake bone" for the selected .pt bones. If it is not a pt bone it don't draw nothing. Same than max min angles.
I think it could be done inside the select bone tool. Just add a new drop down menu and insert there the Rx, Ry, and alpha values. In an initial version is not needed that the user can drag the fake bones, just a visual aid. Later if it works dragging can be used.
That was a not so crazy idea Vern. Not so crazy.
You have my support on this.
-G
Oh yes... No dragging of "fake" bones! I couldn't pull that off.That was a not so crazy idea Vern. Not so crazy.
You have my support on this.
this would be data input not dragging a bone.If it works it could eliminate nearly 2/3 of the bones.
On the other matter of sharing points with bones. I just don't see how this would "break".
If you have a bone way out on the tip of the nose and bone at the surface of the face and theoretically they share influence over a point between the two... the x rotation/translation would be half way. The y translation would be half way. It would split the difference?
You are right... I need to prove my theory first.
The proof is in the pudding!
-vern
More MATHS!!!
(Don't be frighten please!)
Please do following for me:
1) Add a new bone called "masterZ". Let's call its controller angle "gamma".
2) Wrap masterZ angle inside the script and store it to gamma.
3) Modify the maths formulas:
x = Rx*cos(beta)*cos(gamma) + Ry*sin(alpha+alpha0)*sin(beta) - Ry*cos(alpha +alpha0)*sin(gamma)
y = Ry*cos(alpha +alpha0)*cos(gamma) + Rx*cos(beta)*sin(gamma)
I'm considering apply also gamma0 coming from the angle of the .Rx bones (useless value for the moment) but first try this and let me what happen...
It is supposed that
alpha = turn
beta = roll
gamma = tilt
in a common language.
(maybe beta = tilt and gamma = roll... perhaps a native English one can help me in that).
If gamma is 0 the formulas are exactly the same than the previous ones.
It wouldn't need more bones (well only one more in total) and can have a new degree freedom (tilt) what in the current rig it was only valid for the front view.
It was a rotation that I couldn't implement only with bones... With your powerful script we can do that and even more...
Apply it to my giraffe (specially useful when beta is different from 0) and tell me the results!!!!!
-G
(Don't be frighten please!)
Please do following for me:
1) Add a new bone called "masterZ". Let's call its controller angle "gamma".
2) Wrap masterZ angle inside the script and store it to gamma.
3) Modify the maths formulas:
x = Rx*cos(beta)*cos(gamma) + Ry*sin(alpha+alpha0)*sin(beta) - Ry*cos(alpha +alpha0)*sin(gamma)
y = Ry*cos(alpha +alpha0)*cos(gamma) + Rx*cos(beta)*sin(gamma)
I'm considering apply also gamma0 coming from the angle of the .Rx bones (useless value for the moment) but first try this and let me what happen...
It is supposed that
alpha = turn
beta = roll
gamma = tilt
in a common language.
(maybe beta = tilt and gamma = roll... perhaps a native English one can help me in that).
If gamma is 0 the formulas are exactly the same than the previous ones.
It wouldn't need more bones (well only one more in total) and can have a new degree freedom (tilt) what in the current rig it was only valid for the front view.
It was a rotation that I couldn't implement only with bones... With your powerful script we can do that and even more...
Apply it to my giraffe (specially useful when beta is different from 0) and tell me the results!!!!!
-G
It's probably less ambiguous to think about this like a boat (this terminology is used in a number of 3D programs too):Genete wrote:alpha = turn
beta = roll
gamma = tilt
in a common language.
(maybe beta = tilt and gamma = roll... perhaps a native English one can help me in that).
Pitch -- boat rotates around X
Yaw -- boat rotates around Y
Roll -- boat rotates around Z
I can't help in other ways, but at least I am a native English speaker!
Hope this helps,
J
You can't have everything. Where would you put it?
That's right! And it is perfect for my proposes!. When a boat yaws its roll and pitch axis follow the local coordinate system of the boat. That's what I wanted to exaplain a lot of times in all the previous bones depelovement! It makes sense!!jahnocli wrote:It's probably less ambiguous to think about this like a boat (this terminology is used in a number of 3D programs too):Genete wrote:alpha = turn
beta = roll
gamma = tilt
in a common language.
(maybe beta = tilt and gamma = roll... perhaps a native English one can help me in that).
Pitch -- boat rotates around X
Yaw -- boat rotates around Y
Roll -- boat rotates around Z
I can't help in other ways, but at least I am a native English speaker!
Hope this helps,
J
We are looking now for a roll movement.
Thanks jahnocli!
-G
Dear Vern. I have modified the lua script to wrap the new master bone and include the math and it don't work. It makes strange deformations. Anyway I will deep investigate what is happening with my maths and if it works I'll let you know. For get it for the moment. Once I reach it I'll post it.
Best wishes with the new select bone tool. We really need it.
-G
Best wishes with the new select bone tool. We really need it.
-G
Hahaha...
I did not remember that a rotation in an axis can be done with a linear combination of two rotation in other two axis. So With the currect model I can roll the model at any position. It is a little difficult because it requires some tricks depending on the yaw of the model.
http://www.darthfurby.com/genete/Other/ ... 12roll.swf
http://www.darthfurby.com/genete/Other/ ... 2roll.anme
See this sample where I show three rolls in the front view, the side view and a 3/4 view.
Also I have added the masterZ bone what is a direct master of the central bone of the model (it is like if the Z rotation were invariant like the Y rotation)
When the model is at the front view just rotate the masterZ to roll.
When the model is a the side view then you have to cross the masterZ and the masterY (-90 and +90 respectively) in an step interpolation mode. Then the masterX now is a roll bone.
When the model is at a 3/4 view you should maintain masterX constant and modify both masterZ and masterY in opposite directions to perform a roll of the model. Depending on the amount of masterX rotation the other two rotate more or less.
I'm happy now!
-G
I did not remember that a rotation in an axis can be done with a linear combination of two rotation in other two axis. So With the currect model I can roll the model at any position. It is a little difficult because it requires some tricks depending on the yaw of the model.
http://www.darthfurby.com/genete/Other/ ... 12roll.swf
http://www.darthfurby.com/genete/Other/ ... 2roll.anme
See this sample where I show three rolls in the front view, the side view and a 3/4 view.
Also I have added the masterZ bone what is a direct master of the central bone of the model (it is like if the Z rotation were invariant like the Y rotation)
When the model is at the front view just rotate the masterZ to roll.
When the model is a the side view then you have to cross the masterZ and the masterY (-90 and +90 respectively) in an step interpolation mode. Then the masterX now is a roll bone.
When the model is at a 3/4 view you should maintain masterX constant and modify both masterZ and masterY in opposite directions to perform a roll of the model. Depending on the amount of masterX rotation the other two rotate more or less.
I'm happy now!
-G
Dear Vern... It seems that I will not let you take a break...
I was thinking about performing the limbs (I mean the 3D hand). Now is the moment to do it. As well as the Rx bones can hold another angle (and if you look to my model the angle of all those bones are 0 even the one that are looking left because they have negative length...) they can hold there a beta0 value. If you do that now, the model would be the same. But what is the difference? the difference is that if you link properly the pt bones you can perform linked rotations (like if they were limbs). Then every bonename.Rx and bonemane.Ry now acts like if they were masters for the bones that are linked to its corresponding .pt. Did you follow me?
I mean:
1) Store in the table also the beta0 value coming from the current angle of each .Rx bone found.
2) When inside the LinkIt function, test if the pt bone is a root bone (have children) or not. If yes then consider the beta0 value in the formula; otherwise make it 0.
To perform this you should change the formulas to:
(I think it is not a very difficult scripting task)
Then if you rotate the corresponding .Rx and .Ry bones you rotate also the all the bones locally linked to it. For sure a linked bone can be also a root bone and so on. That makes a limb.
-------
BTW: what does this piece of code?
Nor "vec" nor "pBone1" are used later...
Best
-G
I was thinking about performing the limbs (I mean the 3D hand). Now is the moment to do it. As well as the Rx bones can hold another angle (and if you look to my model the angle of all those bones are 0 even the one that are looking left because they have negative length...) they can hold there a beta0 value. If you do that now, the model would be the same. But what is the difference? the difference is that if you link properly the pt bones you can perform linked rotations (like if they were limbs). Then every bonename.Rx and bonemane.Ry now acts like if they were masters for the bones that are linked to its corresponding .pt. Did you follow me?
I mean:
1) Store in the table also the beta0 value coming from the current angle of each .Rx bone found.
2) When inside the LinkIt function, test if the pt bone is a root bone (have children) or not. If yes then consider the beta0 value in the formula; otherwise make it 0.
To perform this you should change the formulas to:
Code: Select all
local testX= Rx*math.cos(beta+[u]beta0[/u]) + Ry*math.sin(alpha + alpha0)*math.sin(beta+[u]beta0[/u])
local testY= Ry*math.cos(alpha+alpha0)
Then if you rotate the corresponding .Rx and .Ry bones you rotate also the all the bones locally linked to it. For sure a linked bone can be also a root bone and so on. That makes a limb.
-------
BTW: what does this piece of code?
Code: Select all
if (skel:Bone(pt.fParent)) then
local pBone1 = skel:Bone(pt.fParent)
pBone1.fMovedMatrix:Transform(vec)
endBest
-G
It's probably some left over code. I pulled some of this from the flipper script and needed to apply the parent bone offsets and forgot to delete it.
Actually... I thought it was doing something... now that you pointed out that the vec value isn't being used I can take it out.
I will work on those other changes later... I need to take a little break from my marathon select bone tool creation. That thing worked better than I expected. I might be able to get that bone copy/paste script working.
About modifying the code and getting "weird" transformations... it all depends on when in the script you modify a bones value. I did that a few times. I was changing the translation of a bone before I had applied a calculation to the same variable.
This caused the bone to appear offset from the mesh. It looks very strange. You just have to make sure that if you change any values that are applied to a bones translation or rotation that you do all the calculations first than apply the value to the bone.
-vern
Actually... I thought it was doing something... now that you pointed out that the vec value isn't being used I can take it out.
I will work on those other changes later... I need to take a little break from my marathon select bone tool creation. That thing worked better than I expected. I might be able to get that bone copy/paste script working.
About modifying the code and getting "weird" transformations... it all depends on when in the script you modify a bones value. I did that a few times. I was changing the translation of a bone before I had applied a calculation to the same variable.
This caused the bone to appear offset from the mesh. It looks very strange. You just have to make sure that if you change any values that are applied to a bones translation or rotation that you do all the calculations first than apply the value to the bone.
-vern