Previously, some multi-functions were allocated in a resource scope.
This was fine as long as the multi-functions were only needed during
the current evaluation of the node tree. However, now cases arise
that require the multi-functions to be alive after the modifier is finished.
For example, we want to evaluate fields created with geometry nodes
outside of geometry nodes.
To make this work, `std::shared_ptr` has to be used in a few more places.
Realistically, this shouldn't have a noticable impact on performance.
If this does become a bottleneck in the future, we can think about ways
to make this work without using `shared_ptr` for multi-functions that
are only used once.
Back in Blender 2.30, the GUI project brought panels into Blender among other important visual updates.
For the first time it was possible to move the wall of buttons around. Providing a clear separation
between sections (it even allowed the grouping of panels in tabs!)
During the 2.5 redesign, the separation between panels became a line on top of each panel, and panels received
theme settings for background and header colors. The default theme used the same color for both.
In 2.8 the background color of panels was different from headers in the default theme, so the separator
line was removed. While the separator line wasn't elegant (only on top, non-themeable, hard-coded emboss effect),
it provided a sort of separation between panels.
This patch solves the panels-separation by simply adding a margin space around them (not visible in default theme yet).
Even though the margin reduces the width of the working area slightly, it makes room for the upcoming always-visible scrollbars.
Other adjustments:
* Use arrow icon instead of triangle to collapse/expand
* Use rounded corners to match the rest of the UI (editor corners, nodes, etc).
{F10953929, size=full}
Margin on panels makes use of the `style->panelouter` property that hasn't been
used in a while. Also slight tweaks to `boxspace` and `templatespace` style properties so they
are multiples of 2 and operations on them round better.
There is technically no need to update the themes for them to work, so no theme changes are included in this patch.
{F10953931, size=full}
{F10953933, size=full}
{F10953934, size=full}
{F10954003, size=full}
----
A new theme setting under Style controls the roundness of all panels (added it to Style instead of ThemeSpace because I think controlling the panel roundness per editor is a bit overkill):
{F11091561, size=full, autoplay, loop}
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D12814
Instead of checking whether the socket value was hidden, use the proper
node declaration to check whether the socket has an implicit input. The
remaining larger change to make is allowing nodes to specify what their
implicit input should actually be.
The sockets are not exposed in any nodes yet.
They work similar to the Object/Collection/Texture sockets,
which also just reference a data block.
Based on rB207472930834
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D12861
This commit implements T91780, adding nodes to get and set builtin
attributes. Individual set nodes are used so that the values can be
exposed for direct editing, which is useful for attributes like shade
smooth and spline resolution. Individual input nodes are used to allow
reusing nodes for multiple components, and to allow grouping multiple
outputs conceptually in the same node in the future.
Input Nodes
- Radius
- Curve Tilt
- Curve Handle Positions
- Is Shade Smooth
- Spline Resolution
- Is Spline Cyclic
'Set' Nodes
- Curve Radius
- Point Radius
- Curve Tilt
- Curve Handle Positions
- Is Shade Smooth
- Spline Resolution
- Is Spline Cyclic
Using hardcoded categories is necessary to add separators to the node
menu.
Differential Revision: https://developer.blender.org/D12687
I've seen requests to remove this or complaints about this error message
quite frequently. In lots of production files it's just always going off.
It's not an actionable warning, and since "slow" is relative, it isn't
always even correct.
Differential Revision: https://developer.blender.org/D12694
Add a fields-aware implementation of the attribute proximity node.
The Source position is an implicit position field, but can be
connected with a position input node with alterations before use.
The target input and mode function the same as the original node.
Patch by Johnny Matthews with edits from Hans Goudey (@HooglyBoogly).
Differential Revision: https://developer.blender.org/D12635
This enables fields as the official workflow for geometry nodes.
While many features are converted to use fields rather than the old
attribute workflow, many are not yet converted. In that case, the
unconverted nodes are still accessible with an experimental option.
In the coming weeks the rest of the nodes will be converted.
Differential Revision: https://developer.blender.org/D12672
This commit adds nodes to do direct conversion between meshes and point
clouds in geometry nodes. The conversion from mesh to points is helpful
to instance once per face, or once per edge, which was previously only
possibly with ugly work-arounds. Fields can be evaluated on the mesh
to pass them to the points with the attribute capture node.
The other conversion, point cloud to mesh vertices, is a bit less
obvious, though it is still a common request from users. It's helpful
for flexibility when passing data around, better visualization in the
viewport (and in the future, cycles), and the simplicity of points.
This is a step towards T91754, where point clouds are currently
combined with meshes when outputing to the next modifier after geometry
nodes. Since we're removing the implicit behavior for realizing
instances, it feels natural to use an explicit node to convert points
to vertices too.
Differential Revision: https://developer.blender.org/D12657
Change the toggle to switch between an attribute and a single value to
only display for inputs that are fields, as determined statically by
the field inferencing added in rB61f3d4eb7c7db7. This means the field
inferencing must be calculated on file load, since it's used in the UI.
Differential Revision: https://developer.blender.org/D12623
Particle copying code was already properly sharing pointcache between
orig data and its copy only when `LIB_ID_COPY_SET_COPIED_ON_WRITE` is
set, do the same for the other point cache users.
Using `LIB_ID_CREATE_NO_MAIN` here is waaaaaaay to much wide scope for
such a dangerous/advanced behavior, that kind of things has to be
strictly restricted in scope.
In a sub-panel it will be clearer that they are outputs, since they
just look like more inputs now. Unfortunately it is not possible to
make sub-panels display conditionally currently, so the output
sub-panel will always be visible whether or not it is empty.
Differential Revision: https://developer.blender.org/D12653
This patch allows passing a field to the modifier as output. In the
modifier, the user can choose an attribute name. The attribute
will be filled with values computed by the field. This only works
for realized mesh/curve/point data. As mentioned in T91376, the
output domain is selected in the node group itself. We might want
to add this functionality to the modifier later as well, but not now.
Differential Revision: https://developer.blender.org/D12644
This adds a new Instance on Points node that is a replacement
for the old Point Instance node. Contrary to the old node,
it does not have a mode to instance objects or collections
directly. Instead, the node has to be used with an Object/
Collection Info to achieve the same effect.
Rotation and scale of the instances can be adjusted in the node
directly or can be controlled with a field to get some variation
between instances.
The node supports placing different instances on different points.
The user has control over which instance is placed on which point
using an Instance Index input. If that functionality is used, the
Instance Geometry has to contain multiple instances that can are
instanced separately.
Differential Revision: https://developer.blender.org/D12478
This node replaces the deprecated Attribute Randomize node, populating
a vector, float, integer or boolean field with random values. Vector,
float, and integer have min/max settings, which are also field aware.
The boolean type has a probability value for controlling what portion
of the output should be true. All four types have a field seed input
which is implicitly driven by the index, otherwise, all values would
be the same "random" value.
The Random Float node is now deprecated like other nodes, since it is
redundant with this node.
Differential Revision: https://developer.blender.org/D12603
This commit adds warning messages to "legacy" nodes that will be
removed in the future. The warning is shown in the node header, but
it is not printed in the terminal or displayed in the modifier. It is
also not propogated to node groups, but that is a more general task.
If the modifier's node tree has executed a deprecated node, it will
display a warning and a "Search" button that will select the nodes and
pan to them in the node editor. This doesn't open child node trees and
select nodes in there, because I want to keep this operator simple and
avoid wasting a lot of time perfecting this behavior.
Differential Revision: https://developer.blender.org/D12454
This change makes the Set Position node do nothing by default.
Before, the geometry would always disappear, because it all points
would be moved to (0, 0, 0).
Differential Revision: https://developer.blender.org/D12553
An issue with the previous commit-- the default value of the type was
used instead of the property value when the "use_attribute" property
was missing.
This adds a toggle to node group inputs exposed in the modifier to use
an attribute instead of a single value. When the toggle is pressed, the
button switches to a text button to choose an attribute name. Attribute
search isn't implemented here yet.
One confusing thing is that some values can't be driven by attributes
at all, like the size of a primitive node. In that case, we should have
a node warning, but that will be separate since it's more general.
We can also have an option to turn off this toggle in node group
input settings.
The two new properties for each input are stored with the same name
as the value, but with `"_use_attribute"` and `"_attribute_name"``
suffixes. The properties are not added for socket types that don't
support attribute input, like object sockets.
Differential Revision: https://developer.blender.org/D12504
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
Since fields were committed to master, socket inspection did
not work correctly for all socket types anymore. Now the same
functionality as before is back. Furthermore, fields that depend
on some input will now show the inputs in the socket inspection.
I added support for evaluating constant fields more immediately.
This has the benefit that the same constant field is not evaluated
more than once. It also helps with making the field independent
of the multi-functions that it uses. We might still want to change
the ownership handling for the multi-functions of nodes a bit,
but that can be done separately.
Differential Revision: https://developer.blender.org/D12444
Previously fluid simulation and Alembic modifiers had a dedicated function
to query the velocity for motion blur. Now use a more generic system where
those modifiers output a velocity attribute.
Advantages:
* Geometry and particle nodes can output velocity through the same mechanism,
or read the attribute coming from earlier modifiers.
* The velocity can be preserved through modifiers like subdivision surface or
auto smooth.
* USD and Alembic previously only output velocity from fluid simulation, now
they work with velocity from other sources too.
* Simplifies the code for renderers like Cycles and exporters like
Alembic and USD.
This breaks compatibility:
* External renderers and exporters accessing these velocities through the
Python API now need to use the attribute instead.
* Existing modifier node setups that create an attribute named "velocity"
will render differently with motion blur.
Differential Revision: https://developer.blender.org/D12305
This commit allows connecting color sockets to the group input and
changing the input values in the modifier. Before there was an error
since this was more complicated to support with the previous IDProperty
UI data storage method.
Differential Revision: https://developer.blender.org/D12437
This implements the initial core framework for fields and anonymous
attributes (also see T91274).
The new functionality is hidden behind the "Geometry Nodes Fields"
feature flag. When enabled in the user preferences, the following
new nodes become available: `Position`, `Index`, `Normal`,
`Set Position` and `Attribute Capture`.
Socket inspection has not been updated to work with fields yet.
Besides these changes at the user level, this patch contains the
ground work for:
* building and evaluating fields at run-time (`FN_fields.hh`) and
* creating and accessing anonymous attributes on geometry
(`BKE_anonymous_attribute.h`).
For evaluating fields we use a new so called multi-function procedure
(`FN_multi_function_procedure.hh`). It allows composing multi-functions
in arbitrary ways and supports efficient evaluation as is required by
fields. See `FN_multi_function_procedure.hh` for more details on how
this evaluation mechanism can be used.
A new `AttributeIDRef` has been added which allows handling named
and anonymous attributes in the same way in many places.
Hans and I worked on this patch together.
Differential Revision: https://developer.blender.org/D12414
Allow blending the imported cache with the modifiers stack above the
MeshCache modifier.
This is particularly useful for instance when dealing with cloth
simulations performed in another software, where some parts of the cloth
are completely pinned (non-simulated, following the armature). Indeed,
this would allow modifying the animation in some areas without having to
rebake the other parts or the cloth, resulting in a much more flexible
workflow.
Reviewed By: #modeling, campbellbarton, mont29
Ref D9898
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
Add an option to the mask modifier to use the vertex weights to generate
smooth in between geometry, instead of just deleting non complete faces.
This can be used to make all sorts of smooth dissolve animations
directly with geometry, which are usually hacked together with shaders.
It also allows for implicit function plotting using geometry nodes and
boolean like operations on non manifold geometry with the proximity
modifier.
Reviewed By: campbellbarton
Ref D10979
The multi-function network system was able to compose multiple
multi-functions into a new one and to evaluate that efficiently.
This functionality was heavily used by the particle nodes prototype
a year ago. However, since then we only used multi-functions
without the need to compose them in geometry nodes.
The upcoming "fields" in geometry nodes will need a way to
compose multi-functions again. Unfortunately, the code removed
in this commit was not ideal for this different kind of function
composition. I've been working on an alternative that will be added
separately when it becomes needed.
I've had to update all the function nodes, because their interface
depended on the multi-function network data structure a bit.
The actual multi-function implementations are still the same though.
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
