During the development of the new nodes in the `geometry-nodes` branch
the color of the new nodes wasn't considered, so all of the nodes ended
up red, the color for "input" nodes. This patch introduces two new
colors, one for "Geometry" and one for "Attributes". There are only two
attribute nodes currently, but the next sprint will add two more,
attribute mix, and sample from texture. The attribute nodes are
conceptually different enough from the nodes that modify the geometry
that they deserve their own color.
Differential Revision: https://developer.blender.org/D9682
The modifier was called "Empty", which reflects the fact that the modifier
doesn't do anything when you add it. However, that is not true after you
change the modifier's node group, and the fact that the modifier uses
nodes is the one thing that distinguishes it at this point. This commit
changes the name to "Geometry Nodes", which is simple and consistent
with the "Geometry Node Editor" and the naming of the project so far.
The handling of muted nodes is handled at the derived node tree
level now. This is also where expanding node groups is handled.
Muted nodes are relinked and removed from the derived tree
during construction. The geometry node evaluation code does
not have to know about muted nodes this way.
Note: This also changes the Shader socket color, to match "Shading" in the Outliner.
Theme update for shader nodes will be committed separately.
Related to T82689
Before, attributes could only be accessed via setter and getter functions.
While this works well, it can be cumbersome and slow.
It would be better if most code could just operate on the underlying
attribute array directly. The issue is that some attributes are currently
not stored in plain arrays (e.g. vertex positions, vertex groups, ...).
This patch implements a solution where these "special" attributes are
converted into a temporary array for easy access and then copied
back into their correct form after all modifications are done.
Attribute accessors now have a `get_span` and `apply_span` method,
which can be used exactly for that purpose. In the case of attributes
that are plain arrays internally, only small constant overhead is added.
Material indices and smooth states are not destroyed anymore.
If the two incoming meshes use different materials, the materials of
the first input will be used. This is obviously not ideal, because the
second input might change its material.
In the future we want to handle that differently and keep both materials,
but for now this is consistent with the boolean node.
This commit makes the way the selector in the middle of the node editor
header interacts with the active modifier much more intuitive.
- With no active modifier, or when the active modifier is a non-node
modifier, the "new" operator adds a new nodes modifier.
- With an active node modifier, the drop-down affects the modifier's
selected node group.
- With no active object, there is no drop-down in the header.
- The node editor's node group always updates, even when there is no
active modifier.
- Pinning disables the drop-down and keeps the same node group
selected, regardless of the context.
This is designed to work similarly to materials and material slots,
which should be familiar to any Blender user. One workflow not allowed
by this design is editing any geometry node group, regardless of the
context, but if that turns out to be an issue it should be solved in a
similar way for all node editors.
This adds "modifier" as a new context variable in the property editor.
It is used instead of getting the active modifier directly. This way it
displays in the breadcrumbs panel, and the variable can be set only
in the modifier tab, meaning it won't work from the shortcut even
when the modifiers aren't visible.
While we can support different domains already in this node, there is not
really anything you could do with that data yet. It can be added back when
there is a use case for it.
Currently, implementing a node that supports math operations requires
you to write a long switch statement. The goal of this abstraction
is to reduce the number of these switch statements.
Note, this commit adds new such long switch cases. However, in the upcoming
commits existing math nodes are updated to use this abstraction, resulting in
less code overall.
Based on discussion with the team, summarized in T82691, it makes sense
to simplify the shortcut behavior and remove the way the shortcuts
currently activate on hover if there is no active modifier. This commit
also removes the behavior of clearing the active modifier when you
click on blank space in the modifier tab.
This commit includes these improvements to operators and how they
relate to the active modifier:
- Shortcuts performed while there is an active modifier will affect
only that modifier.
- Clicking anywhere on the empty space in a modifier's panel will make
it active.
- Clicking anywhere in the empty properties space will clear the
active.
These changes require some refactoring of object modifier code. First
is splitting up the modifier property invoke callback, which now needs
to be able to get the active modifier separately from the hovered
modifier for the different operators. Second is a change to removing
modifiers, where there is now a separate function to remove a modifier
from an object's list, in order to handle changing the active. Finally
the panel handler neeeds a small tweak so that this "click in panel"
event can be handled afterwards.
This provide a simple implementation for basic math operations. Add,
subtract, multiple, and divide are implemented so far. Domain
interpolation is not implemented yet either.
This commit also adds two "Type" options to the node for choosing
explicitly whether to use an attribute or a float value as one of the
inputs. It is not possible to use two floats as inputs, because that
would be a regular math node.
Some cleanup to avoid some code duplication will come in a future
commit.
This node creates a new geometry based on two incoming geometries.
In the future the node ui can be extended to support more than two inputs.
The output geometry will have all the attributes of the inputs.
If both inputs have non-matching set of attributes, missing data is either
interpolated, type cast or zeroed.
Ref T82786.
* It now knows its own component type.
* Add virtual method to check if the component is empty.
* Add virtual methods to find all attribute names.
* Support adding existing components to a geometry set.
This changes the meaning of the order of the two geometry input sockets
to match the existing boolean modifier. The first socket is now the base
mesh and the second socket is the "cutter" geometry.
Similar to how the node editor context works for materials, this commit
makes the node group displayed in the node editor depend on the active
object and its active modifier. To keep the node group from changing,
just pin the node group in the header.
There are still missing updates when switching the modifier's node group.
This exposes the operator to set the active modifier as the type icon
in the header of the modifier panels. Tweaks to the widget drawing
code were necessary to use the red alert for non-emboss operator
buttons. Then, the panel for the active modifier gets a border around it
(which currently uses the property search theme color), requiring
an "active property" field in the PanelType struct.
Previously, it was always outputting an empty geometry in that case.
This was confusing because e.g. the output of a union operation
with a single non-empty mesh is also non-empty.
This will probably not stay exactly like this, because it looks a bit ugly.
Adding this now, because it increases flexibility a lot and allows me
to test the attribute api a bit more.
Originally, there were technical reasons for why two different domains
were used. Those reasons have been lost unfortunately, and there
don't seem to be any issues with combining the domains now.
This reduces confusion when users have to select the domain type
in enums.
Attributes can now be accessed through a GeometryComponent.
MeshComponent and PointCloudComponent implement the specific
attribute access mechanisms using virtual methods.
This simplifies code that should work on different geometry components
quite a bit, because it only has to be written once without using templates.
The Random Attribute node benefits from that a lot.
Although disabling this option is equivalent to setting the edge angle
to 180 degrees, there is no great reason to change the settings from what
is exposed in the modifier.
Differential Revision: https://developer.blender.org/D9564
The random attribute node currently doesn't support every attribute
domain or data type. With a bit of boilerplate code we can remove these
unsupported enum items from the UI for now, and also get a system to
remove unsupported items from the UI in the future. If all attribute
creation nodes end up always supporting all attibute types and domains,
this can be removed.
There will be an operator to access this property instead, which provides
a better name and tooltip to expose in the UI, and makes it more clear
that the property is dependent on the other modifiers.
This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.
This adds some ui boilerplate code for the Random Attribute node and
provides an initial implementation.
Note, while the implementation can already randomize attributes, it might
not behave as expected under all circumstances yet. It's still work in progress.
I will have to do a couple more iterations on this api in the upcoming weeks,
but for now it should be good enough.
The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).
Accessing attributes through this indirection does have a performance penalty.
In later iterations of this API I want to reduce this penalty and extend the API
so that performance critical code does not have to go through the indirection
for every attribute access.
Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.
Until there is a icon made specially for this, the nodetree icon is up
for grabs. Using it in the nodegroup + modifier + editor helps the users
to make a connection on where to edit those modifiers.
The point cloud object is the only one that will support instancing at
first. So we can expose it as a regular object.
It is limited since it has no edit mode. But this is not different than
the volume object.
As part of preparing this work for master, with an initial subset of
working functionalities the Geometry Nodes Editor can be exposed for
everyone.
(it also helps people that are testing the branch)
Previously, GeometrySets and GeometryComponents has reference
counters and could be shared. This commit changes it so that
only GeometryComponents are shared. A GeometrySet is a fairly
small type that is cheap to copy.
A lot of code simplifies when we can assume that GeometrySet
is cheap to copy.
Brecht and I decided to move the GeometrySet classes
to the global namespace for now. This way we can use
the same type in C and C++ and don't have to use
reinterpret_cast as often.
More than output for the modifier's node group is fine, because the
node group may be used in other situations, but the modifier will
not work if there is no geometry output socket.
Bypassing the macro that creates modifiers to allow the enum to be
referring to the Empty modifier, but the internal struct in the code to
be Nodes.
Also fix the name of the new created modifiers to be "Empty".
Fix was built with rBb458ea6b23381a9acb90dbbd73ced678e1d404c5.
Leave the internal DNA data struct as "Nodes", and only rename the
modifier and user interface to Empty.
See 4a2734a835 for the original take and the reasoning
for renaming from Nodes to Empty.
This diff remove "Combine Strings" and "Group Instance ID" nodes from the UI (but keep them in the source code to be able to bring them back if needed).
This is part of "Cleanup 1st Sprint Nodes" (https://developer.blender.org/T82370).
Differential Revision: https://developer.blender.org/D9558
This introduces a regression. Users need to re-create their modifiers
and set their values again. The NodeGroups are intact so all they need
is to create new "Empty" modifiers and set the node group.
---
Original problem: Eventually most modifiers will be node-based, so naming
this new modifier "Nodes" will get outdated pretty quickly.
Calling it "Empty" it's fairly descriptive, since the node tree simply connects
the modifier Input to an Output, without any effect.
There is a potential problem, that it could be associated with the
Empty object type. Like some sort of Hook.
This is the task T82700, and the design task T82537.
This implements a workaround for the issue that (for historical reasons)
the names of vertex groups are stored on the object while the actual vertex
group data is stored on the mesh.
The solution is to copy the vertex group names from the object into
the `MeshComponent` so that the information is not lost, when the
object cannot be accessed.
Previously, the execution function of a geometry node has three parameters.
Now it has only one. This makes it easier to pass more information to the
execution function, that might only be used by a few nodes, because we
don't have to add more parameters that are unused in most cases.
* Support vertex weights to control density.
* O(n) performance instead of O(n^2).
* More stable when density weights are changed.
The vertex group has to be specified using an index for now.
This is a technical limitation that will resolved a bit later.
Objects can evaluate to a geometry set instead of a single ID (only point cloud
objects for now). In the depsgraph object iterator, those geometry components
are expanded into temporary objects.
It's important to note that instanced objects can also contain geometry
components. Therefore, they have to be split up into multiple objects
as well in some cases.
At a high level the iterator works like so:
```
for object in depsgraph:
for component in object:
yield object_from_component(component)
for dupli in make_duplis_list(object):
for component in dupli:
yield object_from_component(component)
```
DEG_iterator_objects_next has been cleaned up, to make this structure
a bit more apparent.
This changes the signature of the modifyPointCloud function.
I'm doing that instead of making a new callback, because it requires
changes to significantly fewer files. Eventually it would be good
combine modifyMesh, modifyHair, modifyPointCloud and modifyVolume
into one modifyGeometrySet.
I temporarily disabled the displacement only modifiers for point clouds.
Support can be added back a bit later. I assume those have not been
used anywhere anyway.
The output of point cloud modifiers can not only be another point cloud,
but also a mesh and/or some instances. I added a new geometry_set_eval
field to Object_Runtime. For point cloud objects, the final geometry is
now referenced by that pointer instead of data_eval. The data_eval field
is still initialized after modifier evaluation to make some other code happy.
The evaluated geometry set is not yet passed to the renderer, so a point
cloud is currently rendered empty.
This node takes an object as input and outputs its location, rotation,
scale and geometry. Right now the loc/rot/scale are extracted from the
objects `obmat`. The geometry is just the mesh in the local space of the
source object.
We will likely need some more control over space transformations
using enums in the node, but those can be added a bit later.
The fundamental difference between object sockets and the
other existing data sockets is that an object is an ID data block.
Changing the value of an object socket also changes the depsgraph.
The modifier has to analyse the node tree to figure out which other
objects it depends on. Currently, this is done very simply by just
looping over all sockets and collecting the objects. In the future
this can be improved by also figuring out what components of
an object are needed.
Instead of passing object pointers around in the node tree, we actually
use a handle. This handle is just a number internally that identifies
a specific object. The conversion between handles and object pointers
is done using a map that is provided by the modifier.
This approach has a couple of benefits. It protects us a bit from passing
around pointers that are not known to the modifier and therefore are
not in the depsgraph. Furthermore, the object pointer can change
while the handle stays the same. This is not important right now, but
is not unlikely to become useful in the future.
The API for how nodes access object pointers is not ideal yet and
will be improved in the future.
This commits implements multiple changes:
* Adds a simple C API.
* Improves the ownership handling by introducing GeometryOwnershipType.
* Adds an InstancesComponent that stores positions and Object pointers.
This should not change any functionality.
After talking to Brecht, we agreed that it might be good
not to have a class called Geometry for now. In the future
we might want to use a Geometry class as base class for
meshes, curves, etc.
This commit renames the Geometry class to GeometrySet,
because it is essentially a container that can contain
multiple geometries of different types.
This node is similar to the subdivision surface modifier. It subdivides
the mesh component of a geometry. The options have the same meaning
as in the modifier.
Differential Revision: https://developer.blender.org/D9364
Naming based on supported geometry components only works in some cases.
For nodes that work with multiple data types, it's better to categorize
them based on their functionality.
Theoretically the modifier's properties could be changed or removed by
Python, so it may be useful to have errors printed and added to the
modifier in that case.
I kept the check as a separate step from the `compute_geometry`
pass because the object is needed to set the modifier error message.
But it could easily be moved there in the future.
If we add the "name" label manually with uiItemR, we can use the socket
identifier instead of the name for the IDProperty name. This will also
allow us more flexibility in how to draw the settings in the future, and
removes the empty _RNA_UI proprety that was drawn before.
The system for exposing property settings like min, max, default, subtype,
etc. for ID properties is quite convoluted currently, so I won't give a
full description here, but this commit creates the tree of ID properties
needed to store that information. This means that property subtypes like
"angle" or "XYZ" will affect the display in the modifier.
Limitations:
- The _RNA_UI property is displayed in the modifier. This may require a
modification to uiDefAutoButsRNA to fix.
- IDProperties must have unique names, but node sockets don't have
that limitation. This can be solved by adding a "UI name" field to
IDProperties.
We can't use that for now, because the original mesh might be freed
before the new copied mesh. When the original mesh is freed, the shared
layers will be freed as well.
This can probably be improved in the future, so that we can actually
share attribute arrays between meshes. An approach similar to how
geometries and components are shared should work as well.
A geometry now contains zero or more geometry components.
A geometry component is a subclass off GeometryComponent.
Currently, there is a MeshComponent and PointCloudComponent.
A geometry contains at most one component of each type.
Individual components can be shared between multiple geometries
to avoid unnecessary copies. For that, each component has a user
count that determines when the component will be freed and whether
it is mutable.
Code working with geometries can either work with the components
directly, or use the utility functions on the geometry that cover the
most common operations.
In the future, additional component types can be added. For example,
we'll probably need components for curves and volumes.
Furthermore, something like an InstancesComponent can be added,
which contains points with attributes and references a geometry/object/collection
that is instanced on all the points.
The execute callback of a geometry node gets more domain specific
types as parameters now: GeoNodeInputs and GeoNodeOutputs.
Those types are also aware of what node is being executed and can
provide better error messages when they are used incorrectly.
The first is a "Point Distribute" node, which takes a mesh and outputs a
pointcloud, scattering points randomly on the surface based on the input
density. The distribution algorithm is extremely basic at this point, and
doesn't take into account an attribute weight at each vertex.
The second node is a "Point Instance" node, which is mainly a placeholder
until the engineering design for how to work with instancing in geometry
nodes is decided. For now it just runs the same code that the convert
pointcloud to mesh operator uses.
This adds another set of the same mesh functions but for pointclouds.
There are probably better ways to generalize this functionality, but that
may have to be rethought in the future anyway if we want to store
multiple of each type. And anyway it's handy to have a specific set of
"pointcloud" functions available in the node implementations.
This uses the code from the rewritten boolean modifier from 2.91 as a node.
The implementation is about as minimal as it can get, since for now the use
case of this node is mostly to test multiple geometry outputs and inputs.
The boolean code requires a BMesh, so the node converts the input meshes
to BMesh, so the bmesh is added as a dependency to the nodes module.
The settings can only be set via Python currently. The matching between properties
and group inputs is based on the socket identifier (which is e.g. `Input_5`).
Maybe we'll have to use a different matching strategy in the future, will see.
The properties are not used yet, but can already be accessed with Python
using `modifier.settings['setting name']`.
The plan is to use id properties to store the parameters that the modifier
passes into the geometry node group.
Group inputs are not yet exposed in the modifier. For now I just added
a simple float setting that will be passed to every float input of the group.
Inputs of other types have some default value.
We might not want to have all those nodes in a final version.
Some of them have been added with particle nodes in mind.
However, to test the evaluation system it is useful to have a
couple of nodes available.
Those nodes should "just" work, because their implementation
is reused from the particle nodes project.
This adds support for nodes that have a multi-function implementation.
That includes various function nodes like Math, Combine Vector, ...
Furthermore, there is support for implicit conversions now. So it should
work when one connects e.g. a float to an integer and vice versa.
These two functions "snode_notify" and "ED_node_tag_update_id" appear to
be mostly duplicates. However, there is already a case for each type of
built-in node tree, so it makes sense to add one for the geometry node
tree as well. This doesn't solve the update issues for changing number
in buttons, that must be handled somewhere else.
This adds a layer of abstraction between the code calling callbacks
on sockets and the implementation of those callbacks.
This abstraction layer allows some sockets to not implement all
callbacks when those can be derived from some other callback.
This is still very basic and does quite a few unnecessary computations.
Also the error handling is quite weak currently, so when invalid things are
connected, it will probably just crash.
Also the interface that individual nodes have to implement will have to change,
but the current solution is a good starting point.
Only the triangulate node is implemented for now.
