Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
This mainly removes the bmain argument, which can be
retrieved from the graph itself.
Also, I removed some outdated/unnecessary comments.
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8614
The problem here is that the baking code uses tiles to exchange pixel data with
the renderer since a recent-ish refactor, but the code that sent data to the
renderer did not initialize the bake result pixels.
Therefore, when the baking process for the second object started, Cycles
received empty tiles and sent them back as-is if the second object did not
cover them.
By initializing the tiles with the result of the previous bakes, we avoid this
problem.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule. This should be the final commit of the series of commits that
addresses this particular rule.
No functional changes.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
When bl_use_gpu_context is set, an OpenGL context will be available for
OpenGL based render engines.
Differential Revision: https://developer.blender.org/D8305
This was caused by `BPy_*_ALLOW_THREADS` being used when it shouldn't.
Implemented the simple fix suggested by @brecht :
> The simplest solution may be to ensure that Python stuff is only done
> when called through the RNA API, and not when Eevee calls it directly.
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
Function names will be updated in a separate commit.
This will be the place for the new particle system and other
code related to the Simulation data block. We don't want
to have all that code in blenkernel.
Approved by brecht.
- BKE_lattice_deform_data_create was init_latt_deform.
- BKE_lattice_deform_data_destroy was end_latt_deform.
- BKE_lattice_deform_data_eval_co was calc_latt_deform.
Previously this would be enabled when threads were used, but threads are now
basically always in use so there is no point. Further, this is only needed for
guarded allocation with --debug-memory which is not performance critical.
The previous naming scheme for the "selected to active" baking options
lead to confusion and they were not describing what they actually did.
To remedy this, I've added a new settings that does what the older setting implied it did.
Reviewed By: Brecht, Dalai, Andy Davies
Differential Revision: http://developer.blender.org/D7733
There should be no user visible change from this, except that tile size
now affects performance. The goal here is to simplify bake denoising in
D3099, letting it reuse more denoising tiles and pass code.
A lot of code is now shared with regular rendering, with the two main
differences being that we read some render result passes from the bake API
when starting to render a tile, and call the bake kernel instead of the
path trace kernel.
With this kind of design where Cycles asks for tiles from the bake API,
it should eventually be easier to reduce memory usage, show tiles as
they are baked, or bake multiple passes at once, though there's still
quite some work needed for that.
Reviewers: #cycles
Subscribers: monio, wmatyjewicz, lukasstockner97, michaelknubben
Differential Revision: https://developer.blender.org/D3108
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
Problem is that the RenderEngines will change the RenderData cfra when
rendering (when time remapping is used -- at least workbench/eevee/
gpencil do a combination of BKE_scene_frame_get() plus
RE_GetCameraWindow() which alters the RenderData cfra).
Later on in the pipeline, the Compositor will use this RenderData cfra
to determine the output file name for the FileOutput node. (In contrast
to this, the 'regular' Output will use the Scene's RenderData -- not the
Render's -- cfra [which hasnt been altered])
It is not entirely clear why RE_GetCameraWindow was setting the cfra on
the Render, but it appears to be legacy OGL rendering related and is not
needed anymore.
Removing this will keep the cfra as needed for the Compositor FileOutput
node.
