| Age | Commit message (Collapse) | Author |
|---|
|
There isn't really a reason for why this has to return a copy of
the data instead of a reference.
|
|
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
|
|
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.
|
|
I need to access this functionality from modifier code. Therefore it should
not be in the nodes module.
|
|
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
|
|
Normally sockets only have one input link. This commit adds the back-end
changes needed to use multiple input links per socket.
Multi-input sockets can be defined with a new flag in `bNodeSocketType`.
The changes necessary to make the sockets work in the geometry nodes
evaluator are generalizing input socket values as a vector of values,
and supporting this in the derived node tree structure.
This patch should contain no functional changes. Two upcoming patches
will use this system for the "Join Geometry" node and expose link picking
and updated display in the UI: D10069 and D10181.
Reviewed By: Jacques Lucke, Hans Goudey
Differential Revision: https://developer.blender.org/D10067
|
|
This node allows sampling a texture for every vertex based on some
mapping attribute. Typical attribute names are the name of a uv map
(e.g. "UVMap") and "position". However, every attribute that can be
converted to a vector implicitly is supported.
It should be noted that as of right now, uv map attributes can only be
accessed after a Point Distribute node.
Ref T82584.
Differential Revision: https://developer.blender.org/D10121
|
|
The depsgraph will have to be accessed in an upcoming patch.
|
|
Undefined geometry nodes will just output a default value now.
|
|
Currently, the random attribute node doesn't work well for most
workflows because for any change in the input data it outputs
completely different results.
This patch adds an implicit seed attribute input to the node, referred
to by "id". The attribute is hashed for each element using the CPPType
system's hash method, meaning the attribute can have any data type.
Supporting any data type is also important so any attribute can be
copied into the "id" attribute and used as a seed.
The "id" attribute is an example of a "reserved name" attribute,
meaning attributes with this name can be used implicitly by nodes like
the random attribute node. Although it makes it a bit more difficult
to dig deeper, using the name implicitly rather than exposing it as an
input should make the system more accessible and predictable.
Differential Revision: https://developer.blender.org/D9832
|
|
This adds a boolean attribute and custom data type, to be used in the
point separate node. It also adds it as supported data types in the
random attribute and attribute fill nodes.
There are more clever ways of storing a boolean attribute that make
more sense in certain situations-- sets, bitfields, and others, this
commit keeps it simple, saving those changes for when there is a proper
use case for them. In any case, we will still probably always want the
idea of a boolean attribute.
Differential Revision: https://developer.blender.org/D9818
|
|
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
|
|
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.
|
|
* Add typed attribute accessors for color attributes.
* Support implicit conversions between colors and floats.
|
|
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
|
