| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The issue was that the attribute propagation in the Fillet Curve node seems
pretty broken. I couldn't really make sense of the old code. It changed the
size of the point attribute domains on splines to 1 for some reason which
led to a crash in the next node.
Differential Revision: https://developer.blender.org/D13362
|
|
This is only meant to be used for development purposes for now,
not to show warnings to the user.
Differential Revision: https://developer.blender.org/D13348
|
|
This dependency was a bit ugly and the functions from the mask modifier
did a few things that we don't need in the Delete Geometry node:
* The mask modifier uses `CustomData_copy_data` which the node doesn't need.
* The mask modifier checks for `-2` in some values, but this special value is
not used by the node.
Differential Revision: https://developer.blender.org/D13335
|
|
Unity builds are only used in the `bf_nodes_geometry` module for now.
This module has been prepared to support unity builds already.
Usually, there is a 2-4x speedup when building `bf_nodes_geometry`
compared to without unity builds (e.g. 145s to 55s).
For more information about how unity builds work and how they help
with compile times, see D13341.
Differential Revision: https://developer.blender.org/D13341
|
|
|
|
Previously, attribute propagation did not work correctly in when only
deleting edges and faces (but not points). Face and face corner attributes
were propagated wrongly or not at all respectively.
In order to keep the patch relatively small for the release branch,
it does not include some small optimizations. These can be done in 3.1:
* Use a `Span<int>` instead of `IndexMask` to avoid creating an
unnecessary `Vector<int64_t>`.
* Only prepare index mappings when there are actually attributes to
propagate.
Differential Revision: https://developer.blender.org/D13338
|
|
Adds a new overlay called "Timings" to the Geometry Node editor.
This shows the node execution time in milliseconds above the node.
For group nodes and frames, the total time for all nodes inside
(recursively) is shown. Group output node shows the node tree total.
The code is prepared for easily adding new rows of information
to the box above the node in the future.
Differential Revision: https://developer.blender.org/D13256
|
|
With this commit, we no longer use the prefixes for every node type
function like `geo_node_translate_instances_`. They just added more
places to change when adding a new node, for no real benefit.
Differential Revision: https://developer.blender.org/D13337
|
|
This puts all static functions in geometry node files into a new
namespace. This allows using unity build which can improve
compile times significantly (P2578).
* The name space name is derived from the file name. That makes
it possible to write some tooling that checks the names later on.
The file name extension (`cc`) is added to the namespace name as
well. This also possibly simplifies tooling but also makes it more
obvious that this namespace is specific to a file.
* In the register function of every node, I added a namespace alias
`namespace file_ns = blender::nodes::node_geo_*_cc;`. This avoids
some duplication of the file name and may also simplify tooling,
because this line is easy to detect. The name `file_ns` stands for "file
namespace" and also indicates that this namespace corresponds to
the current file. In the beginning I used `node_ns` but `file_ns` is more
generic which may make it more suitable when we want to use unity
builds outside of the nodes modules in the future.
* Some node files contain code that is actually shared between
different nodes. For now I left that code in the `blender::nodes`
namespace and moved it to the top of the file (couldn't move it to
the bottom in all cases, so I just moved it to the top everywhere).
As a separate cleanup step, this shared code should actually be
moved to a separate file.
Differential Revision: https://developer.blender.org/D13330
|
|
Currently the geometry nodes evaluator always stores a field for every
type that supports it, even if it is just a single value. This results in a lot
of overhead when there are many sockets that just contain a single
value, which is often the case.
This introduces a new `ValueOrField<T>` type that is used by the geometry
nodes evaluator. Now a field will only be created when it is actually
necessary. See D13307 for more details. In extrem cases this can speed
up the evaluation 2-3x (those cases are probably never hit in practice
though, but it's good to get rid of unnecessary overhead nevertheless).
Differential Revision: https://developer.blender.org/D13307
|
|
|
|
This changes what domain is used by the raycast mode. This should fix the
behavior for face corner attributes (but may make it a bit slower for other
attributes). I think for 3.0 this is an acceptable trade off. For 3.1 we can do
what the comment suggests already.
Differential Revision: https://developer.blender.org/D13333
|
|
|
|
This will be useful to solve some issues with unity builds,
which compiles different files together to improve build times.
|
|
This really doesn't have to be a callback currently, since it is always
the same `CPPType` for a socket type.
|
|
When 97533eede444217 added the instance domain, it didn't change
the domain that instance attributes are read from in this node.
|
|
Previously, the function names were stored in `std::string` and were often
created dynamically (especially when the function just output a constant).
This resulted in a lot of overhead.
Now the function name is just a `const char *` that should be statically
allocated. This is good enough for the majority of cases. If a multi-function
needs a more dynamic name, it can override the `MultiFunction::debug_name`
method.
In my test file with >400,000 simple math nodes, the execution time improves from
3s to 1s.
|
|
Updates the Transfer Attributes and Capture Attributes nodes
to support attributes from instances.
Differential Revision: https://developer.blender.org/D13292
|
|
Instance attributes exist on the instance domain after rB97533eede44421,
so these fields should be evaluated on that domain.
|
|
Adds an attribute provider for instance attributes.
A new domain `ATTR_DOMAIN_INSTANCE` is implemented.
Instance attributes are not yet realized correctly.
Differential Revision: D13149
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
|
|
This is a bit similar to rBb7260ca4c9f4b7618c9c214f1270e31d6ed9886b.
Sometimes a group node may not reference a node group
because it was linked and can't be found.
|
|
Separating geometry nodes into a new library will make it
easier to improve compile times with features like unity
builds and precompiled headers.
Differential Revision: https://developer.blender.org/D13261
|
|
Previously, node types had a callback that creates internal links. Pretty
much all nodes used the same callback though. The exceptions are the
reroute node (which probably shouldn't be mutable anyway) and some
input/output nodes that are not mutable.
Removing the callback helps with D13246, because it makes it easier
to reason about which internal links are created and when they change.
In the future, the internal links should be part of the node declaration.
|
|
This cleans up part of the code that still set the flag manually. Also, this
change helps with D13246 because it makes it easier to tag the node
tree as changed when the availability of a socket changed.
|
|
This commit contains a few mostly-related changes to this node:
- Add a warning when retrieving the geometry from the modifier object.
- Only create the output geometry when it is necessary.
- Decompose transform matrices in a more friendly way.
- Use default return callbacks like other newer nodes.
Differential Revision: https://developer.blender.org/D13232
|
|
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
|
|
|
|
|
|
Change the node class type for Node Select by Handle Type to
NODE_CLASS_INPUT
|
|
|
|
The node does support curves, but only in index mode (see T88630)
So add a specific error message for the nearest mode, and let the
node support curves in the declaration.
Differential Revision: https://developer.blender.org/D13205
|
|
Adds a boolean field output containing a selection of the
points of the star that are controlled by the outer radius
of the star.
Differential Revision: https://developer.blender.org/D13097
|
|
This new order is a bit more intuitive.
|
|
|
|
Differential Revision: https://developer.blender.org/D13194
|
|
Adds a vector offset field to the "Curve Handle Position Node".
This vector is added to the incoming position (which is the
implicit handle position if not connected) which will set the
position of the handle. Default is (0,0,0)
Differential Revision: https://developer.blender.org/D13035
|
|
Selection sockets are meant to come right after the geometry,
this was missed in review of rBa7672caeb255e3.
Also, the selection value was not hidden.
|
|
|
|
Currently the Distribute Points on Faces node does not propagate
non-point attributes correctly. That is because it first interpolates the
attributes to the point domain on the input mesh, and then propagates them.
Differential Revision: https://developer.blender.org/D13148
|
|
|
|
Previously, to get the declaration of a socket, one had to go
through `node->declaration`. Now this indirection is not necessary
anymore. This makes it easier to add more per-socket information
into the declaration and accessing it in various places.
Currently, this system is used by socket descriptions and node warnings
for unsupported geometry component types.
|
|
Reference struct members by name instead relying on their order.
This also simplifies moving back to named members when all compilers
we use support them.
|
|
|
|
The point domain attributes (stored on splines) are sorted so they
have a consistent order on all splines after the join. However, spline
domain attributes were included in the new order, which didn't work
because the length of the attribute lists didn't match. The simple fix
is to only include point domain attributes in the new order vector.
|
|
Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX`
operator context enum. This adds type safety, allows the compiler to
produce better warnings and helps understanding what a variable is for.
Differential Revision: https://developer.blender.org/D13113
Reviewed by: Campbell Barton
|
|
|
|
This solves the issue in a more general that can also be used to solve
similar issues for other nodes in the future. Nodes can specify their
"main" socket in their declaration so that we don't have to rely on
heuristics.
Differential Revision: https://developer.blender.org/D13108
|
