Commit Graph

9 Commits

Author SHA1 Message Date
ed1042ee06 Geometry Nodes: cleanup attribute usage
Now that typed attribute wrappers don't need to own the
attribute anymore, many `std::move` calls can be removed.
2021-01-13 12:27:38 +01:00
614bd239f8 Geometry Nodes: support optional ownership for typed attributes
This will simplify some code in an upcoming commit and will be
useful for T83793.
2021-01-13 10:48:39 +01:00
3a254b93fd Geometry Nodes: support reading from spans of WriteAttribute
Previously, the span returned by `WriteAttribute`s might not contain the
current value of the attribute for performance reasons. To avoid some
bugs, the span now always contains the old values (they might have to
be copied over from the internal storage, dependending on how the
attribute is stored).
The old behavior is still available with the `get_span_for_write_only`
method. The span that it returns might not contain the current
attribute values. Therefore, it should only be used when you want
to overwrite an attribute without looking at the old values.
2021-01-12 12:50:29 +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
b347c4e9ca Cleanup: remove redundant struct declarations 2020-12-16 16:25:56 +11: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
2c181521ec Geometry Nodes: add custom data type getter for attribute accessor
This is just an utility method, that avoids that the caller has to do
the conversion every time it is necessary.
2020-12-03 16:20:09 +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