Page MenuHome

Local View
ClosedPublic

Authored by Dalai Felinto (dfelinto) on Wed, Nov 21, 3:08 AM.
Tags
None
Tokens
"Love" token, awarded by amonpaike."Party Time" token, awarded by Zino."Love" token, awarded by ace_dragon."Love" token, awarded by steego."Love" token, awarded by billreynish."Orange Medal" token, awarded by duarteframos.

Details

Summary

Bring back per-viewport localview. This is based on Blender 2.79.
We have a limit of 16 different local view viewports.

TODOs:

  • Hack to make sure lights are always visible.
  • Expose this to RNA, so Cycles/Python can support this as well.
  • More testing.

Diff Detail

Repository
rB Blender
Branch
local-view (branched from blender2.8)
Build Status
Buildable 2531
Build 2531: arc lint + arc unit

Event Timeline

This seems generally fine. Some missing things to make operators respect local view:

  • rna_Object_visible_get should include this test.
  • ed_screen_context should include this test for visible_objects, selectable_objects, and so on.
  • TESTBASE should include v3d again.
source/blender/blenloader/intern/readfile.c
7413

This code is still needed, things can still go out of sync.

The only thing to add is v3d->local_view_uuid = 0; along with freeing v3d->localvd.

source/blender/editors/space_view3d/view3d_view.c
1217–1218

In this case it could kick one of the other 3D views out of local view, especially one that is not in any used workspace or editor.

Not sure it would happen much in practice though, so not blocking, but you could leave a comment about it.

1223

For multi-object editing, this should take into account multiple objects.

1323

This could just set v3d->local_view_uuid = 0.

1324–1325

I would not restore these shading and overlay settings, but keep them shared with local view.

1326

Campbell and I agreed to remove the local view cursor at some point, and just keep it global. It complicates things in some ways, and sometimes it's also unhelpful to lose the cursor position when existing local view.

1392

The flag is BASE_SELECTED now. It's best to use ED_object_base_select() for setting these flags.

Addressed all the issues mentioned in review.
That said there are still the following known issues:

  • When localview is in rendered mode, it has some issues when going out of local view.
  • Editmesh mode has some issues still (object disappear if you go out of edit mode inside localview).
  • Select all is ignoring viewport object type restriction.
source/blender/draw/intern/draw_manager.c
1429–1436

This might be nice to put in a utility macro or inline function, the same test is duplicated in a few places.

source/blender/editors/screen/screen_context.c
123–125

This needs object type selectability and visibility tests I think.

Same for selectable_bases and some of the others below.

source/blender/editors/space_view3d/view3d_view.c
1324–1325

The shading and overlay are still being restored, I would remove these two lines.

More fixes.

Some of them were stashed away (i.e., not resetting shading), but most of them
comes from looking a bit closer to the relation between local view and viewport
per object-type restrictions.

For now I'm assuming the selectability flag does not affect whether the object
is select, but only if we can select it further. I hope this is the intended
design otherwise there are plenty of things we need to change in blender2.8.

That said the biggest TODO here seems to be multi-editing. Up to debate whether
we should commit and tackle those in 2.8 or do it in the patch itself.

The operator needs to be added back in the View menu still.

For now I'm assuming the selectability flag does not affect whether the object
is select, but only if we can select it further. I hope this is the intended
design otherwise there are plenty of things we need to change in blender2.8.

I think that is the intended design. If selectability is per viewport there isn't really any other option anyway.

That said the biggest TODO here seems to be multi-editing. Up to debate whether
we should commit and tackle those in 2.8 or do it in the patch itself.

What's the problem with multi-editing?

I have no objection to committing this though.

Massive multi-object editing support

  • Add to View Menu
  • Cleanup

The operator needs to be added back in the View menu still.

Done

What's the problem with multi-editing?

It is tackled now. Basically all the object iterators need to be aware of the viewport. An example that would yield strange results and sometimes crash before:

  • 2 viewports, 3 cubes. Viewport A has 2 cubes in local view, viewport B selects all 3 cubes, go to edit mesh mode and select all vertices.
  • If you do G in the viewport A, you should move only the vertices of the 2 cubes, if you do it in viewport B it should move all of them.

For the records the cleanups you mention (util functions for the visibility tests) were not done here. But that is cleanup and can always be done after the merge.

Summoning @Campbell Barton (campbellbarton) here, in case he wants to take a look at it. Campbell I'm changing all the object iterators to take into account v3d.
(and just confirmed that indeed Cycles with renderer view still ignores local view)

Looked over the patch & tested functionality, design looks good - think any details relating to this that come up could be handled once in 2.8 (although I didn't see any).

This revision is now accepted and ready to land.Sun, Nov 25, 7:49 AM

Committed on 4c3ed98ca27667c3403361199096e31eaa93cce2.