Has there been any discussion on paths (or trajectories) on the view port in 2.5? Currently they are implemented for armatures alone and i was wondering if anyone has thought about including them for any animated objects. I must say that visualising a path and being able to edit the knots (keyframes) on that path in the viewport is a strength of Max. Looking back to my cel animation days, we had trajectories (we called them tram lines) for all our work and I sorely miss them in many apps, including Maya which doesn’t support them unless you use a 3rd party script.
Ok, I’ll add this to my todo list. Just adding paths there shouldn’t be too much work.
My plans regarding path/motion visualisations currently stand as:
0) Adding paths for objects
Making paths editable in some way
Ghosting entire meshes (or perhaps just proxy meshes) instead of just ghosting armature bones - not sure how to proceed with this yet… will see
Not on this list though are things like:
Editing ghosts - this really quickly gets out of hand from a technical standpoint, and I don’t really think it adds to the workflow. Simply scrubbing to the relevant frame then editing probably would do well enough, plus the ghosts shown then would probably be more appropriate.
Great news.
I think ghosting is less important (particularly as far as editing is concerned) than a clear track spawned form the object’s center. Whatever you manage to bring to the table will be fantastic.
I’m really keen on the idea of editable paths – that’d be very helpful!
Onion-skinning would be amazing, but all the implementations I’ve seen for 3D have sort of calculated 2D images of the animated mesh, so you can’t orbit the view or anything, which seems to eliminate any usefulness. Actual 3D ghosting would be revolutionary (?), but would need a lot of calculation…
It’s a fantastic workflow. To see the curve of a bouncing ball and edit it in the view is a whole other paradigm that I’m amazed hasn’t become a default in every 3d app.
This would be really useful. I have seen this in some XSI tutorial and its nice to have animated silhouette of the animated objects itself not just controlling armature.
And having editable paths? That would be miracle, definitely. Translate of the bones keys in 3d view for the beginning would be enough.
Sorry to hijack this but I have another question relating to the new animation system:
I have played with keying sets. Following Michael Fox (mfoxdogg) video tour IV.
Just simple test when I wanted only Y (euler) rotation and X, Z location to be keyed (yes, bouncing ball test). Unfortunately keying sets force me to have all curves for rotation/location. If I choose only some of them, keying sets cannot be set up.
Because there is not even keying option “Available” like in 2.49 it is really not too animator friendly to carry all curves including unneeded ones. I thought this was the aim of keying sets?
Also one more question concerning euler rotation. Which degrees are used in the Bone-Transform panel? If I rotate a bone 360 there is number -6.283 (or 6.283185 to be precise). Really not intuitive at all.
yes, being able to edit paths would be amazing. It’d be like just drawing arcs, practically.
Similarly awesome would be being able to change the handles of the beziers in the IPO window by moving bezier handles on the editable arc curve. Although that’s a whole 'nother step, and might be hard to impossible, depending on how blender’s set up.
For now, you’ll have to go to the datablocks view and turn off the ‘whole array’ setting for the relevant KeyingSets. KeyingSets are found under Scene…
One of the main aims of KeyingSets was make it easy to just keyframe all the settings that you find important to keep keyframed - especially when blocking, this would save you from having to select all relevant settings and try and remember to include the right keyframes for all the bones.
The ‘available’ option is currently not available. If there is sufficient interest, I can restore this…
Finally the complaints about radians instead of degrees for euler rotations start showing up (after the requests for eulers for bones have been satisfied)
Seriously though, currently all rotations are directly exposed via RNA in radians. We’ve had a few discussions about this and there didn’t seem to be any consensus on this so far. IMO, we should make RNA expose rotations in degrees by default, with facilities to express in radians (for scripts?) instead of forcing this upon the UI level (buttons, and animation editors) since there are significant complications involved with having checks/conversions for this throughout the animation editor code.
I should also note here though, that Blender does internally use radians, and keeping everything in a single form is ultimately more efficient than doing on-the-fly conversions…
it is more friendly to show degrees for the UI though!
scripts usually deal in radians and use convertor functions like dtor() or rtod()
I guess the confusion would arise with echoed operators though… an inexperienced scriptor might expect degrees and get confused with radians… I mean someone who just makes macros from the echoed operator report…
I see what you mean by having RNA expose values as degrees but it sounds dangerously in-consistent… I mean that the api functions that aren’t operators probably wouldn’t be dealing with degrees…
I’d definately prefer a clear cut line like:
UI displays degrees,
scripts deal in radians
and then add some built in functions like I mentioned: dtor() and rtod() for conversion.
Sorry to bother again. But I have spent couple of hours searching in Outliner-Datablocks for “whole array” setting for KeyingSets. But with no luck. Any better hint
Thank you very much for your advice. It means that I have to include transform/rotations/… whatever into keying set. Then edit relevant keying set - turn off “Entire Array”, then go back to transform/rotations/… and remove curves I do not want to have animated.
Aligorith, I have played with Keying Sets and the option to switch off Entire Array for relevant Keying Set Path. Unfortunately I was not able to set it up. ust simole test. One bone where only Location Z and X should be in Keying Set. I have added Bone Location into Keying Set. Editted the Keying Set Path Entire Array (off). Later I tried to have only Location X and Z included and Y exlcuded. But with no luck. Strange was the Blender decided to key only Bone Location X value no matter what. You can test the blend in matter: http://rapidshare.com/files/266148823/KeyingSetsTest.blend
Anyway much animator friendly approach would be to decide keying sets members per curve basis in advance.
Aligorith I have give it another try to remove from keying set unneeded curves from entire array. But once again I have to say there are some problems how to do it. So if change of keying sets principle was too complicated the possible solution maybe to use Available keying we have in Blender 2.49 (animator would key e.g. Location, remove unneeded curves and then key with Available. On the other hand Keying Sets possibility would abandoned using this other method which would be pity.
Sorry for the lack of response on this (been a bit busy of past few days). I’ve checked the file and there is indeed a bug somewhere (I currently can’t even assign any paths in the way that you’ve got selected, so something is definitely wrong there). I’ll look into this in more detail during the weekend…
Aligorith, thank you very much for correction the bug in matter during the previous weekend
EDIT: After playing with new build it still seems that the single curves keying paths do not work correctly. Maybe there should be different procedure how to set it up then the hereabove described oone?
Aligorith, I just wanted to confirm that now keying sets per curve works ok (even thought it is not so straight forward to set it up). So big thank you for this. by the way thank you for bone-hooks as well
One little think following my tests. If I lock curve in F-Curve editor (Editability of keyframes for this channel) when keying using keying sets (of which this locked curve is member) Blender still adds keys for this locked (uneditable) curve. I guess this is not OK? Thank you very much.
EDIT: Second finding. If animator tweak curves of bones directly in F-Curve editor bones react in realtime nicely but the mesh which should is deformed by this armature do NOT.
You have to move one frame to see the reaction of the mesh.
Here is an example: http://rapidshare.com/files/269788531/B25_Anim_1_Simple_SS_Ball.blend
