Adds an early return if Position/Offset inputs won't lead
to any changes in the Geometry.
It now also compares with the read-only Position attribute instead of
getting it for write only, to work correctly with Copy-on-Write.
Before, the `is_same`-check only worked for geometry created
in the node tree.
Differential Revision: https://developer.blender.org/D16738
This adds an explicit post processing step to node declarations.
The purpose of this is to keep the actual node declaration functions
concise by avoiding to specify redundant information. Also it improves
the separation of the creation of the declaration from using it.
Improve a few messages, but mostly fix typos in many areas of the UI.
See inline comments in the differential revisiion for the rationale
behind the various changes.
Differential Revision: https://developer.blender.org/D16716
Using a cache greatly simplifies access to the output node.
I touched on the most common and understandable cases for me.
The texture nodes were touched because it looked pretty generic.
Differential Revision: https://developer.blender.org/D16699
Add preferred domain based on the "Value" input field. Most often,
the domain must match the original domain for the value.
Differential Revision: https://developer.blender.org/D16730
This allows using the "On Cage" feature in edit mode to interact with
original mesh elements via the newly created geometry. The original
indices are only set for new elements that copy attribute values
from original elements directly, so it can also be a helpful way
to visualize attribute propagation.
The change was simplified by refactoring the individual mode slightly
to create separate index maps for the new edges and vertices. That
simplified attribute copying a bit too.
This is partially a bug fix, since the original index layer wasn't
handled at all before, and could be left initialized. That was caused
by my recent change to modify a mesh in place rather than create a
new one. Also copy over any orco data, which was another unhandled
layer type.
It's also a new feature though, since it allows using the "On Cage"
feature of edit mode to adjust original mesh elements by selecting
the new ones. This brings the functionality inline with the Edge Split
modifier.
This patch implements the Simple Star Glare node. This is only an approximation
of the existing implementation in the CPU compositor, an approximation that
removes the row-column dependency in the original algorithm, yielding an order
of magnitude faster computations. The difference due to the approximation is
readily visible in artificial test cases, but is less visible in actual use
cases, so it was agreed that this approximation is worthwhile.
For the future, we can look into approximating this further using a closed form
IIR recursive filter with parallel interconnection and block-based parallelism.
Which is expected to yield another order of magnitude faster computations.
The different passes can potentially be combined into a single shader with some
preprocessor tricks, but doing that complicated that code in a way that makes
it difficult to experiment with future optimizations, so I decided to leave it
as is for now.
Differential Revision: https://developer.blender.org/D16724
Reviewed By: Clement Foucault
This patch implements the Ghost Glare node. It is implemented using
direct convolution as opposed to a recursive one, which produces
slightly different results---more accurate ones, however, since the
ghosts are attenuated where it matters, the difference is barely
visible and is acceptable as far as I can tell.
A possible performance improvement is to implement all passes in a
single shader dispatch, where an array of all scales and color
modulators is computed recursively on the host then used in the shader
to add all ghosts, avoiding usage of global memory and unnecessary
copies. This optimization will be implemented separately.
Differential Revision: https://developer.blender.org/D16641
Reviewed By: Clement Foucault
Nodes which are common in multiple editors (RGB, Value, Switch, RGB to BW)
has less width in compositor editor. Patch changes compositor node width to
140 for consistency.
Reviewed by: HooglyBoogly
Differential Revision: https://developer.blender.org/D16719
OpenVDB likes to crash even in release builds when volumes become too small.
To fix this I used the same function that we use in other places already to
determine if the resulting volume will be too small.
Based on feedback from Simon Thommes, for link-drag-serach it's most
useful to have the A and B sockets connected, first, then the factor
sockets, then the special color mix operations. This addresses that by
adding the search items in order and decrementing a weight manually
as items are added.
The wrap function was a feature of the old compositor
but was never ported to the new CPP compositor node.
This simply removes the unused property, the function could alternatively be
restored but in has been missing for a decade so it does not seem missed.
Differential Revision: https://developer.blender.org/D16712
Fixes T102796
The Blur Attribute node mixes values of neighboring elements in meshes and curves.
Currently it supports points, edges and faces on meshes and points on curves.
In theory, support for face corners could be added, but useful semantics are not
obvious yet.
The node calculates a weighted average of each element with its neighbors (based
on curve/mesh topology). The weight of the element itself is always 1, and the weight
of the neighbor elements is controlled by the weight input socket. In the future,
more options for how different elements are weight can be added (e.g. smoothing
groups and selection).
The node can perform multiple blurring iterations to achieve a blurrier result.
Generally, it is better to do multiple iterations in one node instead of using
multiple blur nodes because it has better performance in the current implementation.
We use the term "Blur" (instead of "Smooth") because smoothing is generally more
related to removing roughness from surfaces. When viewing the result of the
Blur Attribute node in the viewport, it looks like an image is blurred. While the
node can also be used to smooth surfaces, other/better algorithms exists for that
purpose (which e.g. don't reduce the volume of the mesh to zero with too many
iterations).
Differential Revision: https://developer.blender.org/D13952
Avoid using an incremented "loop index" variable which makes the whole
data-filling necessarily sequential. No functional changes expected,
this just simplifies some refactors to face corner storage.
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 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
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
This cache was never written to, only "copied" between sockets in one
case, it dates back at least a decade. It doesn't make sense to store
caches on node trees directly anyway, since they can be used in
multiple places.
