Page MenuHome

Viewport: implement new UI (work in progress)
AbandonedPublic

Authored by Dalai Felinto (dfelinto) on Oct 18 2016, 9:10 AM.

Details

Summary

There are a few (bug ;) missing bits:

  • specific per-display layer panel
  • take new variables into account for drawing
  • "convert" the other display layers
  • doversion for 2.77 files

Any initial thoughts on the approach? (DNA/RNA/UI/ListBase - wise)

Diff Detail

Repository
rB Blender
Branch
blender2.8-layers
Build Status
Buildable 241
Build 241: arc lint + arc unit

Event Timeline

Dalai Felinto (dfelinto) retitled this revision from to Viewport: implement new UI (work in progress).
Dalai Felinto (dfelinto) updated this object.
  • Small changes from own review
  • More robust preset
  • cleanup: fix some over 120 long lines

The overall organization (UI) makes a lot of sense.

+10 for using eye icons! Much better than checkboxes, makes it clear we're toggling visibility.

This whole thing reminds me of the chat @Dalai Felinto (dfelinto) and I had with @Hjalti Hjálmarsson (hjalti) -- a way to see just the animated objects and their motion paths, like a specialized "render only" view. No need to hide objects or move them to hidden layers. A "render only the things I want" view.

opinion: Background Images seems too specific... we always have some sort of background (often just a solid color). Much less often have an image there. So why does this get its own display layer? If I'm not using a background image I don't want to see anything about background images in the UI. Will the UI for managing background images stay where it is, or become part of this new UI?

Similar for motion tracking. If I'm not using that feature, why is it so prominent? (feel the same way about current UI)

UI for hair & particles should be hidden until we get those features back. But this is a good place for them.

When DNA & RNA evolve, are we able to remove the old data structures? I've never had to do this before.

Dalai Felinto (dfelinto) edited edge metadata.
  • Merge remote-tracking branch 'origin/blender2.8' into blender2.8-layers
  • Some bugfixes + cleanups + grid panel

This goes into a similar direction as I intended to go with D2284 so generally +1. I'm not a fan of using the term 'layers' for yet another concept though, especially not if exposed to the UI. Why not 'plates'?

Another thing I'm not too sure about is: How is this going to work for offscreen rendering? We're adding data to View3D again which needs to be initialized for rendering, even if not rendered for the 3D view (that's why plates were part of the viewport engine in D2284).
When it comes to drawing the display layers (or plates), I'd suggest to do that using a draw callback that can be assigned on display layer creation. Such callbacks help avoiding messes with many switches or huge if-else blocks. Drawing the display layers would simplify to something like this.

IMHO it's fine to break compatibility of grid options for 2.8 so we don't need to keep the old properties around.

source/blender/editors/include/ED_view3d.h
393

*v3d, not *rv3d :)

source/blender/makesdna/DNA_view3d_types.h
93

Convention would be to use completely capitalized names, not camel case (https://wiki.blender.org/index.php/Dev:Doc/Code_Style#Macros.2C_Enums.2C_Inline_functions).

137–139

Could be replaced with single DisplayLayer member, that way you don't need DisplayLayerData, it can all be in DisplayLayer then.

316–321

Would suggest to move this into an own struct to avoid View3D from becoming too messy and to add some more context to what members belong to.

Brecht Van Lommel (brecht) edited edge metadata.EditedOct 19 2016, 2:37 AM

For screen effects, from the user point of view I would consider these no different than AO, lighting, matcap, motion blur, .. settings? In my opinion it's not really that useful to specifically present depth of field and reflections as layers in a list.

The lists for drawing support and elements might need to grow longer: Motion Paths, Edit Mode Normals / Creases, Stats, Physics Visualization, Background, Mist / Atmosphere, Particles, .. . The problem then is that the lists become really long and you need to scroll too much. With some grouping we can keep the list short enough.

But at that point is there any point in presenting these as "layers" rather than just tabs or panels that lead to certain UI settings? To me it seems all these display settings belong in a wider modal(ish) popup instead of the narrow 3D view properties, where there is sufficient space to lay you out all the settings properly. With either a vertical list / tabs like this on the left or horizontal tabs on top.

For screen effects, from the user point of view I would consider these no different than AO, lighting, matcap, motion blur, .. settings? In my opinion it's not really that useful to specifically present depth of field and reflections as layers in a list.

Those - AO, lighting (?), matcap, ..., python defined - would be screen effects just as DoF and reflection.

The lists for drawing support and elements might need to grow longer: Motion Paths, Edit Mode Normals / Creases, Stats, Physics Visualization, Background, Mist / Atmosphere, Particles, .. . The problem then is that the lists become really long and you need to scroll too much. With some grouping we can keep the list short enough.

But at that point is there any point in presenting these as "layers" rather than just tabs or panels that lead to certain UI settings?

Although the list(s) may get too big, it has the following advantages:

  • We can get rid of the individual panels (e.g., display, grease pencil layers, motion path, ..) and only show the relative to the selected one.
  • We can show only the visible, thus cleaning up the UI

(we can even have a pin system where an item is always shown even if invisible)

An alternative would be to start with very basic ones (axes & grid, and a few scene element ones) and allow them to be added/removed.

To me it seems all these display settings belong in a wider modal(ish) popup instead of the narrow 3D view properties, where there is sufficient space to lay you out all the settings properly. With either a vertical list / tabs like this on the left or horizontal tabs on top

Are you referring only to the visibility flags? Or also settings such as grid size?

Instead of three separate lists could we have "Drawing Support", "Scene Elements" and "Screen Effects" as categories or groups (like proposed layer groups) inside the same list?
They could be expandable showing the sub-items, and they could have a "master toggle" eye icon that would quickly toggle visibility of all sub-items overriding any child.

This seems more compact, requiring less space and would allow to quickly toggle a bunch items on/off. If one was unsure where a random item was searching would also be simpler (one list to search).

Not sure if further subdivision is a good idea or too much granularity, but we could even have further subcategories like say "Geometry Helpers" that would include "Face Normals" "Vertex Index" "Curve Normals", "Face Centers" etc. Or separated by object type for curve or mesh

Although the list(s) may get too big, it has the following advantages:

  • We can get rid of the individual panels (e.g., display, grease pencil layers, motion path, ..) and only show the relative to the selected one.
  • We can show only the visible, thus cleaning up the UI

Right, though I don't think these advantage are exclusive to this particular UI layout. Mainly my point is that you're effectively making a specialized tab system here, which might be good for this use case, but my guess is that doing that inside a panel in the narrow 3D view properties will not lead to a great UI.

To me it seems all these display settings belong in a wider modal(ish) popup instead of the narrow 3D view properties, where there is sufficient space to lay you out all the settings properly. With either a vertical list / tabs like this on the left or horizontal tabs on top

Are you referring only to the visibility flags? Or also settings such as grid size?

I'm referring to all the display settings. I'm not saying we have to do this now, but I expect it will get cramped and we'll need some kind of wider UI layout.

What are the plans with this considering the new layers/collections work? Is this patch still valid after all?

This was merged in blender 2.8 with still pending work. Closing the patch for now though.