This is just a bit more ergonomic and works a bit better with our C++
math vector types. Also, during PBVH build, don't store the center of
each triangle/grid. That's redundant and can always be recalculated
from the bounds.
Flag enables backends to differentiate between a framebuffer
bind with a custom loadstore state and a standard bind.
For Metal, this resolves an ambiguous complexity about loading
or clearing attachments by only flagging the first bind call as
explicit.
This means if a framebuffer is re-bound by a secondary code-path,
the re-started render-pass will not perform a secondary load. This
now allows explicit clear state to be specified on any attachment
type. Previously only memoryless attachments supported this.
To avoid further complexity, usage of`GPU_framebuffer_clear_* `
calls in conjunction with `GPU_framebuffer_bind_ex` will now
trigger an assertion failure.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115734
Rely on the depsgraph to detect scene updates,
using the `view_update` callback.
Remove `SceneHandle` and `scene_sync`.
Remove `reset_recalc_flag`.
Remove most `sampling.reset()` calls and their related logic,
and move the remaining ones to `Instance`.
Re-sync lights on `light_threshold` changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115758
Similar to previous commits (7332a1eb90), use three separate
functions for updating the bounds of different PBVH types. This avoids
the use of the vertex iteration macro. Also make the functions reusable,
so they can be called directly after a brush update in the future.
The copied the material index and its smoothness to every grid,
resulting in 4 bytes of memory per base mesh face corner. That's
wasteful, since it's trivial to loop up the original data from the base
mesh attributes as necessary. This way we can also avoid the
dereference.
Automatic memory management and clearer ownership! Requires
removing `MEM_CXX_CLASS_ALLOC_FUNCS` from `MeshRuntime`,
but that's used very inconsistently anyway, and `MeshRuntime` isn't
that large.
I've seen this appear in profiles sometimes, which it really shouldn't,
since it's just a single array access. I didn't detect an observable
difference, but we don't have to think about that anymore anyway.
Instead of storing a redundant array of faces, use the base mesh faces
and corner_to_face map. This saves 8 bytes per base mesh face with
multires sculpting, and avoids recalculating the topology map whenever
reevaluating the object. There is a lot of other duplicate data between
base meshes and faces, particularly in `MeshTopology`. This is just
a first step of untangling that.
Push the undo step before changing any grid hide data, fix a missing
allocation in the undo step, and workaround some issue with temporary
BitVector<> construction that I couldn't quite figure out. Also fix a
crash when there is vertex mask attribute but no multires hiding.
Two main user-facing benefits: only nodes with actually changed
values have undo steps pushed, meaning reduced memory usage
and undo runtime, and the mask attribute is removed when cleared,
reducing memory usage and theoretically improving performance
afterwards.
On the code side, the changes consist conceptually of expanding the
PBVH vertex iter macro for each PBVH type and simplifying the resulting
logic. This results in significantly more code; the idea is that in the
future abstractions to reduce duplication will become clearer. We just
want abstractions that relate closely to the actual data processing,
which is much simpler than the existing macro makes it look.
Specialize the mask update for each PBVH type, simplifying hot loops,
reducing reliance on complex shared state and clarifying which data is
used. Expose functions to update the visibility and masks tags for a
specific node. It can be helpful to call these after modifying the data
to update the flags while the data is more likely to be in CPU caches.
Since we're always writing the mask with the old format, this versioning
will have to run until a larger breaking release such as 5.0. Luckily it
is cheap, it's just rearranging the pointers to larger arrays.
Implements #105001 - new import option for name separator, e.g. "|" or "/".
Names found in the OBJ file are split by that, and a Collection hierarchy is
made, so you can have e.g. "o House/Roof/Tile" in the OBJ file.
Pull Request: https://projects.blender.org/blender/blender/pulls/115742
Changes:
- Renamed Split Viewer Node to Split Node
- Split Node is now under `Utilities` (similar to Switch node)
- Versioning: split viewer from 4.0 and before is replaced with the new split node connected to a new viewer node.
Pull Request: https://projects.blender.org/blender/blender/pulls/114245
Instead of allocating a separate bitmap per grid for the hide status, store
all the bits in a recently added C++ data structure that stores all bits in one
contiguous memory chunk. When nothing is hidden, nothing is allocated
(that saves 32 MB for a 16 million vertex multires sculpt). Intuitively it
could have better performance because of the cache benefits of
contiguous memory, but this is hard to measure. It also has a nicer
API than `BLI_bitmap`.
I discussed this with Sergey in person recently. Most of the changes are
just straightforward refactors. The part that isn't is a change to the "show/hide"
operator to structure it similarly to the mesh handling in 4e66769ec0.
Pull Request: https://projects.blender.org/blender/blender/pulls/115687
This merge does not rename any ID. In case a conflict happens (an ID of
the same name and library already exists in destination Main), its
counterpart in source Main is not moved, and its usages by other
moved-from-source IDs are remapped accordingly.
Libraries are also properly de-duplicated, and remapped as necessary.
Source Main is always freed by this function, since it is either empty,
or contains left-over IDs very likely to have invalid relationships
after the merge.
NOTE: This commit also enables `main_test.cc` unittests, which was
comitted by mistake in fe3cb11ae4, sorry about that.
Pull Request: https://projects.blender.org/blender/blender/pulls/115671
Usually Library pointers should not be affected by remapping, but this
can be needed in some cases.
WARNING: Use with caution, this is potentially a dangerous operation for
Main data integrity/validity.
Speedup the "apply zebra stripes" image loop by multi-threading it.
For non-float images, avoid an extra image copy that was not doing
anything useful.
4K UHD resolution, Windows Ryzen 5950X:
- LDR: whole `sequencer_get_scope` 16.4ms -> 5.3ms, just `draw_zebra`
part: 7.5ms -> 3.3ms
- Float image: whole `sequencer_get_scope` 126.6ms -> 114.1ms, just
`draw_zebra` part: 22.4ms -> 7.4ms. Whole scope is still expensive
due to color management work being done.
Pull Request: https://projects.blender.org/blender/blender/pulls/115622
The position of the vertical value slider has to be clamped to be
within the area of that slider, otherwise it can draw outside the
range when a value is over 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/115680
This operator (`SCULPT_OT_reveal_all`) is redundant with
the "Hide Show" operator (`PAINT_OT_hide_show`). Since
the latter was recently changed to be much faster, remove the
former and update keymaps and menus. The industry compatible
keymap actually already contains the hide/show operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/115629
