Engine is not stored in WorkSpaces. That defines the "context" engine, which
is used for the entire UI.
The engine used for the poll of nodes (add node menu, new nodes when "Use Nodes")
is obtained from context.
Introduce a ViewRender struct for viewport settings that are defined for
workspaces and scene. This struct will be populated with the hand-picked
settings that can be defined per workspace as per the 2.8 design.
* use_scene_settings
* properties editor: workshop + organize context path
Use Scene Settings
==================
For viewport drawing, Workspaces have an option to use the Scene render
settings (F12) instead of the viewport settings.
This way users can quickly preview the final render settings, engine and
View Layer. This will affect all the editors in that workspace, and it will be
clearly indicated in the top-bar.
Properties Editor: Add Workspace and organize context path
==========================================================
We now have the properties of:
Scene, Scene > Layer, Scene > World, Workspace
[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)
Reviewers: Campbell Barton, Julian Eisel
Differential Revision: https://developer.blender.org/D2842
by the transform constraint lines
Ported over e7395c75d5 from the
greasepencil-object branch. I should've fixed this ages ago, but
couldn't figure out why at the time.
Mostly internal changes, keeping both manipulators
could have worked but there was no point long term.
There are still some glitches to resolve, will work on those next.
A single manipulator could only assign a single operator to each part.
Now each part can have it's own.
Also modify 2D selection callback, 2D started at 1, 3D at 0.
Now use -1 for unset value, start both at 0.
Re-use operator return flags for manipulator modal & invoke,
this means manipulators can allow navigation or other events to be
handled as they run - see T52499
Caused by own recent changes in handling of verts/edges/etc. arrays storage
for raycasting (rBe324172d9ca6690e8).
Issue was actually even weirder - there is absolutely no reason at all to
release DM here, those finaldm are stored in Object or EditMesh structs and
handled by general update system, other code shall never try to release them!
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
We do have an history of those pieces of evil in our code, would be nice
to get fully rid of it, but at the very least let's not add more of them
in new code. :)
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
Changes for 2.8x to use EvaluationContext caused some confusion
- Would use scene layer passed from snap context.
- Would generate duplis from Main eval context.
- Would take context argument and use it to create another eval context.
Adding context args all over and filling in a new eval-context
for every ray-cast test isn't ideal either.
Remove the context argument since the purpose of
SnapObjectContext is to avoid this kind of confusion.
Store the EvaluationContext once and re-use.
