[Bf-committers] Texture assignment workflow is confusing

Bassam Kurdali bkurdali at freefactory.org
Mon Apr 26 20:03:25 CEST 2010


How about (just a quick idea) treating textures like we do animations -
give them their own space/editor.
Reasoning: texturing a value is essentially 'wiring' the output of a
function that value, similar to animation. the texture itself, is less
specific than the thing it textures.
so basically for anything that has a texture, it could have some channel
in the texture editor, where if you click you can see the texture/s that
are assigned to it , and edit them there.

Advantage to the current system:

1- by forcing you to use a seperate editor, it removes the temptation to
jump back and forth in the properties window between e.g. materials and
texture.

2- it shows via the 'channels' what thing you are texturing visually,
and allows you to switch back and forth by switching the world channel
vs. the wood material channel (for instance). selecting these things in
other contexts could automatically select them in the texture editor.

3- gives you a lot of space to edit the textures.. perhaps this means
less scrolling.

Disadvantage:

1- it forces you to use a seperate editor! perhaps this is fine for
people with multiple monitors, might be harder on people with small
screens.

2- it doesn't take into account nodal editing at all. Perhaps this can
be resolved with further thought... would be annoying to have to have a
properties editor, a texture editor AND a nodal editor open to edit
textures? or perhaps this is not a big deal?

On Mon, 2010-04-26 at 17:25 +0200, Brecht Van Lommel wrote:
> Hi,
> 
> I agree the workflow is confusing, but I would like to see some
> constructive ideas on how to improve this. Mockups, analyzing pro and
> cons of different solutions.. it's easy to propose a solution for one
> aspect of the problem but that then often conflicts with other parts
> of the workflow and existing design principles. Also I think this is
> not something that has to wait for a new shading system necessarily,
> it's still going to have to solve the most of the same problems.
> 
> * How to access textures for world/modifiers/brushes?
> * How can we avoid having to scroll in the material/texture UI, making
> it more compact?
> * How can we avoid switching constantly between material properties,
> texture properties and material nodes?
> * How to communicate the difference between texture and texture slot data?
> * Can we make the connection between the value that is being textured
> and the texture clearer?
> * Can we do all this we do this for workflows both with and without nodes?
> * How can we make managing material slots less confusing?
> 
> I know it's a bit much to ask to solve all these problems at once, but
> if everyone has their ideas for little tweaks to improve the
> situation, that helps, but doesn't add up to a nice consistent overall
> design.
> 
> 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've done some tests with this in
> the new shading code but making the UI for that work clear & efficient
> is still problematic. Some possibilities:
> 
> * Click button that takes you to the texture properties with the
> relevant texture pinned.
> * Click on the node in the node editor to make it active in the
> texture properties.
> * Select it in the texture properties from a list of all textured values.
> * Slide out a window with texture properties somehow, so you stay in
> material properties?
> * Open a popup window.
> * Open an extra tab that contains the properties for this texture,
> than you then later can close.
> 
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers




More information about the Bf-committers mailing list