[Bf-committers] Texture assignment workflow is confusing

[Matt Ebb]

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 <brecht at blender.org> 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