I will try to put something together for a tutorial.
I think I can put together a simple head with poseable mouth like my original character rig and still use this setup.
I was thinking about this recently. If I don't bind ALL the points of the mouth/lips to a bone, just enough to distort the general shape for "perspective", I can use my mouth posing rig to do lip sync.
I should also look into using this with bones on a switch layer possibly. That might be tricky though. Maybe using "point offset"...
HEY! This would WORK!
... Bones on a switch that are bound to the same points for all the layers of a switch! Instead of creating a bone for each point, the script would just create bones for one layer in the switch and then bind all the other corresponding points in each layer to the same bones!!!!!!!
Holy cow!
I do this all the time! You can have bones that control points but the bones don't have to be anywhere near the points they control. This would allow the same perspective motion of the mouth using layers in a switch for lip sync.
I have to try this. Yeehaa!
-vern
Genete! Springy bones 3D rotation with one bone.
Moderators: Víctor Paredes, Belgarath, slowtiger
That's I was saying all the time!!!... Bones on a switch that are bound to the same points for all the layers of a switch! Instead of creating a bone for each point, the script would just create bones for one layer in the switch and then bind all the other corresponding points in each layer to the same bones!!!!!!!
I said it before!!!!
I'm glad you realized it! I have mentione it is some posts I think!Cheers!
-G
EDIT: If you look to the Elsa The giraffe" post I used the "sort shape inside a swithc layer" thecnique to performa a 360º ear turn of the giraffe. The only difference is that I used point motion instead of point by bone motion.
Before invent the automatic shape order script I planeed to sort the shapes inside a switch layer like the ear turn. Now is not needed to the 3D stuff but is valid for rest of animation concepts.
Yeah! switch layers are great!
I tried to do that and the deformed (turned) mouth by point motion don't follow the flat bone motion...Extract from Genete's Elsa the giraffe post... wrote:If you look carefully to the anme file you will find some interesting things.
In the switch layer there are three bones. I puted there thinking that they will have influence to the ear as well as the points pass thru them. Let say that I wanted to draw a 0, 90 and 180 bones position. My surprise was that the points respond to the bones as they (the points) were in the original position (the 0 degree position). For example the left bone scale would enlarge or shrink the ear when the ear points are at position 0. But when the points are at position 180 degrees, the influence of the bone over them is the same!. It enlarges the ear when the bones enlarge!! I have to confirm that this night. If this happen in this way it would be a bery important discover! Imagine that you rig a mouth to talk only with bone motion. Later you distorts the mouth with point motion and the mouth still talking the same but distorted by point motion. It would be a god gift!!! I have to confirm it.
I have been researching the way to distort the bone rig itself to move the bones to a 3D position and move the points to the new 3D position and continue making its work. To achieve that I compromised the point motion feature to be null and let the bones to do all the job (for example the 3D eye or the 3D hand). Now if I confirm what I have mentioned before, I can have only springy mechanisms to do the global turning and the fine turning can be done with point motion without loosing the ability of the bones of have a "flat" rig influence over "deformed mesh of points by point motion".
Heyvern! please maintain us informed if you really make it work!
Best
-Genete
Yes, point motion AFTER frame 0 "offsets" the points but the bone works the same.
The key to this is the bone and the points position on frame 0 must not change. I usually did this with region binding.
Point/bone binding is different.... but the same.
For instance with point binding you could bind a point to a bone that is anywhere on the layer. The point will move based on the location of the bone no matter where it is.
My thought was to bind the SAME POINTS in all the switch layers to the same bones. I would only need to bind one switch layer first than either do the others "by hand" or maybe this could be scripted?
I have done my first test with a mouth shape and the auto rigging scripts and it works. I just need to finish binding the points of all the other switch layers.
--------
I think I will cheat. this has worked in the past...
... I could create "temporary" rigs for each switch layer using the auto rigging system.
AS doesn't care what bones in what layer the points are bound to as long as the "ID" is the same. Since all of those layers have the exact same number of bones I should be able to just drag the switch layers into one switch layer after rigging them and the binding will still be there. Then I can just delete the extra bone rigs. This has happened before "by accident" and I thought it was pretty cool.
Each point of each switch will still be bound to the correct bone but the bones in the "final" switch layer will be "offset".
I would put the whole thing in one big switch layer. Including the head. I don't see a way of having a sub switch layer with bones that would work with the script at this point. Maybe it could by binding the MasterTR bone to the layer? I would have to use bone slave/master set up and I just don't want to. Maybe the next version we can figure it out.
I apologize if I didn't catch on to what you said about this before. There are so many cool things to try I may not be paying 100% attention to everything.
-vern
The key to this is the bone and the points position on frame 0 must not change. I usually did this with region binding.
Point/bone binding is different.... but the same.
For instance with point binding you could bind a point to a bone that is anywhere on the layer. The point will move based on the location of the bone no matter where it is.
My thought was to bind the SAME POINTS in all the switch layers to the same bones. I would only need to bind one switch layer first than either do the others "by hand" or maybe this could be scripted?
I have done my first test with a mouth shape and the auto rigging scripts and it works. I just need to finish binding the points of all the other switch layers.
--------
I think I will cheat. this has worked in the past...
... I could create "temporary" rigs for each switch layer using the auto rigging system.
AS doesn't care what bones in what layer the points are bound to as long as the "ID" is the same. Since all of those layers have the exact same number of bones I should be able to just drag the switch layers into one switch layer after rigging them and the binding will still be there. Then I can just delete the extra bone rigs. This has happened before "by accident" and I thought it was pretty cool.
Each point of each switch will still be bound to the correct bone but the bones in the "final" switch layer will be "offset".
I would put the whole thing in one big switch layer. Including the head. I don't see a way of having a sub switch layer with bones that would work with the script at this point. Maybe it could by binding the MasterTR bone to the layer? I would have to use bone slave/master set up and I just don't want to. Maybe the next version we can figure it out.
I apologize if I didn't catch on to what you said about this before. There are so many cool things to try I may not be paying 100% attention to everything.
-vern
Well... I gave a try. It didn't work as well as I hoped.
http://www.lowrestv.com/moho_stuff/shap ... witch3.mov
First off my mistakes.
I did the head completely wrong that's why it gets "squished". I didn't add enough cross sections to maintain the shape.
Creating this was... hard. I plan to do the whole thing over again from scratch so I can do it correctly. I had a heck of a time keeping the switch layers "the same" so they interpolated. That was my mistake not the scripts. I made the mouth separate from the head but then realized I couldn't use that in a switch... so I had to paste the head back into the switch layers. What a mess.
Creating the switch layer bone binding worked exactly as I predicted. I only did 3 of them to test but basically I kept redoing just the "front" bone script to each layer and then dragged it into the switch layer with the final bone rig. Point binding stayed intact.
Issues with the scripts:
I couldn't use the shape ordering script. The lip sync layers use custom shape ordering for the teeth and lips to create the phonemes. The shape ordering switch really messed that up.
I couldn't use the shape connected around the mouth that is part of the head to hide the teeth and tongue because on the turn the lips... disappear. Need to come up with a different solution.
The bigger issue is the way the bones rotate based on the original shape of the mouth. On some of the shapes this causes the lips to protrude in a wierd way because that is where the mouth shape was when I did the side view. Since each switch layer would have a different side view it doesn't work so well. Don't know how to fix that.
I still think this may have some promise. Next I will try the original mouth rig from my character rig. That should work better since there is no predefined point locations. I have high hopes for that.
Will post the moho file when I get it kind of cleaned up.
-vern
http://www.lowrestv.com/moho_stuff/shap ... witch3.mov
First off my mistakes.
I did the head completely wrong that's why it gets "squished". I didn't add enough cross sections to maintain the shape.
Creating this was... hard.
I plan to do the whole thing over again from scratch so I can do it correctly. I had a heck of a time keeping the switch layers "the same" so they interpolated. That was my mistake not the scripts. I made the mouth separate from the head but then realized I couldn't use that in a switch... so I had to paste the head back into the switch layers. What a mess.Creating the switch layer bone binding worked exactly as I predicted. I only did 3 of them to test but basically I kept redoing just the "front" bone script to each layer and then dragged it into the switch layer with the final bone rig. Point binding stayed intact.
Issues with the scripts:
I couldn't use the shape ordering script. The lip sync layers use custom shape ordering for the teeth and lips to create the phonemes. The shape ordering switch really messed that up.
I couldn't use the shape connected around the mouth that is part of the head to hide the teeth and tongue because on the turn the lips... disappear.
Need to come up with a different solution.The bigger issue is the way the bones rotate based on the original shape of the mouth. On some of the shapes this causes the lips to protrude in a wierd way because that is where the mouth shape was when I did the side view. Since each switch layer would have a different side view it doesn't work so well. Don't know how to fix that.
I still think this may have some promise. Next I will try the original mouth rig from my character rig. That should work better since there is no predefined point locations. I have high hopes for that.
Will post the moho file when I get it kind of cleaned up.
-vern
Yes but only if you translate the bone. Not if rotate or scale the bone.Yes, point motion AFTER frame 0 "offsets" the points but the bone works the same.
Why don't duplicate the layer and is automatically and exactly the same points binded?My thought was to bind the SAME POINTS in all the switch layers to the same bones. I would only need to bind one switch layer first than either do the others "by hand" or maybe this could be scripted?
It could be called a "repository of vector layers 3D rigged to a predefined skeleton... not?AS doesn't care what bones in what layer the points are bound to as long as the "ID" is the same. Since all of those layers have the exact same number of bones I should be able to just drag the switch layers into one switch layer after rigging them and the binding will still be there. Then I can just delete the extra bone rigs. This has happened before "by accident" and I thought it was pretty cool.
Deep thoughts for the TODO list...
It can be done also within a single layer and using the limb concept I have described before. Then you don't need to rotate the limb individually. It would rotate as its parent. If you want to preform a individual rotation of the limb you can do it just moving its corresponding .mX and .mY bones (a limb can be an eye, an ear, a mouth...). all in one layer.I would put the whole thing in one big switch layer. Including the head. I don't see a way of having a sub switch layer with bones that would work with the script at this point. Maybe it could by binding the MasterTR bone to the layer? I would have to use bone slave/master set up and I just don't want to. Maybe the next version we can figure it out
And remember that you can always bind a layer (bone, group or what you want) to a bone inside a bone layer. If the bone move in 3D the layer itself would move if it were in 3D (as a group). This slave layer can be also a "3D" rigged layer (switch or bone) what can hold a different masterX and masterY.
I apologize if I didn't catch on to what you said about this before. There are so many cool things to try I may not be paying 100% attention to everything.
Come on! I was just kidding!
Regarding to the mouth sample:
Is that mouth rigged with the automatic 3D script and rotated with the 3Dgrid script?
Yes it is a problem. Same "front/side" skeleton for different front/side vector layers would produce strange deformations to the non original vector layers.The bigger issue is the way the bones rotate based on the original shape of the mouth. On some of the shapes this causes the lips to protrude in a weird way because that is where the mouth shape was when I did the side view. Since each switch layer would have a different side view it doesn't work so well. Don't know how to fix that.
In my opinion the best work flow with this crazy 3D rig and its corresponding automatic shape sort is this:
0) draw and rig your 3D skeleton. I mean. Draw the "no render" lines that define the union of the central points of each limb. For example in that horrible picture I've done with my wacom graphire 3 you can see the main skeleton. The cyan lines would not be rendered.
1) Draw front and side views of your model. You can do it in separate parts. to avoid mixing. Same layer but separated positions. You can place all together later.
2) Rig each separated part of your model. Don't worry about if they are controlled by the master or the m.X/Y bones. Just rig the points and create the virtual skeleton of every limb (nose, ears, head surface, mouth and eyes... hair also). Only take account to use the original pt points of the virtual skeleton (the cyan lines) to be the center bones of the individual meshes. You can separate the central pt bone apart and later rescue it with the offset tool.
3) Once rigged each separated part of the face. Add .mX and .mY bones to the ones that need it (eyes and mouth in a normal human face
). 4) Now comes the funny part. add the shapes. Add shapes to the individual portions of the face and also to the connecting areas that connect them together (remember to not add any point here!. If you plan your model properly all the points would be added at the beginning.
5) The most important and the cool thing. Use actions. Use actions for phonemes, expressions, eye blinks, "muscles" movements... Whatever you want!. Actions would work with bones and with points if needed. But points motion the less possible distance from the bone.
With this you would avoid all the problems in one shot, because you can use the lip sync by actions from Ramón and the rest of work could be done with bone motion and manual point motion (not actions) for every needed situation to fix gaps errors and so on.
Anyway let me know if the researching you're doing is successful.
Best
-G
Yes it is. Worked really well. I'm looking forward to trying it out on my original character rig.Regarding to the mouth sample:
Is that mouth rigged with the automatic 3D script and rotated with the 3Dgrid script?
Actually I don't really want to use switch layers myself. I think the rig should eliminate the need for switch layers. I did this because I know a lot of people like switches and they do have a lot of uses.
I like the idea of using actions for lip sync and facial expressions. I already do that with my original rig.
I was thinking the same thing about using "limb" rigging for the mouth. Treat the mouth like an arm!
You could animate it like an extra limb by using sub bones from the main skeleton.
This script system keeps getting more and more interesting as I play with it. There is a lot of potential. I could write a book about all the uses for it.
I am still struggling a bit with the 3D perspective... but I am determined to do it. I think it needs to be an option at least.
There is another thing I discovered, but I think you mentioned this a long time ago... you can't really rotate around the "z" axis. I did discover a workaround, you can rotate the "center" bone... the parent of the point bones. You rotate that bone in combination with masterX and masterY and it works perfectly.
I just linked the rotation of my MasterTR bone to that.
-vern
I have released a new version of 3dgrid, and ge_3Drig_front and ge_3Drig_side.
I have to create a more practical example.
Main changes:
Values Rx, Ry and alpha0 have changed the way they are calculated from bones.
Previous:
alpha0= current angle of bone .Ry of the point.
Ry = length of bone .Ry
Rx = length of bone .Rx (even negative)
Now:
alpha0 = atan2 (.Ry.fPos.y, .Ry.fPos.x) Is the angle of the bone .Ry related to its parent.
Ry = .Ry.fPos:Mag() the distance of its position in relation of its parent
Rx = .Rx.fPos.x the x coordinate of the bone in relation to its parent.
Now all the bones .Rx and .Ry are parented. .Rx and .pt parented to central bone in front view and .Ry to its corresponding central bone in the side view.
Benefits:
1) Front and side views are more clear. Bones are smaller.
2) In the side view you can morph the Ry bones placing them in other place and you are morphing directly Y and Z coordinates. Alpha0 is calculated. No more use of two tools (angle and length) to morph your model. Only position (less keyframes to control)
3) .Rx bones can be easily re-parented and moved away with no problem.
4) Creation of limbs is now easier. Now the central bone don't need to be a root bone. So you can rig partially a mesh and continue adding limbs without modifying nothing of your previous rig.
5) Side view can be used for reference for the deformed mesh during the time line. It only need to be set to "Don't render".
Tomorrow with more time I'll post the samples and the new code lines.
No I have to go to bed...
-G
I have to create a more practical example.
Main changes:
Values Rx, Ry and alpha0 have changed the way they are calculated from bones.
Previous:
alpha0= current angle of bone .Ry of the point.
Ry = length of bone .Ry
Rx = length of bone .Rx (even negative)
Now:
alpha0 = atan2 (.Ry.fPos.y, .Ry.fPos.x) Is the angle of the bone .Ry related to its parent.
Ry = .Ry.fPos:Mag() the distance of its position in relation of its parent
Rx = .Rx.fPos.x the x coordinate of the bone in relation to its parent.
Now all the bones .Rx and .Ry are parented. .Rx and .pt parented to central bone in front view and .Ry to its corresponding central bone in the side view.
Benefits:
1) Front and side views are more clear. Bones are smaller.
2) In the side view you can morph the Ry bones placing them in other place and you are morphing directly Y and Z coordinates. Alpha0 is calculated. No more use of two tools (angle and length) to morph your model. Only position (less keyframes to control)
3) .Rx bones can be easily re-parented and moved away with no problem.
4) Creation of limbs is now easier. Now the central bone don't need to be a root bone. So you can rig partially a mesh and continue adding limbs without modifying nothing of your previous rig.
5) Side view can be used for reference for the deformed mesh during the time line. It only need to be set to "Don't render".
Tomorrow with more time I'll post the samples and the new code lines.
No I have to go to bed...
-G
Yeehaaa!
I like those improvements. Anything to clear up the interface. Those side view bones were kind of... annoying. Like when your windshield of your car is dirty and the washer doesn't work.
Genete, you mentioned the possibility of not having the bones over the mesh at all. That theoretically they could be anywhere on the screen. Is this still possible?
-vern
I like those improvements. Anything to clear up the interface. Those side view bones were kind of... annoying. Like when your windshield of your car is dirty and the washer doesn't work.
Genete, you mentioned the possibility of not having the bones over the mesh at all. That theoretically they could be anywhere on the screen. Is this still possible?
-vern
Yes it is possible since the movements are only translations. But if you do it you loose:heyvern wrote:Yeehaaa!
I like those improvements. Anything to clear up the interface. Those side view bones were kind of... annoying. Like when your windshield of your car is dirty and the washer doesn't work.
Genete, you mentioned the possibility of not having the bones over the mesh at all. That theoretically they could be anywhere on the screen. Is this still possible?
-vern
1) The feed back on what pt bone correspond to what point
2) The ability to rotate the central bone (the one what perform the Z rotation and you just have commented in two previous post)
With this new version you have a clean interface and can directly morph your model in terms of (x,y,z) values and nor X by Rx lenght, Y and Z (by alpha), and Y and Z (by Ry length).
Hav a look to the "pepino.anme" file and look carefully how the Rx and Ry bones change its dimensions and angles (in case of Ry) to perform the last deformation of the head of the cucumber. Erase the keyframes and try to do it by your self.... Not so easy. Ry variables affect at the same time to Z and to Y. As well as you cannot morph the Ry bone as it were at the frame 0 (lenght and angle at the same time), you need to use scale and length alternatively (use two tools). It is a pain. Now you just use one tool: Translate bone. More simple and less keyframes.
Let me have a clean script and a interesting example and I'll post it.
Cheers!
-G
Genete!
I figured out how to hide bones!
It is a "cheat" actually that I discovered by accident.
This only happened in Moho. efrontier fixed this problem with AS so it doesn't happen anymore but I think the underlying "flaw" still exists.
If you assign a constraint to a bone and use the menu "Hide constrained bones" all bones with a constraint will be "invisible".
I was hoping this was done using lua somehow so I could hide any bone but this is not possible. I have given that up.
The trick is to create a constraint on a bone and use a bone ID for the target bone that doesn't exist!
In moho I was able to do this through a complicated procedure of parenting bones and deleting multiple bones. No need to explain it since you can't do it anymore in AS.
The result was a blank constraint target in the constraint window for the bone. The menu item is "blank" since it targets a bone ID that doesn't exist.
And the most important part is that the constraint doesn't work! The constraint is sort of still there but the target doesn't exist so the constraint doesn't do anything. The bone is hidden when the hide constrained bones menu is activated but it functions normally through script control.
So, my thought would be to create a "false" bone ID and add that ID as a constraint to any bone you don't want to see. This "false" bone ID would be defined after all the other bones are created so it could be a number HIGHER than what actually exists.
I plan to create a script or some kind of tool to do this and see how it works.
It is a perfect solution when you think about it. Hiding constrained bones works for constrained bones, no problem. It is only hiding bones WITHOUT a constraint that can't be done... so... "wasting" the constraint that does nothing is not a problem since you aren't using it anyway.
This could be a special tool or menu for the script to hide or show all the point bones, or the Rx only or Ry only bones!
See what I mean? Let's say you want to edit the limb parent bones but there is a lot of "clutter". You could easily hide ALL bones except the ones you want to see.
I could easily check to make sure that if a constraint exists it targets a "real" bone that exists before doing anything else. To turn a bone "back on" just check if the constraint target is a "real" bone before deleting the constraint.
-vern
I figured out how to hide bones!
It is a "cheat" actually that I discovered by accident.
This only happened in Moho. efrontier fixed this problem with AS so it doesn't happen anymore but I think the underlying "flaw" still exists.
If you assign a constraint to a bone and use the menu "Hide constrained bones" all bones with a constraint will be "invisible".
I was hoping this was done using lua somehow so I could hide any bone but this is not possible. I have given that up.
The trick is to create a constraint on a bone and use a bone ID for the target bone that doesn't exist!
In moho I was able to do this through a complicated procedure of parenting bones and deleting multiple bones. No need to explain it since you can't do it anymore in AS.
The result was a blank constraint target in the constraint window for the bone. The menu item is "blank" since it targets a bone ID that doesn't exist.
And the most important part is that the constraint doesn't work! The constraint is sort of still there but the target doesn't exist so the constraint doesn't do anything. The bone is hidden when the hide constrained bones menu is activated but it functions normally through script control.
So, my thought would be to create a "false" bone ID and add that ID as a constraint to any bone you don't want to see. This "false" bone ID would be defined after all the other bones are created so it could be a number HIGHER than what actually exists.
I plan to create a script or some kind of tool to do this and see how it works.
It is a perfect solution when you think about it. Hiding constrained bones works for constrained bones, no problem. It is only hiding bones WITHOUT a constraint that can't be done... so... "wasting" the constraint that does nothing is not a problem since you aren't using it anyway.
This could be a special tool or menu for the script to hide or show all the point bones, or the Rx only or Ry only bones!
See what I mean? Let's say you want to edit the limb parent bones but there is a lot of "clutter". You could easily hide ALL bones except the ones you want to see.
I could easily check to make sure that if a constraint exists it targets a "real" bone that exists before doing anything else. To turn a bone "back on" just check if the constraint target is a "real" bone before deleting the constraint.
-vern
The problem comes if you create the a bone with the wasted boneID. For example you can constraint the scale of a bone to a bone with a ID = 9999 it (the constrained bone) would be hidden during the animation. I think I wouldn't create a bone with an ID of 9999... with my current computer not... So the top value of the integer number (65535?) would be enough. (BTW, how any bones can you create in an AS file? would AS crash? ... Hehe...It is a perfect solution when you think about it. Hiding constrained bones works for constrained bones, no problem. It is only hiding bones WITHOUT a constraint that can't be done... so... "wasting" the constraint that does nothing is not a problem since you aren't using it anyway.
...Cool...
It could be very easy create a custom button that "hide" selected bones and another to "show all" or show hidden or show selected. Very easy.
That idea rocks!!, please post it in another thread to don't let the trick hidden here. Maybe in a separated post under Scripting area and/or Tips and Tricks.
If you don't do the scripts I'll do it. It will be VERY simple and very useful.
Great mind is yours Vern!
(And yes... you have a reputation that need to maintain...
)This weekend more interesting things. Keep connected!!.
Cheers!
-G
You only have to create a false bone with an ID that is +1 of the total bone count... or actually you can use "nil" as the constraint target. I think that is why the menu is blank.
When I get further along I will start a new thread. This may not work if they "fixed" AS too well. It would be a shame to ask for a bug to be put back in.
-vern
When I get further along I will start a new thread. This may not work if they "fixed" AS too well. It would be a shame to ask for a bug to be put back in.
-vern
Oh boy...
Genete you are going to hate me now.
As my knowledge of 3D transformation matrices has increased... so have my thoughts about the efficiency of the current code.
What I keep finding is that even for very simple perspective just as we have it, using transformation matrices is the way to go. It may be faster and just better programming.
The added benefit of course would be having a more flexible way to do perspective scaling and field of view.
All the "code" and math I'm finding to do this starts at the "beginning". It includes the point translations we already have in place. It is all based on using points in 2D space of a 2D application and making them look 3D... exactly as we've done.
Most of the samples stop short of doing the perspective scaling but I found a few that include that portion. However, it is almost like reinventing the wheel because of how I "hard coded" the 3D translations. They don't fit into the more efficient concept of using matrix transformations. And since AS HAS the ability to do matrix transformations built in it might make sense to use it.
I am thinking I should start another "version" of the 3Dgrid script unrelated to what you are doing. I am sure if I come up with something better I can apply it to anything new you come up with.
I think also a lot of the repetitious calculations and looping could be streamlined by moving them out into function calls. Also instead of doing all the sin cosine math stuff on every point we could do it "once" for each point parent bone. We only really have one center of rotation around a single point for most of the bones in each case. We can calculate the math ahead of time for the parent of many point bones, then use that value to calculate the new x y position.
We are calling that math stuff over and over on every single bone. It probably is wasting a lot of computer cycles. At least that is what other experts are saying.
Don't stop what you are doing! I am getting very familiar now with this stuff and should be able to rework it later.
-----------
Good lord my BRAIN IS GOING TO EXPLODE! I feel like I'm in school! Algebra, calculus, trigonometry... I had no idea how cool that stuff is.
I had to delete a bunch of Giligan's Island reruns from my brain to make room for all of this new knowledge. But I will NOT delete any Charlie's Angels episodes.
-vern
Genete you are going to hate me now.
As my knowledge of 3D transformation matrices has increased... so have my thoughts about the efficiency of the current code.
What I keep finding is that even for very simple perspective just as we have it, using transformation matrices is the way to go. It may be faster and just better programming.
The added benefit of course would be having a more flexible way to do perspective scaling and field of view.
All the "code" and math I'm finding to do this starts at the "beginning". It includes the point translations we already have in place. It is all based on using points in 2D space of a 2D application and making them look 3D... exactly as we've done.
Most of the samples stop short of doing the perspective scaling but I found a few that include that portion. However, it is almost like reinventing the wheel because of how I "hard coded" the 3D translations. They don't fit into the more efficient concept of using matrix transformations. And since AS HAS the ability to do matrix transformations built in it might make sense to use it.
I am thinking I should start another "version" of the 3Dgrid script unrelated to what you are doing. I am sure if I come up with something better I can apply it to anything new you come up with.
I think also a lot of the repetitious calculations and looping could be streamlined by moving them out into function calls. Also instead of doing all the sin cosine math stuff on every point we could do it "once" for each point parent bone. We only really have one center of rotation around a single point for most of the bones in each case. We can calculate the math ahead of time for the parent of many point bones, then use that value to calculate the new x y position.
We are calling that math stuff over and over on every single bone. It probably is wasting a lot of computer cycles. At least that is what other experts are saying.
Don't stop what you are doing! I am getting very familiar now with this stuff and should be able to rework it later.
-----------
Good lord my BRAIN IS GOING TO EXPLODE! I feel like I'm in school! Algebra, calculus, trigonometry... I had no idea how cool that stuff is.
I had to delete a bunch of Giligan's Island reruns from my brain to make room for all of this new knowledge. But I will NOT delete any Charlie's Angels episodes.
-vern
You're absolutely right. sin and cos of beta and alpha don't need to be calculated for every point!
That's what I mean when said you those things about professional programmers...
Don't worry about my brain... I'll continue purifying the current scripts that almost work! Once I have a script that do the work completely well done then will apply those improvements. It is easy to do.
And every new idea is always welcome!!
And good choice... Charlie's Angels must be always present.
-G
That's what I mean when said you those things about professional programmers...
Don't worry about my brain... I'll continue purifying the current scripts that almost work! Once I have a script that do the work completely well done then will apply those improvements. It is easy to do.
And every new idea is always welcome!!
And good choice... Charlie's Angels must be always present.
-G