[Bf-committers] Re: UI refactoring (was "IRC meeting minutes sunday 28th nov")

[Jonathan Merritt]

Alexander Ewering wrote:

> 2) You would be unable to have different direction mappings for, say, 
> Alpha
>    and Spec, unless you make seperate sliders for EVERY mapping 
> function. And
>    I'm sure you don't want that :)


Just out of interest; why wouldn't I want my specular coefficient to be 
different from my alpha coefficient (without having to apply a texture 
twice to achieve that effect)?  :-)

Personally, I'm in favour of representing the texture application 
process in a more obvious way.  I think the current system is a little 
confusing because textures are presented very much as an 
"after-the-fact" modification to a material.  We also have three 
different zones where coloring / texturing information might arise:
    1. The original material parameters in the material buttons.
    2. The texture mapping area of the material buttons (with its 
arbitrary combinations of effects).
    3. The texture buttons, where the actual parameters to generate a 
given texture can be changed.
I don't think this system is straightforward.  You may find it 
straightforward because you have become accustomed to it, but if 
somebody sends you a .blend file with a complicated shader (as happened 
to me several times when I was working on RenderMan export), you find 
you have to check loads of different areas to find out what's actually 
going on...  How is a texture generated?  How is it mapped?  What 
parameters is it affecting?

I think we could do with a system in which it is more directly obvious 
how a particular texture will affect a material.  So, for example, 
instead of having the material color in one place and a texture that can 
affect that color in a different place, we would have some kind of link 
that is placed right next to the material color.  For those parameters 
that don't involve "set point" values (eg: surface normal vectors), 
there would need to be a separate area, but there are relatively few 
non-set-point modulators.

Anyway, I guess this will all be a moot point if ever the proposed 
node-based shader construction is implemented. :-)

Jonathan Merritt.