Commit Graph

12 Commits

Author SHA1 Message Date
d2869943d2 Nodes: refactor derived node tree
This is a complete rewrite of the derived node tree data structure.
It is a much thinner abstraction about `NodeTreeRef` than before.
This gives the user of the derived node tree more control and allows
for greater introspection capabilities (e.g. before muted nodes were
completely abstracted away; this was convenient, but came with
limitations).

Another nice benefit of the new structure is that it is much cheaper
to build, because it does not inline all nodes and sockets in nested
node groups.

Differential Revision: https://developer.blender.org/D10620
2021-03-06 16:51:06 +01:00
f53221bff7 UI: Allow translation for node error messages
This commit exposes the strings used in the node error messages for
localization. It also changes the message tooltip creation to
automatically add the period at the end, to be more consistent with
the (arguably bad) design of other tooltips in Blender.

Calling `TIP_` directly in the node implementation files allows us to
continue using `std::string` concatenation instead of passing variadic
arguments. It's also more explicit about which part of the message is
translated and which isn't. The files already include the translation
header anyway.
2021-03-03 12:58:33 -06:00
626a8e0f10 Fix T85979: Attribute missing warning with empty geometry
An error doesn't make sense in these situations because we don't expect
to find attributes on empty geometry, and an empty geometry set is a
valid situation.

Note that we can't use `component.is_empty` here, because often the
component is visually "empty" but still has a point cloud with no
points or a mesh with no vertices.
2021-02-25 08:20:02 -06:00
47fc1e11db Nodes: ensure ui storage implicitely
This makes it easier to use the api.
2021-02-19 11:27:40 +01:00
461d4fc1aa Geometry Nodes: Node error messages
This patch adds icons to the right side of nodes when they encounter a
a problem. When hovered, a tooltip displays describing the encountered
while evaluating the node.

Some examples are: attribute doesn't exist, mesh has no faces,
incorrect attribute type, etc. Exposing more messages to the system
will be an ongoing process. Multiple warnings per node are supported.

The system is implemented somewhat generically so that the basic
structure can also be used to store more information from evaluation
for the interface, like a list of available attributes.

Currently the messages are just button tooltips. They could be styled
differently in the future. Another limitation is that every instance of
a node group in a parent node tree will have the same error messages,
the "evaluation context" used to decide when to display the tooltips
must be extended to support node tree paths.

Differential Revision: https://developer.blender.org/D10290
2021-02-16 17:15:08 -06:00
eb2e260540 Cleanup: Used derived node in geometry exec params
Since the derived node tree is already build for the evaluation system,
it's simpler to pass a derived node to the params struct. This will also
allow context lookups in nested node groups for node error messages,
since the derived node has that information readily accessible.
2021-02-16 13:06:18 -06:00
39f60e6909 Geometry Nodes: move some attribute utilities to blenkernel
I need to access these utilities from modifier code as well.
Therefore, they should not live in the nodes module.
2021-02-16 11:55:12 +01:00
d7c2c889a6 Geometry Nodes: Allow attribute nodes to use different domains
Currently every attribute node assumes that the attribute exists on the
"points" domain, so it generally isn't possible to work with attributes
on other domains like edges, polygons, and corners.

This commit adds a heuristic to each attribute node to determine the
correct domain for the result attribute. In general, it works like this:
 - If the output attribute already exists, use that domain.
 - Otherwise, use the highest priority domain of the input attributes.
 - If none of the inputs are attributes, use the default domain (points).

For the implementation I abstracted the check a bit, but in each
node has a slightly different situation, so we end up with slightly
different `get_result_domain` functions in each node. I think this makes
sense, it keeps the code flexible and more easily understandable.

Note that we might eventually want to expose a domain drop-down to some
of the nodes. But that will be a separate discussion; this commit focuses
on making a more useful choice automatically.

Differential Revision: https://developer.blender.org/D10389
2021-02-12 12:46:17 -06:00
a8da70f70a Geometry Nodes: Add boolean attribute in utility function
This follows up rBc484b54453e607, adding the boolean custom property
data type in one more place that was missed.
2020-12-16 12:50:45 -06:00
49ec3cef69 Geometry Nodes: Input data type utility function
This commit adds a simple utility function for getting the data type of an
attribute or its "constant" socket counterparts. No functional changes.

Differential Revision: https://developer.blender.org/D9819
2020-12-14 11:43:54 -06:00
4a5f36638b Geometry Nodes: simplify supporting different input socket types for attributes
This is a non-functional change. The functionality introduced in this commit
is not used in master yet. It is used by nodes that are being developed in
other branches though.
2020-12-09 16:20:57 +01:00
6be56c13e9 Geometry Nodes: initial scattering and geometry nodes
This is the initial merge from the geometry-nodes branch.
Nodes:
* Attribute Math
* Boolean
* Edge Split
* Float Compare
* Object Info
* Point Distribute
* Point Instance
* Random Attribute
* Random Float
* Subdivision Surface
* Transform
* Triangulate

It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier.

Notes on the Generic attribute access API

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).

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.

It includes commits from:
* Dalai Felinto
* Hans Goudey
* Jacques Lucke
* Léo Depoix
2020-12-02 15:38:47 +01:00