Making some liboverride local will break/corrupt liboverride hierarchies
in many cases. So that function (or its caller, in some cases) need to
call #BKE_lib_override_library_main_hierarchy_root_ensure to re-validate
(and re-generate if needed) the liboverride hierarchy roots.
The code ensuring a valid liboverride hierarchy root ID pointer for all
liboverrides in a given Main would fail in some cases, and crash on
asserts (in Debug builds) or due to corrupted data later in code
(release builds).
The main issue fixed here is re-entry in case of dependency loops (a
same ID being checked more than once within the same chain of recursive
calls to ensure its hierarchy root is valid). Solved the usual way now,
using the intermediate 'PROCESSING' flag instead of setting immediately
the 'PROCESSED' one, when recursively processing the chain of
dependencies.
A second issue fixed in that code was that in some cases, it could leave
the invalid existing hierarchy root pointer unchanged, because it could
not find a 'valid enough' alternative.
NOTE: This data corruption is presumably caused by 'make local'
operations on liboverride hierarchy root IDs. This will be addressed as
a second commit.
For reference, issue is reproducible when opening
`/promo/splash/040_0010.lighting.splash.blend` from Pets SVN repo r3106.
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
Caused by 2cead79747
The clip_plane count in BLI_kdopbvh.c was incorrectly reduced.
To solve, make the size of the clip_plane array variable.
This eliminates the need to keep values in sync.
This was because the size and bounds of points were not properly
checked in some places.
Additionally, the smoothing algorithm should only be run if the
smoothing window is larg enough.
This PR reuses the scene specific reflection probe resolution for all
reflection light probes in the scene. The target is to have a automatic
detection for the resolution. But as long as we don't have a mechanism
for detection it is better to not introduce a new UI element that will
be removed within the foreseen future.
This setting is currently used by EEVEE and EEVEE-Next. EEVEE supports
resolutions upto 4096px. This will be clamped to 2048 when using
EEVEE-Next.
The motivation for this is that EEVEE-Next will soon replace
EEVEE and 4096 can then be removed from the choices that the user can
made. Adding as separate option could need synchronization, and that
option would also be temporary as it will be removed by the resolution
detection mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113491
According to the documentation `read` isn't required to read all the
data requested. Although until recently I'd never encountered this and
none of Blender's code checks for read succeeding but not reading the
requested size.
Resolves#113473 where images over 2gb fail to load.
Ref !113474.
This traces planar lightprobe captures just like
the screen-space tracing does.
This is implemented as a separate shader that
loads the ray before the screen trace and
check if it can be traced against any available
planar probe. If it does it marks the ray as
traced (negative pdf) so that the screen tracing
pass does not override the result or try to
trace it.
Pull Request: https://projects.blender.org/blender/blender/pulls/113453
This patch improves the heuristic used to
determine maximum frames-in-flight at
different input latency levels.
Previous values adjusted to better encapsulate
workloads in the 10-20 FPS range which can
manifest excessive latency. Changes improve
total performance throughput and improve
the interactive user experience.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/113020
After performing a transformation EEVEE-Next non-stops resets the
sampling. The cause is that the `recalc` flag that are stored in the
Object isn't consumed. When transforming it was always filled with
`ID_RECALC_TRANSFORM` and kept on resetting the sampling.
Regression introduced by PR #113252.
Pull Request: https://projects.blender.org/blender/blender/pulls/113484
Currently nodes are reordered so that the "on top" nodes are last in
the list. Node order changing for simple operations like selection
means we either have to reevaluate the node tree data-block on
selections or accept that the evaluated order can be different from the
original. Currently we do the latter (see d76a0e98ba), but
makes it complex to access nodes by index, and is hard to reason about.
Instead of reordering nodes, store the ui order in the node itself
and sort the nodes before drawing them or doing any processing
that depends on the "depth."
The "selected_nodes" list in the context is no longer ordered by the
recent selection.
Pull Request: https://projects.blender.org/blender/blender/pulls/113419
When using Immediate mode emulation the data is stored in a ring buffer.
As data isn't overwritten it is safe to call multiple draw commands in
a single command buffer.
This improves drawing performance when immediate mode is being used, it
mostly improves the readability of the GPU traces in renderdoc.
Pull Request: https://projects.blender.org/blender/blender/pulls/113482
Wireframe mode wasn't working and viewport had flickering artifacts.
Reason was that the render pass creation failed for its framebuffer as
the input data was filled with garbage for attachments that were unused.
Vulkan requires every attachment to be filled upto the highest used attachment
slot. This PR fills missing attachments with a dummy texture.
Pull Request: https://projects.blender.org/blender/blender/pulls/113141
It seems that the code only ever converted the
first IK constraint found into a `PoseTree`.
Before #110417 constraints with zero influence were
skipped so it worked, except for the bug with the depsgraph.
After this patch the logic is the following:
From top to bottom of the constraint stack,
keep adding constraints until the first constraint with influence is added.
This ensures, that if there is only one disabled constraint,
it still gets converted into a `PoseTree`,
which is needed for the depsgraph to work correctly.
The resulting behavior from adding the first active constraint is
that the higher in the stack the constraint is, the higher its priority.
To achieve that I split off a helper function `find_ik_constraints`
that populates a vector of `bConstraint` pointers.
The code to create the `PoseTree` is still largely the same,
except I moved a few variables closer to where they are used.
Pull Request: https://projects.blender.org/blender/blender/pulls/113056
Remove unnecessary calls to BLI_file_descriptor_size when using
BLI_mmap_open since this stores the file size too.
While accessing the size twice isn't so bad, the additional check
that the file size isn't an error value is unnecessarily verbose.
Failure to seek would attempt to MMAP SIZE_T_MAX, while this would
likely fail, prefer an explicit error check instead of relying on
unreasonable requests to be rejected.
Accessing the file size returns -1 on error, for file packing this
was passed directly to an allocation which would wrap around to
SIZE_T_MAX and fail to allocate. In other cases zero was treated
as an error value but -1 wasn't.
Add checks for the error return value, also warn that packing files over
2gb isn't supported.
