Blender Git Loki

Blender Git "geometry-nodes-active-modifier-drawing" branch commits.

November 19, 2020, 20:21 (GMT)
Geometry Nodes: Expose the active modifier to the UI

This exposes the operator to set the active modifier as the type icon
in the header of the modifier panels. Tweaks to the widget drawing
code were necessary to use the red alert for non-emboss operator
buttons. Then, the panel for the active modifier gets a border around it
(which currently uses the property search theme color), requiring
an "active property" field in the PanelType struct.
November 19, 2020, 19:47 (GMT)
Geometry Nodes: Add an operator to set the active modifer

Also make new modifiers active, and properly set the active
state when duplicating a modifier.
November 19, 2020, 19:44 (GMT)
Geometry Nodes: Disallow editing and animating modifier active property

There will be an operator to access this property instead, which provides
a better name and tooltip to expose in the UI, and makes it more clear
that the property is dependent on the other modifiers.
November 19, 2020, 19:35 (GMT)
Geometry Nodes: Add the concept of an active modifier

This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.
November 19, 2020, 16:41 (GMT)
Cleanup: use struct instead of class
November 19, 2020, 16:38 (GMT)
Merge branch 'master' into geometry-nodes
November 19, 2020, 16:21 (GMT)
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.
November 19, 2020, 15:59 (GMT)
Geometry Nodes: T82701 Name for initial Node Groups

Rename it from "Geometry Node Group" to "Geometry Nodes". This is
shorter and equality descriptive.
November 19, 2020, 15:11 (GMT)
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.
November 19, 2020, 12:40 (GMT)
Geometry Nodes: transform geometry in Object Info node
November 19, 2020, 12:38 (GMT)
Geometry Nodes: give nodes access to object that is being modified
November 19, 2020, 12:17 (GMT)
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.
November 18, 2020, 12:41 (GMT)
Geometry Nodes: support controlling instance scale in point instancer node
November 18, 2020, 12:40 (GMT)
Geometry Nodes: support point cloud component in random attribute node
November 18, 2020, 12:39 (GMT)
Geometry Nodes: support rotation and scale in instances component
November 18, 2020, 12:27 (GMT)
Geometry Nodes: fix memory leak
November 18, 2020, 11:28 (GMT)
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.
November 18, 2020, 11:25 (GMT)
Geometry Nodes: use attribute api in point instance node
November 18, 2020, 11:25 (GMT)
Geometry Nodes: use attribute api in point distribute node
November 18, 2020, 11:20 (GMT)
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.
Tehnyt: Miika HämäläinenViimeksi päivitetty: 07.11.2014 14:18MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021