To keep things manageable, for now I'll just focus on more top level stuff - like how Objects, Materials, Lights, Textures, etc. - are arranged in the list relative to each other, since this does affect how much of the old structure I'll need to port over to the cleaned up filtering code I'm currently working on (main targets for that are splitting up visibility filters, and replacing the "check then do" with "grab to temp then bundle up").
Dealing with F-Curve Groups stuff is NOT a priority/focus/goal at this point, though I will address this LATER. +1 comments hounding about this will be removed.
With that out of the way, let's have a look at what the current list looks like.
1) Cube Object Expander
2) Cube Object-Level Animation Data Expander
3) A Group within CubeAction
4) A F-Curve within Group: Location
5) Another F-Curve within Group: Location
6) One more F-Curve within Group: Location
7) Subsurf Modifier F-Curve. Rooted @ ob-level
8) Cube Materials-List Expander
9) Cube Animated Material 1 Expander
10) A F-Curve for a material setting
11) Another F-Curve for a material setting
12) Yet another F-Curve for a material setting
13) A F-Curve for Texture Slot 1 - a mapping setting
The focus here is really on looking at how the Bold+Underlined items are grouped relative to each other. That is, how the datablocks are presented in this list.
To understand the current grouping, let's have a look at the ideas+assumptions underlying how this was conceived:
- The datablocks are grouped according to a similar hierarchy to the one you see in the Outliner, which is based on the general mental model of how we know that these are related to each other.
- i.e. Materials are grouped under Objects, so to find the animation for material used for some object, just go under that object. Same goes for texture on that material, and so on.
- i.e. When editing Object-transform animation, you may not want to see the list of Materials datablocks and/or the Particle Settings datablocks, so you close the "Cube Material-List Expander" for example.
- i.e. Material 1 (e.g. "skin") is only used for one object in the scene. Other objects may be using things like "plastic shell 1/2/3/4", etc.
An alternative which I think I once considered, and might bring back now will look like:
One factor which I now think I forgot about when doing this earlier was that there are datablock filters, i.e.
But what about textures and node trees. No longer are these always to be found linked to object-data datablocks (i.e. Lamp, Material) or World-data, but rather, in increasingly varied places, including brushes. Where do all these come in?
My current thinking is that perhaps generally relinkable Node Groups and Textures should perhaps get their own headings on the same level as Objects and Scenes, though perhaps instead of each Texture or each NodeGroup being one top-level heading, there could be a "Textures" and "Node Groups" entry, with the various texture/nodegroup datablocks being listed under that.
Hmm... describing that sounds a bit weird, so maybe that won't work that well :/
Anyways, as you can see, this is actually quite tricky to get right. More updates when I think of some other ways...
nice, what I wish is for the list to keep sync with new channels added, example: key loc x, it creates the location group, now key loc y, it goes out of the group. (or something like that). It seems like the grouping is defined once and it never recalcs?ReplyDelete