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
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
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.
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
The geometry node evaluator now has access to the entire socket path
from the node that produces a value to the node that uses it. This allows
the evaluator to make decisions about at which points in the path the
value should be converted. Multiple conversions may be necessary under
some circumstances with nested node groups.
Differential Revision: https://developer.blender.org/D13034
This properly checks the order of point domain attributes on each
spline, and avoids the map, which makes the code easier to understand.
The assert is also added to realizing instances and the join node.
Differential Revision: https://developer.blender.org/D13071
Currently the curve to mesh node relies on the order of attributes being
the same on every spline. This is a worthwhile assumption, because it
will allow removing the attribute name storage duplication on every
spline in the future.
However, the join geometry node broke this order, since it just created
new attributes without any regard to the order. To fix this, I added a
"reorder" step after all the merged attributes have been created, the
types have been joined, etc. It should be possible to change this code
so that the attributes are added with the right order in the first
place, but I would like to do that after refactoring spline attribute
storage, and not for 3.0.
Differential Revision: https://developer.blender.org/D13074
We run into float precision issues here, clamp the number of octaves to
one less, which has little to no visual difference. This was empirically
determined to work up to 16 before, but with additional inputs like
roughness only 15 appears to work.
Also adds misisng clamp for the geometry nodes implementation.
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
Even though volumes can only have one material, it is still necessary to
allow assigning a material to a prodecurally created volume. This commit
adds volume support and a warning for when a non-constant selection is
used with a volume.
Fixes T92485
Differential Revision: https://developer.blender.org/D13037
This node doesn't only support point clouds, it supports any geometry
component type with points, so meshes, curves, and point clouds.
We could explicitly list them to add a warning for volumes, but
that wouldn't really have any practical benefit, and isn't done
elsewhere.
As part of the refactor to the node declaration builders, we had hoped
to add a regular expression specifically for these socket names, but
recent discussions have revealed that using the translation marker
macros is the preferred solution.
If the names and descriptions were exposed to RNA, these would not
be necessary. However, that may be quite complicated, since sockets
are all instances of the same RNA types.
Differential Revision: https://developer.blender.org/D13033
Calling `remove_unused_references` inside the `modify_geometry_sets` loop
was known to be not entirely reliable before. Now I just moved it out of
the loop which fixes the bug.
This fixes one (of possibly multiple) root issues. The collection passed into
the Collection Info node must not contain the current object, because that
would result in a dependency cycle and recursive instancing.
The text is just too long, it doesn't fit in the node width,
and the tooltips display the property names well enough,
since they aren't used as often as other settings.
Also display the text in lite builds too, there is no reason not to.
That makes the node more useful by default.
One use case is to delete some points after the Set ID node, then instance
with some randomness. Now when deleting different points, the
randomness will remain stable.
Subdivision surface: Both geometry sockets renamed to "Mesh"
Points to Volume: Use "Points" and "Volume" names
Distribute Points on Faces: Use "Mesh" input name
These are meant to provide a hint to users which type each
node is meant to use.
These nodes allow accessing and changing the stable/random ID used
for motion blur with instances and stable randomness.
Since rB40c3b8836b7a, the stable ID is a built-in attribute, so to be
consistent and allow changing it in the node tree like other built-in
attributes, it has get and set nodes.
The call to `attribute_try_get_for_output` does some cache invalidation
internally. Under some circumstances the call to `position_evaluator.evaluate()`
recomputed the caches (e.g. when the Normal node was used, the evaluated
handle positions cache on curves were updated). After the positions have
been updated in the Set Position node, the cache was not invalidated again.,
leading to incorrect rendering.
The proper solution will be to do the cache invalidation in `OutputAttribute.save()`
again. That is a bit more involved though. For now just reorder the code a bit
to do the cache invalidation after the field has been computed.
There is a follow up task: T92509.
Previously, every node had to create warnings for unsupported input
geometry manually. Now this is automated. Nodes just have to specify
the geometry types they support in the node declaration.
Differential Revision: https://developer.blender.org/D12899
Instance IDs serve no purpose for rendering when they aren't stable from
one frame to the next, and if the index is used in the end anyway, there
is no point in storing a vector of IDs and copying it around.
This commit exposes the `id` attribute on the instances component,
makes it optional-- only generated by default with the distribute points
on faces node.
Since the string to curves node only added the index as each instance's
ID, I removed it. This means that it would be necessary to add the ID
data manually if the initial index actually helps (when deleting only
certain characters, for example).
Differential Revision: https://developer.blender.org/D12980
In future use cases, a volume can contain many grids that represent the
density information. In this case, it's better if the volume to mesh node
creates a mesh based on all of the grids in the volume.
This is also a benefit to share-ability, since one doesn't have to
specify the grid name in the node. Instead, in the future we can have
a way to split particular grids into separate volumes, if only one
grid should be considered.
The code changes are relatively simple:
- Move the old volume to mesh node to the legacy folder.
- Run the volume to mesh node on all instance geometry, like elsewhere.
- Make the blenkernel's volume to mesh API a bit more specific.
Differential Revision: https://developer.blender.org/D12997
Previously, the field on every socket was logged for later use. This had
two main negative consequences:
* Increased memory usage, because the fields may contain a lot of data
under some circumstances (e.g. a Ray Cast field contains the target geometry).
* Decreased performance, because anonymous attributes could not be
removed from geometry automatically, because there were still fields that
referenced them.
Now most fields are not logged anymore. Only those that are viewed by a
spreadsheet and constant fields. The required inputs of a field are still
logged in string form to keep socket inspection working.
The viewer node has been expanded to have a field input next to the
geometry input. When both are connected (by ctrl+shift clicking on a node)
the spreadsheet will show the evaluated field on the geometry.
The operator to link to the viewer has become a bit smarter. It automatically
detects if it should link to the geometry or field input. In the future some more
smartness could be added, such as automatically relinking the "right" geometry
when viewing a field.
Internally, there are two major changes:
* Refactor of what happens when ctrl+shift clicking on a node to link to
a viewer. The behavior of the geometry nodes viewer is a bit more complex
than that of the compositor viewers. The behavior in compositing nodes
should not have changed. Any change should be reported as a bug (and then
we can decide if it's worse than before or if it needs fixing).
* Evaluation, display and caching of fields in the spreadsheet editor.
Differential Revision: https://developer.blender.org/D12938
This patch improves performance by only assigning
or calculating data for connected sockets.
It is recommended that artists use the lowest dimensions setting
for noise based textures. E.g. Use 2D instead of 3D where possible.
Using a scoped timer and single thread on 256,000 points.
Smooth F1 3D : Debug build
Timer 'Optimised' took 9.39991 s
Timer 'Normal' took 16.1531 s
This optimisation is only for GN and not shaders.
Differential Revision: https://developer.blender.org/D12985
Also use consistent UI names for properties that are similar between
that node and the points to volume node (which happen to be shorter,
allowing the node to be narrower).
This adds an option to fill the ends of the generated mesh for
each spline combination with an N-gon. The resulting mesh is
manifold, so it can be used for operations like Boolean.
Differential Revision: https://developer.blender.org/D12982
Issue is that the Instance on Points node currently expects that all
instance references are used (see `remove_unused_references`).
This should be fixed at some point, but for now make sure that
the String to Curves node does not output unused references.
This adds a new image texture node for geometry nodes. It does not
reuse the same node that is used in shading, because we want to be
able to expose the image and frame as sockets.
There is a known update issue when a movie or image sequence is
used. That will be fixed separately (also see D12957).
Currently, the image socket is just a pointer to an Image ID data block.
This can contain single images but also movies and image sequences.
In the future, the definition of an image socket can be expanded to
include images that are generated from scratch in the node tree.
For more details read the discussion in D12827.
Some of the code is a direct port from cycles and should be cleaned
up a bit in the future. For example `image_cubic_texture_lookup`.
For still images, the frame input is ignored. Otherwise, the frame
has to be in a valid range for the node to work. In the future we
may add e.g. automatic looping functionality.
Differential Revision: https://developer.blender.org/D12827