Hi, I think the current design is reasonably good, and an improvement over 2.4. While the actual mapping data is often stored on the texture user, it's something that's more specific to the texture itself conceptually, so it's they belong together. eg. you don't think "show me the way this material is mapped", you think "show me how this texture is mapped".
I think the major problem with the current setup is not in what the 'texture properties' is comprised of or how it's laid out, but one level earlier - in finding what data to operate on. This is where the 'click world first then textures' behaviour happens, and I agree this isn't nice, and get a lot worse when you're dealing with brushes, modifiers, physics/force fields, textures used inside shader node trees, compositing node trees, etc. etc. I think part of the reason for this is that we still seem to be trying to hang on to this 90s-era-blender notion of 'texture buttons', a place where all textures and 'textureable channels' are, when nowadays the reality of how you work with textures in Blender is quite different. The fact is that textures are already in all kinds of places over Blender, and it's only going to get more widespread, not less, and the idea that all textures are neatly attached to texture stacks attached to ID blocks is not relevant any more. And this is not a bad thing, the idea of the texture stack is convenient for the simple cases covered in older blenders, but quickly gets problematic and confusing when forced to a wider scope of usage. On Tue, Apr 27, 2010 at 1:25 AM, Brecht Van Lommel <[email protected]> wrote: > Personally I think we should try to move to a system where you > basically say, "texture this property", and then that property gets a > texture or texture stack attached. I completely agree this is where we need to be heading, with the focus on finding and editing the individual textures themselves, rather than trying to find them implicitly and indirectly via their 'parent' data. In many cases now where you're working with textures in part of a workflow (eg. on brushes while sculpting, or in the compositor) you really just want to access that texture's properties directly, to tweak and then continue on with what you're doing. ( As a side node, this need for context-sensitivity in editing textures is also where proposals like having a new editor type for textures fall apart - often when you come into contact with textures, it's not "editing texture properties for their own sake" as the animation analogy is more similar to, but rather it's in service of some other task or workflow. ) The idea already mentioned of something like clicking on a texture somewhere in Blender and having that texture's properties immediately displayed in a properties editor could be a good fast way to achieve this context sensitivity without having to try and follow a trail of breadcrumbs each time. There could be various ways to make this type of editing more comfortable too, such as storing a history of previously edited textures (from throughout blender) that you can jump back and forth between. This would also show a much stronger connection between the value that is being textured and the texture itself. Currently for a lot of things there's a duplication and disconnection between the original properties (such as in a material) such a colour, hardness vs where those properties are in the texture properties. They're laid out differently, in a different place, and they're not all-inclusive either. Especially in an updated shading system where all (or at least many more) values are not hard-coded as being texture-able, but more generalised and flexible, being modified via node connections, the current design only gets worse. Anyway, I know something like this isn't dependent on a new shading system, but I think it would be a good thing to consider the two together, cheers, Matt _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
