This is a final step of having proper ownership. Now selecting different
layers in the "top bar" will actually do what this is expected to do.
Surely, there are still things to be done under the hood, that will happen
in a less intrusive way.
While getting rid of Scene->base we got the following fixes:
* Fix "Convert To" operator
* Fix "NLA allowing to selected objects that are not selectable
* Fix scene.objects (readonly, no option to link/unlink)
Note: Collada needs to use the context SceneLayer for adding objects
however I added a placeholder, so Collada maintainers can fix this
properly.
Depsgraph itself is still created fer the whole scene rather than for a
single layer, this is to be addressed next.
The storage for those dependency graphs is in scene, but now it is a hash
indexed by layer. In the future we can extend hash key to include extra
information (workspace? window?).
This is a lots of changes, but they are boiling down to a simple API
changes where we are no longer relying on implicit usage of scene's
depsgraph and pass depsgraph explicitly.
There should be no user measurable difference, render_layer* tests
are also passing.
Objects from set scene gets flattened out to the active scene depsgraph, so it
is a big question why do we need to build dependency graph for set scenes.
It will not be possible to do that after depsgraph becomes more context
oriented. Which means, all code will need to explicitly tell which graph
to free,
The idea is following: we do need to have multiple dependency graphs to denote
different scene layers (depsgraph should only contain objects from a specific
scene layer), and we also want to support same scene layer to be evaluated to
a different state in different windows. In order to achieve that we do need to
have a list or hash (for faster lookup presumably) somewhere. To keep things
easier for now, it will be a scene which owns that hash. This seems to make
sense anyway, since dependency graph only points to data which is owned by
scene.
This commit only introduces some basic API and hash itself stored in DNA, there
is no changes in behavior. See this as a first step towards getting rid of
scene-global dependency graph.
OUr beloved root nodetrees... Had to check again the code to undersand
why we copy them with bmain even though they are not in bmain, so this
is worth a comment. ;)
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
User count of scenes was inconsistant, screens only have 'user_one' kind
of owning over scenes, which means they shall never increment or
decrement their real user count. And usually, scenes have no real user
at all.
2016 GSOC project by @nathanvollmer, see D2150
- Mirrored painting and radial symmetry, like in sculpt mode.
- Volume based splash prevention,
which avoids painting vertices far away from the 3D brush location.
- Normal based splash prevention,
which avoids painting vertices with normals opposite the normal
at the 3D brush location.
- Blur mode now uses a nearest neighbor average.
- Average mode, which averages the color/weight
of the vertices within the brush
- Smudge mode, which pulls the colors/weights
along the direction of the brush
- RGB^2 color blending, which gives a more accurate
blend between two colors
- multithreading support. (PBVH leaves are painted in parallel.)
- Foreground/background color picker in vertex paint
It has been deprecated since at least macOS 10.9 and fully removed in 10.12.
I am unsure if we should remove it only in 2.8. But you cannot build blender with it supported when using a modern xcode version anyway so I would tend towards just removing it also for 2.79 if that ever happens.
Reviewers: mont29, dfelinto, juicyfruit, brecht
Reviewed By: mont29, brecht
Subscribers: Blendify, brecht
Maniphest Tasks: T52807
Differential Revision: https://developer.blender.org/D2333
Originally we were not respecting the original visibility flags of the
collections. However this is required for Copy-on-write (CoW).
Remember to update the svn lib tests folder. I had to update some of the
json files there.
Also adding a new unittest for this particular issue:
Test render_layer_scene_copy_f
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.
_copy_data() functions shall not do that at all anymore. Kept as option
for now even though that helper is only called from here...
Also moar varnames renaming to standard _src/_dst sufixes.
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 patch adds "Pixel Size" to the performance options, which allows to render
in a smaller resolution, which is especially useful for displays with high DPI.
Reviewers: Severin, dingto, sergey, brecht
Reviewed By: brecht
Subscribers: Severin, venomgfx, eyecandy, brecht
Differential Revision: https://developer.blender.org/D1619
