Commit Graph

4 Commits

Author SHA1 Message Date
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