In this commit, I've experimented with the way in which F-Curve names (seen in DopeSheet/Graph Editor) are put together.
Now, F-Curve names are assembled in the form:
<array-index> <property-name> (<struct-name>)
i.e. "X Location (Bone)", "Y Location (Object)"
"Specularity (VeryLongMaterialName)", etc.
The goal of this experiment was to hopefully make it quicker to do a left-margin scan and identify the defining differences between closely related F-Curves.
- This has the benefit of no (potential) need for horizontal scrolling back and forth to see and compare the end portions of names, and also to avoid the important parts of the name getting pushed out of the standard viewable area by some owner-struct long names.
- The downside is the loss of the clear hierarchial layout closely related to the RNA-paths used internally, that was provided by the old method. Also, this method also looks rather awkward on first glance, but if it improves efficiency of use, why not :)
Now F-Curve channels in channels region are drawn with the same colour as their respective curve is drawn in the curves area. I've had to make a compromise to store such colour info in F-Curves themselves, which is not terribly ideal if the F-Curve gets reused in some way. However, for now, this will do (special tweaks can be made to make this work better though).
I've also added a colour-determination mode per curve which should in future allow more control over this. By default, all curves still use the old 'rainbow' style. The available types area:
* Old Rainbow - Colour is determined 'automatically' using a magic method which uses curve position + total curves to generate a colour.
* Auto RGB - Color is determined using the 'array index' stored in F-Curve for data-access. An unresolved issue with this is that all the curves with this will end up with exactly the same colour, leading to confusion (i.e. all location.x and scale.x properties could potentially all be the same red colour).
* Custom colour - self explanatory
Currently, there's a minor bug when loading old files where the colours don't get initialised yet. For now, just clicking in the Graph Editor after file-load will solve any of these problems.
Ton: it looks like area->refresh() isn't getting called after file read.
It's about time that the RNA wrapping for various parts of the animation system were cleaned up for my recent changes. I've moved some code around (and/or deleted a file or two) in the process.
* Drivers view in Graph Editor now displays drivers only, instead of displaying normal Animation data.
* 'Materials' channel is now only shown under an Object when there are Materials with animation data...
* Hid more debug prints behind debug flag. These should be removed...
* Recoded the conversion code so that all data gets converted. Previously, some IPO's and Actions (notably the ones used for Action Constraints) were not ported across.
* Made F-Curve drawing use more saturated colours to make them more visible. I'm not sure whether this works well in practice.
* Restored some horizontal bounding-box checks to optimise drawing.
* Action Editor/Dopesheet now displays names retrieved from RNA in the form - "<Struct/OwnerName>.<PropertyName>.<ArrayIndex>"
i.e. "HeadBone.Location.X"
i.e. "Cube.Rotation.Y"
i.e. "Material.Diffuse Color.G"
For now, the first part of the name may be unclear as it is easy to confuse Material channels with Object ones if the material was called "Object1" or so (theoretrical example only). This will be explored further.
* Also, fixed crashes when loading some old files with 'Object' Action Channels in their Actions
* Action Editor - IPO curve names are shown properly again. Added anim_ipo_utils.c (old editipo_lib.c) file back. This will need to be removed when I port IPO system to RNA.
* Keyframing code - uncommented more of the code that's now working
* Made the 'preview range' button on timeline header draw more clearly
