Shading and Display Options
Closed, ArchivedPublic

Description

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
  • 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.

Details

Type
Design
Brecht Van Lommel (brecht) claimed this task.

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.

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.

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

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.

Since @Paweł Łyczkowski (plyczkowski) 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.

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?

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.

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

A lot of this may be irrelevant with 2.8 if we're able to get the shading workflow in place.