The attribute smoothing node asks for the ability to have a factor
outside the range of 0 and 1. The problem with this is that there is a
negative weight assertion for some of the mixers. If mixing between 0
and 1, then at a factor of 2, one of the elements will be negative.
Differential Revision: https://developer.blender.org/D16351
In a few places, nodes were added without updating the Identifiers and
vector. In other places nodes we removed without removing from and
rebuilding the vector. This is solved in a few ways. First I exposed
a function to rebuild the vector from scratch, and added unique ID
finding to a few places.
The changes to node group building and separating are more involved,
mostly because it was hard to see the correct behavior without some
refactoring. Now `VectorSet` is used to store nodes involved in the
operation. Some things are handled more simply with the topology
cache and by passing a span of nodes.
The new atomic disjoint set uses additional atomics which are not supported
as intrinsics on all architectures and require linking to libatomic.
Now always link to libatomic on Linux when it is available, instead of only
checking if atomic add for int64_t requires linking to this library.
Thanks to Sergey for the help fixing this.
`is_internal` is supposed to mean that the attribute shouldn't be
visible in lists or the spreadsheet by default, and that it can't be
accessed in geometry nodes. But the value was reversed, which
just happened to work because the list filtering was swapped.
Differential Revision: https://developer.blender.org/D16680
It is not really used from any of the sources, including the
standalone app. Since we are moving to a more backend-independent
drawing it makes sense to remove header which was specific to
how Blender integrates Cycles into viewport.
There is probably some cleanup in CMake files is possible, but
there is some inter-dependency with USD.
Differential Revision: https://developer.blender.org/D16681
This change fixes issues with viewport rendering when Metal
GPU backend is used for drawing. This is not a default build
configuration and requires the following tweaks:
- Enable WITH_METAL_BACKEND CMake option (set it to on)
- Use `--gpu-backend metal` command line arguments
It also helps using the `--factory-startup` command line
argument to ensure Eevee is not used (it is not ported and
will crash).
The root of the problem was in the use of glViewport().
It is replaced with the GPU_viewport_size_get_i() which
is supposed to be portable equivalent form the GPU module.
Without this change the viewport size is detected to be 0
which backfired in few places.
The rest of the changes were to make the code more robust
in the extreme conditions instead of asserting or crashing.
Simplified and streamlined GPU resources creation in the
display driver. It was a bit convoluted mix of creation of
the GPU resources and resizing them to the proper size. It
even seemed to be done in the reverse order. Now it is as
simple as "just ensure GPU resources are there for the
given texture or buffer size".
Also avoid division by zero in the tile manager.
Differential Revision: https://developer.blender.org/D16679
Steps to reproduce were:
- Open a .blend file that is located inside of an asset library and
contains assets.
- Save and close the file.
- Open a new file (Ctrl+N -> General).
- Open asset browser and load the asset library from above.
- If the assets from the file above still show up, press refresh button.
- -> Assets from the file above don't appear.
Likely fixes the underlying issue for T102610. A followup will be needed
to correct the empty asset index files written because of this bug.
We're in the process of moving responsibilities from the file/asset
browser backend to the asset system. 1efc94bb2f introduces a new
representation for asset, which would own the asset metadata now instead
of the file data.
Since the file-list code still does the loading of asset libraries,
ownership of the asset metadata has to be transferred to the asset
system. However, the asset indexing still requires it to be available,
so it can update the index with latest data. So transfer the ownership,
but still keep a non-owning pointer set.
Differential Revision: https://developer.blender.org/D16665
Reviewed by: Bastien Montagne
This is a workaround required to get BAT reliably working again after
recent rB133dde41bb5b, which fixed many indirectly linked IDs being
tagged as directly linked, and therefore having their reference written
in .blend file.
It seems that BAT is still missing proper handling of some ID pointers.
Required for the end of the Heist production here at Blender Studio.
rB9fa4ceb340951 caused a forward compatibility issue.
Going forward, when changing socket names, only the name should be
changed and not the identifier if possible.
The existing `DisjointSet` data structure only supports single
threaded access, which limits performance severely in some cases.
This patch implements `AtomicDisjointSet` based on
"Wait-free Parallel Algorithms for the Union-Find Problem"
by Richard J. Anderson and Heather Woll.
The Mesh Island node also got updated to make use of the new data
structure. In my tests it got 2-5 times faster. More details are in 16653.
Differential Revision: https://developer.blender.org/D16653
When entering paint modes the paint pivot was cleared,
which broken rotate around pivot. Fixed for all paint modes.
PBVH modes set the pivot to the PBVH bounding box
while texture paint uses the evaluated mesh bounding box.
90ea1b7643 broke the sorting that happens as nodes are selected.
The compare function for stable sort had different requirements than
the previous implementation.
This patch adds an integer identifier to nodes that doesn't change when
the node name changes. This identifier can be used by different systems
to reference a node. This may be important to store caches and simulation
states per node, because otherwise those would always be invalidated
when a node name changes.
Additionally, this kind of identifier could make some things more efficient,
because with it an integer is enough to identify a node and one does not
have to store the node name.
I observed a 10% improvement in evaluation time in a file with an extreme
number of simple math nodes, due to reduced logging overhead-- from
0.226s to 0.205s.
Differential Revision: https://developer.blender.org/D15775
