Blender Git Loki

Geometry Nodes: Categories for the nodes

See T82367. There is some ongoing discussion about Attributes vs
Attribute. But it is settle to Attribute, so it matches Color, Vector
and Geometry.

Geometry Nodes: T82701 Name for initial Node Groups

Rename it from "Geometry Node Group" to "Geometry Nodes". This is
shorter and equality descriptive.

Geometry Nodes - Internal rename + API change: NODES for anything but UI

Most of the times the nodes will be non-empty. Empty is really only what
shows in the UI.

Geometry Nodes: transform geometry in Object Info node

Geometry Nodes: give nodes access to object that is being modified

Geometry Nodes: simplify attributes api and support deletion

The main difference is that the functions to access attributes have
been moved to MeshComponent and PointCloudComponent.

Geometry Nodes: support controlling instance scale in point instancer node

Geometry Nodes: support point cloud component in random attribute node

Geometry Nodes: support rotation and scale in instances component

Geometry Nodes: fix memory leak

Geometry Nodes: initial Random Attribute node

This adds some ui boilerplate code for the Random Attribute node and
provides an initial implementation.

Note, while the implementation can already randomize attributes, it might
not behave as expected under all circumstances yet. It's still work in progress.

Geometry Nodes: use attribute api in point instance node

Geometry Nodes: use attribute api in point distribute node

Geometry Nodes: initial generic attribute access API

I will have to do a couple more iterations on this api in the upcoming weeks,
but for now it should be good enough.

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

Accessing attributes through this indirection does have a performance penalty.
In later iterations of this API I want to reduce this penalty and extend the API
so that performance critical code does not have to go through the indirection
for every attribute access.

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.

Functions: add float2 cpp type

Merge remote-tracking branch 'origin/master' into geometry-nodes

Cleanup: Remove all of "#ifdef WITH_POINT_CLOUD"

Since Point Cloud was removed from experimental this is no longer needed.

Geometry Nodes: Unify icons -> use ICON_NODETREE for everything

Until there is a icon made specially for this, the nodetree icon is up
for grabs. Using it in the nodegroup + modifier + editor helps the users
to make a connection on where to edit those modifiers.

Cleanup: Remove most of "#ifdef WITH_GEOMETRY_NODES"

The ones around the simulation datablock are still there, since they are not
needed for the features planned for master yet.

Remove Point Cloud object from experimental

The point cloud object is the only one that will support instancing at
first. So we can expose it as a regular object.

It is limited since it has no edit mode. But this is not different than
the volume object.