Shading and Display Options #37487

New Issue

Paweł Łyczkowski · 2013-11-16T11:51:54+01:00

2013-11-16 11:51:54 +01:00

Current Issues

Currently the settings regarding how we see models in the 3d view are scattered all around the interface:

The biggest display option, where we choose GLSL/Multitexture/Singletexture is hidden in the properties panel, and it’s set on Multitexture by default, which is a inferior display mode.
We have the main Viewport Shading menu on the 3d View's header.
We have the Display panel in the Properties sidebar.
We have the View panel in the Properties sidebar.
We have the local Display section in the Object properties panel, which for instance have the wire overlay draw mode, which should also be global.
And lastly, we have the Mesh Display panel while in the Edit mode.

My Proposal

My proposed solution is to put all those options under just two buttons in the 3d view window:

Viewport Shading Button

The first button, the Viewport Shading, would be a dropdown menu that combines the current Viewport Shading (Solid/Textured/Wireframe..) and Shading (GLSL/Multitexture /Singletexture) into one. It would also display the current selected mode with it’s name, to conserve UI space.

The available modes would be:

Bounding Box
Wireframe
SolidThat, if it’s possible, combines current solid with MatCap display.
TexturedCurrent GLSL Textured.
Textured Shadeless (Patch added by blendix) Current GLG Textured on a Shadeless material - very important for texture paint.
MatCap
Multitexture (Legacy) Left for older machines.
Rendered

The Display Button

The Display button would produce a pop-up with all the display options combined. A pop-up here is needed to toggle a couple of options at once.
Some options would be mode dependent - MatCap settings for instance.
The Draw Options visible when in edit mode would be here in other modes as well, but in a clearly separated section called “Edit Mode Draw Options”.
It would also contain the viewport-specific options from the 3d View’s sidebar View panel.

Object Display Override

An Display Override panel would be in Object Properties where you set the object’s display mode. Similar to the current one.

**Current Issues** Currently the settings regarding how we see models in the 3d view are scattered all around the interface: ![shot_131116_113854.png](https://archive.blender.org/developer/F27953/shot_131116_113854.png) The biggest display option, where we choose GLSL/Multitexture/Singletexture is hidden in the properties panel, and it’s set on Multitexture by default, which is a inferior display mode. We have the main Viewport Shading menu on the 3d View's header. We have the Display panel in the Properties sidebar. We have the View panel in the Properties sidebar. We have the local Display section in the Object properties panel, which for instance have the wire overlay draw mode, which should also be global. And lastly, we have the Mesh Display panel while in the Edit mode. **My Proposal** My proposed solution is to put all those options under just two buttons in the 3d view window: ![shot_130930_102018.png](https://archive.blender.org/developer/F27951/shot_130930_102018.png) **Viewport Shading Button** The first button, the Viewport Shading, would be a dropdown menu that combines the current Viewport Shading (Solid/Textured/Wireframe..) and Shading (GLSL/Multitexture /Singletexture) into one. It would also display the current selected mode with it’s name, to conserve UI space. The available modes would be: - **Bounding Box** - **Wireframe** - **Solid**That, if it’s possible, combines current solid with MatCap display. - **Textured**Current GLSL Textured. - **Textured Shadeless** (Patch added by blendix) Current GLG Textured on a Shadeless material - very important for texture paint. - **MatCap** - **Multitexture (*Legacy*)** Left for older machines. - **Rendered** **The Display Button** The Display button would produce a pop-up with all the display options combined. A pop-up here is needed to toggle a couple of options at once. Some options would be mode dependent - MatCap settings for instance. The Draw Options visible when in edit mode would be here in other modes as well, but in a clearly separated section called “Edit Mode Draw Options”. It would also contain the viewport-specific options from the 3d View’s sidebar View panel. **Object Display Override** An Display Override panel would be in Object Properties where you set the object’s display mode. Similar to the current one.

Paweł Łyczkowski commented

2013-11-16 11:51:54 +01:00

Changed status to: 'Open'

Paweł Łyczkowski commented

2013-11-16 11:51:54 +01:00

Added subscriber: @PawelLyczkowski-1

Brecht Van Lommel commented

2013-11-16 12:26:11 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2013-11-16 12:26:11 +01:00

Brecht Van Lommel self-assigned this 2013-11-16 12:26:11 +01:00

Brecht Van Lommel commented

2013-11-16 12:26:11 +01:00

We currently use the strict rule to only let developers that work on UI features and the module owners (Jonathan and me) create the design tasks. The wiki page is where anyone can create proposals, so please put this there.

This to keep discussion here focused on features that we think we can actually implement with the current development power within a reasonable time. For sure this is a good topic to look into, but we as developers simply do not have the time to discuss and decide on features that do not have a clear path yet to actually getting done.

We currently use the strict rule to only let developers that work on UI features and the module owners (Jonathan and me) create the design tasks. The wiki page is where anyone can create proposals, so please put this there. This to keep discussion here focused on features that we think we can actually implement with the current development power within a reasonable time. For sure this is a good topic to look into, but we as developers simply do not have the time to discuss and decide on features that do not have a clear path yet to actually getting done.

Paweł Łyczkowski commented

2013-11-16 13:16:03 +01:00

Sorry, Jonathan told me to put the design tasks here, and I set it to low priority to indicate that it's to be worked in the future, but kept in mind/discussed already.

Paweł Łyczkowski commented

2013-11-16 13:18:47 +01:00

I do understand correctly that this is a design task, not a coding task, right?

Brecht Van Lommel commented

2013-11-16 14:56:26 +01:00

Ok, seems we have some miscommunication then, I will talk to Jonathan to figure this out.

This proposal is actually a big departure from the 2.5 design in where we show which data, which may be good idea but it needs a bigger discussion that I do not want to get into yet.

Ok, seems we have some miscommunication then, I will talk to Jonathan to figure this out. This proposal is actually a big departure from the 2.5 design in where we show which data, which may be good idea but it needs a bigger discussion that I do not want to get into yet.

Julian Eisel commented

2015-10-18 23:20:07 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2015-10-18 23:20:07 +02:00

Since @PawelLyczkowski-1 is a designer of the core UI team (the only one who's still active), IMHO it's fine to let him create design tasks now and then.

It seems unavoidable to me to discuss this topic in the close future. At least for the ongoing custom manipulator (widgets) project, but propably also for other projects like viewport, custom wireframes, etc we need a good place for a number of display options.

Since @PawelLyczkowski-1 is a designer of the core UI team (the only one who's still active), IMHO it's fine to let him create design tasks now and then. ---- It seems unavoidable to me to discuss this topic in the close future. At least for the ongoing custom manipulator (widgets) project, but propably also for other projects like viewport, custom wireframes, etc we need a good place for a number of display options.

Brecht Van Lommel commented

2015-10-19 00:42:01 +02:00

My comments are from 2 years ago, I'm not sure how this is being done currently. Still I'd advise to always do design tasks when there is a perspective that some developer will work on it, discussions about hypothetical changes that no one actually plans to work on tend to be outdated by the time someone actually does.

Regarding the actual proposal, I think Blender Internal should get the same draw modes as Cycles, plus Textured Shadeless and Matcap probably. Multitexture draw mode should be removed eventually, or at least only be available in game engine mode.

Putting the per-object settings from the properties editor in the 3D view would be inconsistent with the current UI conventions. Note also there are per armature, per bone, per modifier, ... display settings, which I imagine would not all be moved to the 3D view.

Adding a new type of UI menu element to the 3D view also worries me. Do we really need two sets of menus for the 3D view, one in the header and another floating over the viewport? Do we need two places to put 3D view properties, one in these menus and one in these floating menus? Can't we improve the existing UI elements to make the display settings less obscure instead of adding new UI elements?

My comments are from 2 years ago, I'm not sure how this is being done currently. Still I'd advise to always do design tasks when there is a perspective that some developer will work on it, discussions about hypothetical changes that no one actually plans to work on tend to be outdated by the time someone actually does. Regarding the actual proposal, I think Blender Internal should get the same draw modes as Cycles, plus Textured Shadeless and Matcap probably. Multitexture draw mode should be removed eventually, or at least only be available in game engine mode. Putting the per-object settings from the properties editor in the 3D view would be inconsistent with the current UI conventions. Note also there are per armature, per bone, per modifier, ... display settings, which I imagine would not all be moved to the 3D view. Adding a new type of UI menu element to the 3D view also worries me. Do we really need two sets of menus for the 3D view, one in the header and another floating over the viewport? Do we need two places to put 3D view properties, one in these menus and one in these floating menus? Can't we improve the existing UI elements to make the display settings less obscure instead of adding new UI elements?

Paweł Łyczkowski commented

2015-10-19 01:51:32 +02:00

Putting the per-object settings from the properties editor in the 3D view would be inconsistent with the current UI conventions. Note also there are per armature, per bone, per modifier, ... display settings, which I imagine would not all be moved to the 3D view.

Adding a new type of UI menu element to the 3D view also worries me. Do we really need two sets of menus for the 3D view, one in the header and another floating over the viewport? Do we need two places to put 3D view properties, one in these menus and one in these floating menus? Can't we improve the existing UI elements to make the display settings less obscure instead of adding new UI elements?

Yup, from the perspective of these two years, keeping it simple seems best. I'll revamp the proposal when I'll have time.

Regarding design tasks without a developer - you have a point. But I'd like the big ones (like this one) to keep going anyway, some good things may pop up during brainstorming.

>Putting the per-object settings from the properties editor in the 3D view would be inconsistent with the current UI conventions. Note also there are per armature, per bone, per modifier, ... display settings, which I imagine would not all be moved to the 3D view. >Adding a new type of UI menu element to the 3D view also worries me. Do we really need two sets of menus for the 3D view, one in the header and another floating over the viewport? Do we need two places to put 3D view properties, one in these menus and one in these floating menus? Can't we improve the existing UI elements to make the display settings less obscure instead of adding new UI elements? Yup, from the perspective of these two years, keeping it simple seems best. I'll revamp the proposal when I'll have time. Regarding design tasks without a developer - you have a point. But I'd like the big ones (like this one) to keep going anyway, some good things may pop up during brainstorming.

Julian Eisel commented

2015-10-20 18:20:56 +02:00

:P missed that this is already a 2 years old task. Even more urgent to solve then! ;)