| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Ids stored in the `id` attribute cannot be assumed to be unique. While they
might be unique in some cases, this is not something that can be guaranteed
in general. For some use cases (e.g. generating "stable randomness" on points)
uniqueness is not important. To support features like motion blur, unique ids
are important though.
This patch implements a simple algorithm that turns non-unique ids into
unique ones. It might fail to do so under very unlikely circumstances, in
which it returns non-unique ids instead of possibly going into an endless
loop.
Here are some requirements I set for the algorithm:
* Ids that are unique already, must not be changed.
* The same input should generate the same output.
* Handle cases when all ids are different and when all ids are the same
equally well (in expected linear time).
* Small changes in the input id array should ideally only have a small
impact on the output id array.
The reported bug happened because cycles found multiple objects with
the same id and thought that it was a single object that moved on every
check.
Differential Revision: https://developer.blender.org/D10402
|
|
Goals:
* Clarify the distinction between builtin and other attributes at the code level.
* Reduce number of places that need to be modified to add more builtin attributes.
* Reduce number of virtual methods that need to be implemented by e.g. `MeshComponent`.
To achieve these goals, this patch implements the concept of "attribute providers".
An attribute provider knows how to give access to attributes on a geometry component.
Each geometry component can have multiple attribute providers, whereby each provider
manages an different set of attributes.
The separation of builtin and other attributes is now done at the attribute provider level.
There are two types of attribute providers. One for builtin attributes and one for all others.
This refactor also helps with T84297.
Differential Revision: https://developer.blender.org/D10341
|
|
|
|
Because the the vertex group name-to-index map is stored in the object
rather than object data, the object info node has to replace the
map when it replaces the mesh component on the geometry set with mesh
data from another object.
This normally works fine as a way to use the vertex groups from the
input mesh, but when passing this mesh to the next modifier, the entire
mesh component was replaced, removing the vertex group name map.
This commit adds a function to replace only the mesh data in mesh
component, uses it in the modifier code, and updates the relevant
comments.
Note that the fact that vertex group names are stored in object data
is a legacy design decision that should be reevaluated at some point.
Differential Revision: https://developer.blender.org/D10256
|
|
|
|
Use transform matrices instead of loc, rot, scale variables to store instance transforms.
Reviewed By: JacquesLucke
Differential Revision: http://developer.blender.org/D10211
|
|
For the most part, this just adds boilerplate code for volume support in geometry nodes:
* Add `VolumeComponent` next to `MeshComponent`, etc.
* Support `VolumeComponent` in depsgraph object iterator.
Furthermore, I added initial volume support in a few nodes:
* The Object Info node outputs an object instance when the input is a volume object
(that will be the same for mesh objects soonish, to avoid copies).
* Support transforming a `VolumeComponent` in the Transform node.
* Support the `VolumeComponent` in Join Geometry nodes, but only when just one of the
inputs has a volume component for now.
Right now, there is no way to create a `VolumeComponent`, because the Object Info node
outputs an object instance. The `VolumeComponent` will be necessary for upcoming nodes,
which will generate volumes on the fly.
Viewport selection does not work correctly with `VolumeComponent`s currently. I don't
know why that is. That can be figured out a bit later, once we can actually create
new volumes in geometry nodes.
Ref T84604.
Differential Revision: https://developer.blender.org/D10147
|
|
The manipulation of rot/scale was simply not implemented.
|
|
Instances are created with an "index" parameter used for persistence over
time through animation. Currently the geometry nodes instancer passes
the index in the array for this value, but the arrays created by the
"Point Distribution" node aren't necessarily stable in this way when
the input mesh is deformed. In D9832 we already mostly solved this
problem with an `id` attribute. The solution here is to create instances
with this attribute as well.
It's important to note that deforming the instanced points *after*
distribution will usually be a better solution for this problem. This
solution is likely still important though.
Differential Revision: https://developer.blender.org/D10024
|
|
In the report, the geometry is copied because it has two users and the
final join node needs to write to it. The join node also happens to
remove attributes apparently, because it exposed a mistake in the "copy"
method of the `MeshComponent` class. The copy is supposed to be
a deep copy, but the vertex group name map was not duplicated.
Differential Revision: https://developer.blender.org/D9991
|
|
The Point Instance node can instance entire collections now.
Before, only individual collections were supported.
Randomly selecting objects from the collection on a per point basis
is not support, yet.
Last part of D9739.
Ref T82372.
|
|
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
|
