I want bones that:
A) INCLUDE MATH FUNCTIONS INSIDE CONSTRAINTS
I think it could not be so difficult because similar things are already done in current ASP/Moho kernel. For instance Bone dynamics use math functions. The only thing to take care about is to have the possible math singularities (div by 0 for instance) wraped so if they happen could be managed by an internal exception system.
Math formulas inside bone constrints would be a VERY PRODUCTIVE FEATURE.
It could cover:
1) Typical math functions:+,-, *, /, abs(), sin(), cos(), tan(),sroot(), exp(), etc, and its combinations.
2) Arguments could be any of other bones variables in any of other layer: X, Y, angle, length.
B) BONES THAT HAVE INFLUENCE TO POINTS INSIDE VECTOR LAYERS OF INNER GROUP FOLDERS.
It would simplify masking issues.and the use of lock and unlock bones to achieve a walk cycle. The target is that every bone have a strength for each inner vector layer that it has. So at the end you can have the same than today giving a value of zero to the strength for certain layers.
C) BONES THAT CAN BE REPARENTED IN THE TIMELINE.
Similar to lock / unlock bone but relative to his parent. It would simplify a lot the situation where a character is giving one thing to anothe one. This feature conbined with the previous one will work very well.
D) BONES CAN HAVE TWO PARENTS.
It could represent a big mess with the non linear equation system but it would complement feature A) because with this it is possible make mechanisms.
Perhaps some of this features would be never done but I'm interested to know your opinion about them. I think some of them are extremly needed.
Thanks.
Next Bones generation
Moderators: Víctor Paredes, Belgarath, slowtiger
Genete! I think you are doing a lot of interesting and useful developing, the problem with me is that I don't understand your feature request, I can't see the connections with the requests and what it will accomplish in the end...lol, but I do believe you know what you're doing so I support it in hope that it will lead to a better program![/i]
Thankyou jahnocli. Your words encourages me!jahnocli wrote:Genete, I read your post elsewhere about nobody replying, so I thought I'd cast my vote in favour of your feature requests, and congratulate you on some great work. You and heyvern really are extending this program -- well done!
J
Thankyou ulrik for your words. It very simple. With those features request (specially the first one) you can do 2,5D heyvern's rig or my pseudo 3D rig with much less bones and much more effectivity.ulrik wrote:Genete! I think you are doing a lot of interesting and useful developing, the problem with me is that I don't understand your feature request, I can't see the connections with the requests and what it will accomplish in the end...lol, but I do believe you know what you're doing so I support it in hope that it will lead to a better program![/i]
Thankyou for your support for this feature request!!!
Best, Genete
The only problem I see are with C and D.
Option C:
I don't think there is a need for changing a bones parent or if it would even be possible. The nature of bones requires a singular parent. In my mind option C would be handled with an UNPARENTED bone and two translation constraints whose values could be keyed.
If a bones constraint values could be CHANGED over time you would not need to change the parent, just change the constraints value. An object would be constrained to two bones but the values would be "opposite" or balanced between 0 and 1.
During the animation this key could "switched". Changing the objects "Constraint Parent" by reversing the values (0,1 - 1,0). This could be done automatically or not I suppose. You can have numbers higher than 1.
Option D - one bone with two parents:
Once again I think this could be handled better with constraints. The hierarchical concept of bones is extremely simple. I don't think you could have that same simple system with two parents as an option. It would be easier to add functionality to the existing bone constraints... in my opinion.
One bone with two parents would be the same as above, two constraints on one bone. two constraints at 50% each. I already use this technique in my rig, but I have to use multiple bones. If I could add say, 2 constraints of the same type for each bone, or 3. Then I could cut down the number of bones by 60% in most areas! I could have one bone for every 3 that I have now. 250 bones down to less than a 100... (don't check my math please)
--------------------------------
On items A and B... those kick some major arse. I love those ideas. ESPECIALLY B! That would be fantastic. No need for multiple bone layers UNLESS YOU WANT THEM. Easier channel key frame changes. No switching layers to change key frames.
Of course this would add to screen "clutter" which I plan to solve with a very tiny small feature request in another post.
-vern
Option C:
I don't think there is a need for changing a bones parent or if it would even be possible. The nature of bones requires a singular parent. In my mind option C would be handled with an UNPARENTED bone and two translation constraints whose values could be keyed.
If a bones constraint values could be CHANGED over time you would not need to change the parent, just change the constraints value. An object would be constrained to two bones but the values would be "opposite" or balanced between 0 and 1.
During the animation this key could "switched". Changing the objects "Constraint Parent" by reversing the values (0,1 - 1,0). This could be done automatically or not I suppose. You can have numbers higher than 1.
Option D - one bone with two parents:
Once again I think this could be handled better with constraints. The hierarchical concept of bones is extremely simple. I don't think you could have that same simple system with two parents as an option. It would be easier to add functionality to the existing bone constraints... in my opinion.
One bone with two parents would be the same as above, two constraints on one bone. two constraints at 50% each. I already use this technique in my rig, but I have to use multiple bones. If I could add say, 2 constraints of the same type for each bone, or 3. Then I could cut down the number of bones by 60% in most areas! I could have one bone for every 3 that I have now. 250 bones down to less than a 100... (don't check my math please)
--------------------------------
On items A and B... those kick some major arse. I love those ideas. ESPECIALLY B! That would be fantastic. No need for multiple bone layers UNLESS YOU WANT THEM. Easier channel key frame changes. No switching layers to change key frames.
Of course this would add to screen "clutter" which I plan to solve with a very tiny small feature request in another post.
-vern
-
CartoonM!ke
- Posts: 110
- Joined: Mon Apr 17, 2006 4:54 pm
- Location: Walnut Creek, CA, USA
- Contact:
Genete,
Your bones suggestions are great, I would only add:
A) If math formulas are included, The formulas can be built from "pieces" from drop-down menus or buttons, like in Xcel or Filemaker -- this would make it better for us non-math peeps to use. Better yet, the "math" could be invisible to users and named for what they do to the bones, that is, orient like, aim at, offset from, etc... each would require a bone to do the operation to and what it is reference to (another bone, a "floor" coordinate for walk cycles, a range of degrees, etc).
B) YES! Even if it means creation of new folder types: like a Mask Bone Folder or some such thing. I think the thing is to keep things as simple as possible for us artist-types.
D) One use of this kind of constraint is that it could enable a bone rig to change what layer it's on or it's Z depth. For instance, if I want a two characters to Hug, I could have the parent bones of the Arms go either in front of or in back of the other character. This would eliminate a lot of work in Masking and creating duplicate bone/vector layer rigging that such a action would require now. While not being "3-D" in the classic sense, this kind of ability would enable the animator some ability to give depth to characters and a kind of realism.
And maybe this will be how the Rig Vern's working on will eventually be able to be used, but it would be so cool if I create a new character and have specific vector/image layers with body parts on them and then apply a "Make Rig" button that would attach the bones to the layers and create a basic Skeleton that I can then just come in and tweak to meet the specifics of the character. I don't know how this could be done, but it would really speed things up as right now there's a lot of grunt-work in making a rig that could be automated.
Your bones suggestions are great, I would only add:
A) If math formulas are included, The formulas can be built from "pieces" from drop-down menus or buttons, like in Xcel or Filemaker -- this would make it better for us non-math peeps to use. Better yet, the "math" could be invisible to users and named for what they do to the bones, that is, orient like, aim at, offset from, etc... each would require a bone to do the operation to and what it is reference to (another bone, a "floor" coordinate for walk cycles, a range of degrees, etc).
B) YES! Even if it means creation of new folder types: like a Mask Bone Folder or some such thing. I think the thing is to keep things as simple as possible for us artist-types.
D) One use of this kind of constraint is that it could enable a bone rig to change what layer it's on or it's Z depth. For instance, if I want a two characters to Hug, I could have the parent bones of the Arms go either in front of or in back of the other character. This would eliminate a lot of work in Masking and creating duplicate bone/vector layer rigging that such a action would require now. While not being "3-D" in the classic sense, this kind of ability would enable the animator some ability to give depth to characters and a kind of realism.
And maybe this will be how the Rig Vern's working on will eventually be able to be used, but it would be so cool if I create a new character and have specific vector/image layers with body parts on them and then apply a "Make Rig" button that would attach the bones to the layers and create a basic Skeleton that I can then just come in and tweak to meet the specifics of the character. I don't know how this could be done, but it would really speed things up as right now there's a lot of grunt-work in making a rig that could be automated.
Totally agree. Even it is neccesary to avoid people make bad expressions.CartoonM!ke wrote: A) If math formulas are included, The formulas can be built from "pieces" from drop-down menus or buttons, like in Xcel or Filemaker -- this would make it better for us non-math peeps to use. Better yet, the "math" could be invisible to users and named for what they do to the bones, that is, orient like, aim at, offset from, etc... each would require a bone to do the operation to and what it is reference to (another bone, a "floor" coordinate for walk cycles, a range of degrees, etc).
heyvern wrote:Option C:
I don't think there is a need for changing a bones parent or if it would even be possible. The nature of bones requires a singular parent. In my mind option C would be handled with an UNPARENTED bone and two translation constraints whose values could be keyed.
If a bones constraint values could be CHANGED over time you would not need to change the parent, just change the constraints value. An object would be constrained to two bones but the values would be "opposite" or balanced between 0 and 1.
During the animation this key could "switched". Changing the objects "Constraint Parent" by reversing the values (0,1 - 1,0). This could be done automatically or not I suppose. You can have numbers higher than 1.
Yes you are right. C and D request are really inside A request. I think A request should be the fines one to cover all our desired features for bones.
Thak your your support.
Genete
for messed up animators
My dilemma. I animated a walk cycle- then added some more bones for more flexibility. My character's legs were rotated 90 degrees or so and a couple inches away from his body.
Some kind of tool or script that would let you add bones after animating actions without affecting former bone movement.
Some kind of tool or script that would let you add bones after animating actions without affecting former bone movement.
Re: for messed up animators
We are working on that but in a general way. Look to those threadsAlanPS wrote:My dilemma. I animated a walk cycle- then added some more bones for more flexibility. My character's legs were rotated 90 degrees or so and a couple inches away from his body.
Some kind of tool or script that would let you add bones after animating actions without affecting former bone movement.
viewtopic.php?t=8618
(this one is a long post but have the core information. Look for the "tail" anme file in one of the latest post and you'll see a 3D limb)
viewtopic.php?t=8778
This one is the video tutorial one.
With this technique you can control legs with a non affected former bone movements and the legs move as they were have been rotated 90º or what other angle you need.
Enjoy
-G