BEER UI discussion


#1

Use this thread to discuss UI only.


#2

Let’s start will the limitations of UI elements as @khalibloo mentioned.


#3

I still haven’t found a way to represent the proposed BEER folder structure using blender’s interface.
Here are some of the mockups I came up with, anyway.

Mockup A

Pros

  1. Everything is bundled in a single panel, allowing for other panels such as transparency, mirror, shadow.
  2. The shader layers are arranged in a definite order and cannot be re-ordered by blender or by the user (unlike individual blender panels).

Cons

  1. The modifiers have to be contained within the box of the shader layer that they influence in order to avoid confusion. The problem here is that there are certain restrictions as you go deeper and deeper into the hierarchy of blender ui elements (eg. column > box > column > box will not work in blender. Notice how the modifiers have no distinct header region)

Mockup B

Pros

  1. Shallower hierarchy of UI elements allows greater flexibility. Notice the modifiers have a distinct header region since they are not contained within a parent box.

Cons

  1. Shader layers are organized in panels. The user can easily re-order the panels without BEER ever realizing the difference. Remember, BEER is supposed to use a bottom-up order. This can easily become a huge source of confusion for users.
  2. BEER has no control over the ordering of its panels. Since blender uses a first-come-first-serve approach, any new shader layers will be added straight to the bottom. this is the opposite of how BEER should work.
  3. This approach will require generating and registering python classes in runtime.

Personally, I like the look of mockup B but i think A is more practical.
Also, I really don’t see need to bundle shader layers into folders. There doesn’t seem to be a practical way to do this in blender.


#4

nice going, lol our first obstacle (and many to come)


#5

haha :smiley:

Mockup C
This is what i meant when I mentioned the “texture stack model” in the Project View thread

Pros

  1. frees up a lot of ui space.
  2. displays only the active shader’s settings.
  3. users familiar with BI’s texture stack will find this straight forward

Cons

  1. extra navigation for the user. therefore more work is done as the user will need to jump between shader layers to access their settings

#6

The hard question: Should an object has many material containers? This might change the overall design and definition of Material and Shader in BEER.


With many material container (Like Mock Up C)
Pros:
Can have clear definition of material, material assign buttons on material container.
Material works like BI with nodes (close to BI at least).
Can have material container level texture (not sure the con of this yet).
Cons:
1 more panel to navigate, hence more clicks and slower.
Harder to understand: Materials vs Shaders.


Without material container
Shader layers as the container, but can assign to any faces.
Pros:
Less panel to navigate, easier to understand.
Cons:
Must put shader assign buttons under layers.
1 Shader can be on many faces with/without other shader (this can get complex to assign).
Cannot add top level (Material container level) texture.


I know this is hard, but we have to consider these options too. These designs will determine how BEER works and how easy or hard it is to understand and use. This also will determine the flexibility of the shader system to cover most use cases.

I’m viewing this at

  1. object level
  2. between objects (how hard to duplicate/setup shader)
  3. on top of material container (the outer material, if this is even useful)
  4. in material container (shader layers)

Please debate.


#7

The assign shader issue is like this. How hard is it to get that is determined by UI and the core design.

In the normal use case, you want to be able to reuse shaders. Some shaders can cover the whole mesh, and some only the faces it is assigned to. Currently the assigning works in BI but not “making shader” as 1 face can only has 1 material if done without nodes.


Update:
After some more thoughts, there are few features that we might need material container for. They are

  1. mirror
  2. options settings
  3. shadow

Should we move these as shader modifiers?

Things are getting complex. lol


#8

I think material containers will be needed. Each material should then contain its shader layers. This is a fundamental idea in blender. By sticking to it, BEER will be one step closer to one of its main objectives - Simplicity.

It would be very confusing and tedious for users if they had to assign each shader layer manually, where there could be a lot of layers and a lot of faces.
I’ve had characters with almost 20 material slots in BI. If I had to assign them layer-by-layer, I would have gone crazy :smiley:

So I think a middle ground should be found. Use material containers while allowing shader layers to be re-used across different materials. Perhaps a copy/paste feature or something.

To clarify, even Mockups A and B use material containers. My snapshots left them out in order to accommodate the truly new ideas. Sorry about that.

Mockup A

Mockup B


#9

The hard thing to differentiate is between container features and layer features. Or we do it like Freestyle?


#10

Good point. The container itself could contain universal settings that aren’t necessarily directly related to the appearance of the material such as some of the settings in the “Options” panel. internally, the material container in BI holds the texture slots and therefore references to the textures themselves. So containers will allow BEER to keep the texturing information all in one place rather than letting each layer to hold its own textures (unnecessary duplication of data in many cases).

So in my opinion, if the setting affects the appearance of the material, it should be implemented within the shader layer in order to give maximum flexibility to the users (by allowing them to use different values for different shader layers). It doesn’t matter even if BEER ends up not needing any container features.


#11

Using the middle ground solution, can you make a mock-up for world effects?
Just want to see if the middle ground approach still can be used for world effects.

Spoiler for Bconf 2014 but related for UI discussion


#12

Do you have a reference/concept for the world effects?
From the Bconf video above, I got:
AO
Rays
Sky
Mist
Speed lines
Half tone

Will the world tab be similar to BI’s or will it use layers too?


#13

Yes the world tab will have those and more, in a layered system, just like material. The world tab should be empty when it opens.


#14

Just a though:
Why not doing it with node?
You can make the output node as many layer you added…


#15

@MbakKoKom
Please listen to BEER Talk part 1, part 2 and part 3. This has been long discussed (since December 2012). We are not going back to that same discussion again. :wink:

Part 1: https://blendernpr.org/podcasts-in-bnpr-network-week-of-7th-september-2014/
Part 2: https://blendernpr.org/beer-talk-podcast-part-2/
Part 3: https://blendernpr.org/podcast-beer-talk-part-3/


#16

Hmm…
If you would make the shader panel like that, users will need to scroll a lot, don’t they?
*actually one of my nightmare, but bot with BI users…
Maybe just fix the panel…
Or create another panel… :slight_smile:


#17

Each shader layer has a small amount of panels. Compare that to nodes. A cycles production level material nodes is horrible if you open it for the first time. Even BI’s material nodes are very counter productive. Thus very hard to learn.


#18

Wait…
It stacked from bottom to the top?


#19

Please watch the video above.


#20

I prefer the second one, because it leaves more space…
The first one will make tight space…
@Design by @Khalibloo