This restores the object->data to a non-modifier evaluated state.
So this allow us to change evaluated object modifier stack directly and
get BKE_mesh_new_from_object() for the evalauted object.
Basically what we address here is to make sure the active object and the cage
are not interferring with the baking result (e.g., when baking Combined).
To do so, we take advantage of the fact that we create our own depsgraph
for baking. So now we can change the cowed objects, instead of the
original ones.
Note: There is still a way to get a crash. If you try to bake from
selected to active when is_cage, but with no cage object, we get an
assert:
```
BLI_assert failed: //source/blender/blenkernel/intern/DerivedMesh.c
mesh_calc_modifiers(), at
(((Mesh *)ob->data)->id.tag & LIB_TAG_COPIED_ON_WRITE_EVAL_RESULT) == 0
```
We can bypass this by passing ob_low instead of ob_low_eval to
bake_mesh_new_from_object on object_bake_api.c:847 . But then the edge
split modifier change will take no effect.
Since we started using looptris we no longer need a triangulation
modifier in the highpoly object. In fact having was causing a bug
where baking would be utterly broken.
This fix normal baking. Combined pass still needs a fix to hide the
objects during baking.
The fix itself simply is to store the cage object as a pointer instead
of a string/name.
That said baking with or without cage is yielding very different results
than in 2.7.
Currently no functional changes, just exposes all settings which we need
for OpenSubdiv, similar to what Subsurf modifier is doing already.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3602
Both the scene and workspace had an active view layer, and it was confusing
which settings were being used or displayed where. Now we always have one,
so there is no mismatch.
The "View Layers" tab in the properties editor is now "View Layer", no longer
showing a list of layers. Instead view layers can be added and removed with
the workspace view layer selector. They are also listed and selectable in the
outliner.
Single layer rendering uses the active view layer from the workspace.
This fixes bugs where the wrong active view layer was used, but more places
remain that are wrong and are now using the first view layer in the scene.
These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
For correct results these must have been set already when the depsgraph was
created and evaluated, so all dependencies have appropriate resolutions too.
For particle we no longer backup and restore the viewport particles to avoid
overwriting them during render, as copy-on-write solves this for us. Even
without COW particles seem to work ok.
This also removes the particle simplification options based on camera. This
was never used much and only available in Blender Internal.
Differential Revision: https://developer.blender.org/D3148
Scene, view layer and mode are now set in the constructor and never changed.
Time is updated on frame changes to indicate which frame is being or has been
evaluated last.
This is a step towards making EvaluationContext obsolete.
Differential Revision: https://developer.blender.org/D3144
User notes
----------
Compositing, rendering of multi-layers in Eevee should be fully working now.
Development notes
-----------------
Up until now we were still using the same depsgraph for rendering and viewport
evaluation. And we had to go out of our ways to be sure the depsgraphs were
updated.
Now we iterate over the (to be rendered) view layers and create a depsgraph to
each one, fully evaluated and call the render engines (Cycles, Eevee, ...) with
this viewlayer/depsgraph/evaluation context.
At this time we are not handling data persistency, Depsgraph is created from
scratch prior to rendering each frame. So I got rid of most of the partial
update calls we had during the render pipeline.
Cycles: Brecht Van Lommel did a patch to tackle some of the required Cycles
changes but this commit mark these changes as TODOs. Basically Cycles needs to
render one layer at a time.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3073
- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
The issue was caused by render result identifier only consist of scene name,
which could indeed cause conflicts.
On the one hand, there are quite some areas in Blender where we need identifier
to be unique to properly address things. Usually this is required for sub-data
of IDs, like bones. On another hand, it's not that hard to support this
particular case and avoid possible frustration.
The idea is, we add library name to render identifier for linked scenes. We use
library name and not pointer so we preserve render results through undo stack.
Reviewers: campbellbarton, mont29, brecht
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2836
We have a hardcored limit of 1000 images to be baked.
However anything anove 100 would be leading to overflow in the code.
Caught by warning from builder bot (my compiler doesn't even complain
about this, but it should).
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
If users wanted to bake only a few of the mesh materials, they would
still need to create dummy textures for the other parts.
This commit report (as RPT_INFO) the materials with no texture, but move
on to bake the others materials.
Basically upon invoking cycles baking we could canell it which would
leave G.is_break hanging as true. Since we were not setting is_break to
false before exec baking, it would misbehave.
