Age | Commit message (Collapse) | Author |
|
The simple subdivision as a type only causes issues like no-continuous
normals across edges, inability to reliably switch the type and things
like this.
The new subdivision operators supports wider variety of how to add
details to the model, which are more powerful than a single one-time
decision on the subdivision type.
The versioning code is adjusting topology converter to specify all
edges as infinitely sharp. The reason for this (instead of using
settings.is_simple) is because in a longer term the simple subdivision
will be removed from Subsurf modifier as well, and will be replaced
with more efficient bmesh-based modifier.
This is finished up version of D8436.
Differential Revision: https://developer.blender.org/D9350
|
|
Currently render passes in the draw manager (eevee) must be predefined
in the render result. This patch would ask the render engine for the
render passes it needs, and create these as a preparation step during
rendering. This allows any draw engine to define more complex render
passes setup.
Render passes can only be added before the call to `RE_engine_begin_result`.
`RE_engine_begin_result` makes a full copy of the render passes. During
rendering the render engines renders to the duplicated passes.
`RE_engine_end_result` syncs the data back to the original render passes,
but only if the passes existed in the original render result.
Currently we work-around this issue by registering the passes in
`render_result_new`. This is legacy blender internal structure and should
be avoided.
With upcoming projects (AOV/Cryptomatte) it becomes a bit of a mess as we
are extending legacy code to support new features. This patch allows us to
let each draw engine register their own render passes at render time
(similar to cycles and other render engines). In the future we could get
rid of legacy render passes registration in render_result_new.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D9088
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
This is first step of refactoring task T77580.
Next step will be breaking up files into smaller ones.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D8492
|
|
Remove word proxy from eSpaceSeq_Proxy_RenderSize members if proxy is
not used with that item. Otherwise this can be a bit confusing.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8861
|
|
|
|
Cleanup old tracker task format to the new. e.g: [#34039] to T34039
Ref D8718
|
|
This is was caused by incorrectly set `preview_render_size` in VSE
rendering context. Value was set to `SEQ_PROXY_RENDER_SIZE_FULL`, but
it should be `SEQ_PROXY_RENDER_SIZE_SCENE` as scene render size is
being used.
Alternatively we can check for `context->for_render` in
`input_preprocess()`, but I think fix above is more correct.
Reviewed By: sergey, brecht
Maniphest Tasks: T80424
Differential Revision: https://developer.blender.org/D8838
|
|
|
|
|
|
This was left from a previous refactor.
|
|
No functional changes
|
|
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
|
|
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8611
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8613
|
|
|
|
|
|
This may not have caused an actual bug.
|
|
|
|
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.
|
|
Also order sizeof(..) first to promote other values to size_t.
|
|
|
|
|
|
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
|
|
Also order return matrices last.
|
|
Also order return matrices last.
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
This removes extern-C blocks around other includes and adds
such blocks for some headers that need them.
|
|
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.
|
|
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
|
|
Differential Revision: https://developer.blender.org/D7986
|
|
|
|
- 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.
|
|
This helped to go beyond the 4GB limit, but is no longer relevant for 64 bit.
|
|
|
|
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D7787
|
|
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
|
|
|
|
compositor
|