Commit Graph

8 Commits

Author SHA1 Message Date
9a32c7130b Geometry Nodes: pass depsgraph to nodes during execution
The depsgraph will have to be accessed in an upcoming patch.
2021-01-19 16:58:05 +01:00
c5569ba140 Geometry Nodes: do not crash when there are undefined nodes
Undefined geometry nodes will just output a default value now.
2020-12-18 13:28:55 +01:00
c9f8f7915f Geometry Nodes: Make random attribute node stable
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
2020-12-17 07:43:31 -06:00
c484b54453 Geometry Nodes: Boolean attribute type
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
2020-12-16 12:33:13 -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
107231eb95 Geometry Nodes: improve support for Color attributes
* Add typed attribute accessors for color attributes.
* Support implicit conversions between colors and floats.
2020-12-03 16:25:48 +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