Jump to content
Hash, Inc. Forums

bobcroucher

Hash, Inc
  • Posts

    95
  • Joined

  • Last visited

3 Followers

Profile Information

  • Name
    Bob Croucher

Previous Fields

  • Hardware Platform
    Windows
  • Programmer
    Yes

bobcroucher's Achievements

Apprentice

Apprentice (3/10)

0

Reputation

  1. Hi All, I want to submit my opinion about the Key-Groups idea, so that people will realize that there are pros and cons to using them. Both features: Key-Groups, and Drag/Drop poses were written by myself, so I am not writing this because I have some sort of agenda for advocating one feature over the other. The majority of what is accomplished with key groups can be accomplished by creating a simple pose, with keyframes created on the bones which you want to key. Place translate keys, on some bones, rotate keys on others, scale on others, or combinations of these on others. Now to generate these keys on a new action you can just drag this pose (you can even drag poses from the pose slider window) onto the action or chor window. This pose will be pasted into your current action at the current frame. To do manual hold keys later in the action, you can use force keyframe with "all model", and since the correct keys already exist, new keys will be dropped on these channels. Much time has been spent in this thread describing why Key Groups are cool. All of these statements are true. I won't repeat all those benefits here. Most of the benefits also apply to Drag/Drop poses. Advantages of Drag/Drop Poses: They are easier to create than Key Groups. (no Nulls, no Constraints) When it is time to use them, it takes just one step instead of two, just drag/drop instead of Turn ON then OFF. They are easier to understand how they work, since it is not a side effect of an obscure feature. They are lightweight, and add nothing to the realtime evaluation speed of the model. The only cost is paid at the time the pose is dropped. Key groups add permanent constraints to every bone upon which they act. These constraints have to be evaluated at every frame. You may see a list of these constraints by selecting the bone's transform and choosing Select/Driver. Key groups also require additional Null bones. Every bone added to a model is another one to traverse and evaluate at every frame. This lightweight vs heavyweight issue is the single biggest advantage of Drag/Drop poses. It is a painless process to convert Key-Group poses to Drag/Drop poses, but not the other way around. To create them, create a new action, use the key group pose (turn it ON, then OFF), now delete the key group's pose channel you just created, but leave all the keys it created. Now use the Action/Create Pose menu. This new pose, is a drag/drop style pose containing the same channels. You can now delete the Key-Group pose and rename your newly created Drag/Drop pose appropriately. Drag/Drop poses can create channels on pose motion, muscle motion, and any other animatable property, whereas Key-Groups can only create motion on the types of channels that constraints affect. Those are Translate, Scale, and Rotate channels. Disadvantages of Drag/Drop Poses: They cannot be used to force keyframes later in an action when the bones have been moved. The drag/drop will move the bones back to their default position, as was keyed in the pose. For this you must use Force Keyframe on all existing keys on the model, which in some cases may create more keys than you wish, since it keys everything you have animated. Drag/Drop poses are filtered by the Keymode filters. This is good and bad. It means that you can drop only a portion of your Drag/Drop pose if you want. For example, you could get just the translate keys, or just one specific branch of bones. The downside is that you have to remember to check the key modes before you drag/drop. I hope this helps you understand the differences and pros and cons of each feature. Thanks for reading, Bob
  2. Hi DeeJay, The expressions as Rusty showed should do the trick. Orient Like is written for arbitrary rotations, so it doesn't support the concept of rotating more than another bone. As mentioned earlier by Robert though, Roll-Like constraint only works on the Z axis of a bone, but it has a scale-offset option which permits it to scale its own roll based on the target bone's roll. This can be used to reverse the rotation direction, shrink or expand the rotation. It was really intended for gears and such, but with careful parenting and orientation you could use it in a neck/head as well. Collin's idea of using a relationship to do this is also a good one. You have total freedom in how you design the motion relationship between the two bones. It doesn't even have to be linear. On top of that it doesn't require any equations or confusing numbers. Just pose the controlling bone, then pose the controlled bone, then test in an action window, and iterate if necessary. Thanks for the brain teaser, and good luck, Bob
  3. Hi TimeLord, Noel from Hash placed this on AM:Reports for you. There was a maximum number of solver iterations to be performed per chain before giving up in the interest of speed. With 27 bones, this number was exceeded, and needed to be increased. The limit now scales up with the number of bones in the chain. Serg's example had about half the bones, and it performed fine. Now yours does as well. Bob
  4. It is impossible to get a circularity with this ONE pose setup, since you can't turn on both constraints at the same time. The IK constraints, and the "Follow the FK" constraints are mutually exclusive at all times. If you don't want either set ON, you could default the pose to "Not Set". But then you risk the FK and IK setups drifting apart if you animate while in that state. I recommend Picking either FK=ON or OFF, and setting that as the default in the model's user property. The project that I posted has one small problem. That is, the target NULL sits at the origin in the modeler. So starting out with IK=ON will result in his arm reaching down near his hips. Starting with IK=OFF works fine. I should have placed the null at the same location as the hand bone, then you can default to either IK state. This is a very simple rig. Controls for the elbow, clavicle etc... will need to be added. It is only to test and demonstrate the automatic Make Keyframe functionality. I will leave the fancy (and sweet BTW) rig creation to you guys on the rigging team. Thanks for all your work, Bob
  5. We discussed the version question at length at our meeting this morning, and concluded that this will be only the first of several potentially, problem causing changes which will need to be made for the movie. In order to keep a very stable release piece of software, and be able to change on a dime for the demands of a real production, the TWO project will need its own version of software. Hence 13.0. This version is almost identical to v12.0 right now, but will gradually change more and more as the movie demands. These changes will never be placed in v12.0, since it is a released piece of software. We will continue to fix bugs in v12.0. Any bugs fixed in v12 will be migrated to v13.0 and all later versions. Entirely new features, not necessarily for the movie will go into v13.5. Which will be released later. This version will also get any movie features from 13.0. To use this rig setup in version 11 or 12, the only additional step required, is to Make Keyframe before switching the IK pose ON or OFF. Bob
  6. Hi guys. The good news is that it is all working well now. People will really love how this works. I have attached a project derived from Mike's model, where I rigged the left hand side, and performed some very pathetic animation to demonstrate how it works. You can view this in v12, and probably even v11. It was created in version 13 without using the Force Keyframe button. Simply turning OFF or ON the pose called IK at the appropriate times. Version 13 will be coming out in Alpha fairly soon, and will be used throughout TWO. Bob SimpleLeftArmFKIK.zip
  7. With Mike's setup, there are constraints with the opposite ON/OFF state from the ik, which make the target follow the branch when IK is OFF. This also needs baked when it turns from ON to OFF. Mike: One small item. With two separate poses, there is risk of having both ON at the same time causing circularities. I think it simplifies the usage of the rig, if there is just one pose called say IK Arms. Then have the different constraints turn ON/OFF, or OFF/ON when the pose is ON/OFF. I hope this makes sense. I have begun testing this feature. I am having quite a difficult time with the timing. We must do the bake when everything is positioned as it was, but the constraint being turned OFF must be OFF already so that the results go into ordinary channels. I am sure I will get it right, but it is a little more tricky than I had hoped. Bob
  8. Hi, I think everyone's problems would be fixed if every constraint could automatically bake its values onto the current frame whenever it was triggered from the ON state to the OFF state. I don't know if this would break any current rig or setup. I don't believe so. It could be made optional, but my first impression, is that, I can't think of any time in which you WOULDN'T want this. Kind of makes me wonder why I didn't think of it before. The feature in itself is not that difficult, and doesn't present a high risk for newly introduced side effects, although there is always some risk. Can it be whipped in there quick enough for the TWO rigs? That is a good question. Do I dare do it in v12, which is released? Or do I settle for v13, which won't even go Alpha for a while yet? These are questions which can only be answered in a company meeting with the Grand Puba present of course. I guess we'll find out soon enough... I have always been talking about an easier way to attach and unattach FK and IK rigs. I am glad that all of your discussion and hard work, trying to improve the rigs, and software, has led us here. Thanks, Bob
  9. Hi David, I just read all 10 pages of your thread. I am really impressed with all of your hard work. It is amazing the things people, yourself included, can do with the primitive, but powerful, set of constraints, poses, and expressions in AM. A couple of items in response to earlier postings: This is a little known AM feature: The compensated force keyframe. You can turn on compensate mode before doing a force keyframe. Make sure your Key Mode settings are set to include the bones, properties, or poses which you want reset. Then press Force Key. This "Compensated" keyframe puts the values of the properties back to the values they would have had, if the current action wasn't there. Usually, this is the default model state (unless you are working with multiple actions). All the filtered animated properties should be forced to their previous values. This can be done at a later frame to un-squetch your character. David, you mentioned that you added a couple bones to allow an offset be created from this constrained value. If you set the constraint for "Before Action=ON", then the constraint is performed before the channels in the actions. This allows direct animation of the constrained bone in the action to be treated like an offset channel for the constraint. The results of the action are after the constraint, and therefore added to the constraints result. This can sometimes be used to reduce the number of bones or the complexity of your rig a tiny bit. Awesome work! Bob Croucher
  10. Hi John, Great work. It looks very nice. I loaded the Thom project. One of the glitches occurs at 8:09. The action THOM WALK 01 008 needed to last a bit longer. It ended before the next action (THOM WALK 01 009) had ramped all the way to 100%. At 22:12 thom's arm completely disappeared. I don't know why this is yet. This still needs investigated. Bob
  11. Hi Bjorn, I fixed the problem you reported on AM:Reports of clicking on the X, Y or Z sub drivers of a rotate driver while editing an expression. For your second problem involving a jump in the expression behavior. This is due to the automatic switching of the euler order which is used to decompose the rotation into 3 values. It is switching between YXZ order and XYZ order, on the fly, and causing the jump. In version 12, I have added a new property to the Bone called "Euler Order". Most users will never need to modify this, but for your expressions, you may want to change it from "Automatic" to "YXZ". That should remove the jump. Thanks, Bob
  12. Hi, This problem has been fixed. It was repaired due to AM:Report #470 reported by Barry Zundel, and fixed in the release 11.1e. No sample project was provided, so you will need to try your data out to be sure, but I believe it is the same issue. Thanks for the report (#888), Bob
  13. I recently fixed a memory leak reported on AM:Reports which occured when the smoothing option was ON. The project attached also has smoothing ON. I think the memory usage should be much lower in Alpha 8 when released, or in Alpha 7 even with smoothing set to OFF. Smoothing should not affect storage requirements since it is only used for a smoother version for display, but the leak was leaving all of the subdivided models around. So frame by frame more and more memory was consumed.
  14. Thanks for the project Steffen. The last Thom's pants project of yours I looked at cost me a month worth of bug hunting. This one looks great! I noticed your FPS was bumped to 300. Ten times as many per second as usual. I wondered if it would sim OK at 30 fps if I upped the steps from 5 to 50 per frame. It worked fine. This sims just a bit faster, but mostly it only has keys at 30 fps, which made the file and RAM situation significantly better. This may not work if the character motion was super fast, but it did in this case. Next, I upped the subdivisions to 4 then 16, as a test. It was much slower to sim, but much more wrinkling was apparent behind the knees, and between the thighs and the pelvis. Bob
×
×
  • Create New...