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)
Differential D2307
Viewport: implement new UI (work in progress) Authored by Dalai Felinto (dfelinto) on Oct 18 2016, 9:10 AM.
Details There are a few (bug ;) missing bits:
Any initial thoughts on the approach? (DNA/RNA/UI/ListBase - wise)
Diff Detail
Event TimelineComment Actions 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. Comment Actions
Comment Actions 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). IMHO it's fine to break compatibility of grid options for 2.8 so we don't need to keep the old properties around.
Comment Actions 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. Comment Actions Those - AO, lighting (?), matcap, ..., python defined - would be screen effects just as DoF and reflection.
Although the list(s) may get too big, it has the following advantages:
(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.
Are you referring only to the visibility flags? Or also settings such as grid size? Comment Actions 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? 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 Comment Actions 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.
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. Comment Actions What are the plans with this considering the new layers/collections work? Is this patch still valid after all? Comment Actions This was merged in blender 2.8 with still pending work. Closing the patch for now though. | ||||||||||||||||||||||