This implements weight rendering with the draw manager, with all drawing
options (Shading, wire, face masking, vertex masking).
This is part of T51208
Reviewers: campbellbarton
Subscribers: dfelinto
Differential Revision: https://developer.blender.org/D2654
With this we also do not need IDP_MergeGroupValues anymore.
If this causes problems in the future we can always make recursion an
option (like overwrite is).
The original code was failing because the base to object flushing was
only happening as part of the depsgraph. However we can use the
evaluated values to set the initial values of the base.
In this particular case, we couldn't set the new object visible because
its selectability flag was not set yet.
This replaces access to the first scene layer (which was wrong) with a linear
lookup of scene layer by it's active index.
This seems to be a better temporary solution to have things working for until
we've got proper workspace, depsgraph and it's per-layer storage in place.
This moves selectability/visibility flag flush from some hardcoded
places in the code to depsgraph. This way it is possible to simply
tag depsgraph to update those flags and rest it'll do on its own.
Using depsgraph for such flush is an overkill: those flags are fully
static and can not be animated, so it doesn't really make sense to
hook only those to depsgraph.
However, in the future we will have overrides on collections, which
ideally would need to be animatable and drivable and easiest way
to support this is to do this on depsgraph level, so it ensures
proper order of evaluation for animation and drivers. And it seems
logical to do both overrides and flags flush from depsgraph from
this point of view.
This commit also includes the evaluation of IDProperty for collections,
which basically are just another form of override. So once we implement
the other kind of overrides the flushing and collection evaluation won't
change.
Patch by Sergey Sharybin and Dalai Felinto
First this replace a custom data struct with IDProperty, and use
IDProperty group merge and copying functions. Which means that a collection
property setting is only created if necessary.
This implements the "Layer Collection settings" override system, as
suggested in the "Override Manifesto" document.
The core is working, with Scene, LayerCollection and Object using a
single IDProperty to store all the render settings data. Next step is to
migrate this to depsgraph.
Note: Clay engine "ssao_samples" was hardcoded to 32 for now. It will come
back as part of "Workspace Settings" later.
Many thanks for Bastien Montagne for the help with the UI template
nightmare ;)
Differential Revision: https://developer.blender.org/D2563
This is to be used from the Outliner, when dragging and dropping
collections from the Active Render Layer
It also includes a cleanup on the outliner so it calls the new
functions. Note: the outliner still needs fix to allow all the
functionality here exposed.
But this will be tackled by Julian Eisel later.
Nothing happen yet when it's supposed to insert the collection into
another one, that part will be handled by @dfelinto.
See gif for demo of how it works UI wise: {F500337}
Also fixed off-by-one error in utility function.
This adds initial support for reordering collections from the Outliner
using drag & drop.
Although drag & drop support is limited to collections for now, this
lays most foundations for general drag & drop reordering support in the
Outliner. There are some design questions to be answered though:
* Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?)
* Should/can we allow mixing of different data types? (e.g. mixing render layers with objects)
* How could we realize this technically?
Notes:
* "Sort Alphabetically" has to be disabled to use this ("View" menu).
* Reordering only works with collections on the same hierarchy level.
* Added some visual feedback that should work quite well, it's by far not a final design though: {F493806}
* Modified collection orders are stored in .blends.
* Reordering can be undone.
* Did minor cleanups here and there.
This should give the overall direction to whom wants to finish it.
- Renamed EDIT mode engine to EDIT_MESH mode engine
- Introduce EDIT_ARMATURE mode engine
- Started to port legacy drawarmature.c to draw_armature.c
test_evaluation_visibility_a failed before, but it is now fixed
test_evaluation_visibility_b passed before and was used as control to make sure it was not broken
This is a more complex approach, which makes me really want to use
IDProperty instead (assuming we handle their merging nicely).
In fact I would expect this to happen in readfile.c, not during
doversion, but I can revert this later.
For now this allow for demo files saved with 2.8 to keep working even
after we add/remove engine settings properties.
The values are merged. There is no purge though, so
old CollectionEngineSettings and CollectionEngineProperty will live
forever (for the time being).
This prevents crashes when a file was saved with 2.8, but a new
engine settings property was created.
In those cases any previous collection settings are wiped out. We can do
an elegant merge soon.
Note: we are now merging all the collection engines (mode and render), which eventually may get slow. But as stated before, this is to expose the functionality, while waiting for proper depsgraph integrated solution.
I didn't manage to get the proper object context in the collection
properties editor. That said I got it working for now in a temporary way
since this will change once we get workspaces anyways
(see changes in buttons_context.c and
rna_scene.c::rna_LayerCollection_mode_settings_get)
I still need to handle the merging of the settings. I will find a
provisory solution while we wait for depsgraph.
(also layer_collection_create_mode_settings_object and layer_collection_create_mode_settings_edit could probably be elsewhere - under draw/engines likely)
Every time:
* A collection settings is set
* A collection visibility changes
* An object is added/removed/ ...
We need to recalculate the "accumulated" CollectionEngineSettings that
the render engine should use for an object.
This is to be handled by the depsgraph. Meanwhile this code should allow
us to start using those settings in the render engines.
Note: We are storing this in the objects, which means we can only have
one active calculated option every time.
This is intended to get the conversation with the Depsgraph department
going.
Initial work by Clément Foucault with contributions from Dalai Felinto
(mainly per-collection engine settings logic, and depsgraph iterator placeholder).
This makes Blender require OpenGL 3.3. Which means Intel graphic card
and OSX will break. Disable CLAY_ENGINE in CMake in those cases.
This is a prototype render engine intended to help the design of real
render engines. This is mainly an engine with enphasis in matcap and
ambient occlusion.
Implemented Features
--------------------
* Clay Render Engine, following the new API, to be used as reference for
future engines
* A more complete Matcap customization with more options
* Per-Collection render engine settings
* New Ground Truth AO - not enabled
Missing Features
----------------
* Finish object edit mode
- Fix shaders to use new matrix
- Fix artifacts when edge does off screen
- Fix depth issue
- Selection sillhouette
- Mesh wires
- Use mesh normals (for higher quality matcap)
- Non-Mesh objects drawing
- Widget drawing
- Performance issues
* Finish mesh edit mode
- Derived-Mesh-less edit mode API (mesh_rende.c)
* General edit mode
- Per-collection edit mode settings
* General engines
- Per-collection engine settings
(they are their, but they still need to be flushed by depsgraph, and
used by the drawing code)
