Geometry Nodes: support geometry components in depsgraph object iterator
Objects can evaluate to a geometry set instead of a single ID (only point cloud objects for now). In the depsgraph object iterator, those geometry components are expanded into temporary objects.
It's important to note that instanced objects can also contain geometry components. Therefore, they have to be split up into multiple objects as well in some cases.
At a high level the iterator works like so: ``` for object in depsgraph: for component in object: yield object_from_component(component) for dupli in make_duplis_list(object): for component in dupli: yield object_from_component(component) ```
DEG_iterator_objects_next has been cleaned up, to make this structure a bit more apparent.
Geometry Nodes: use GeometrySet when evaluating pointcloud modifiers
This changes the signature of the modifyPointCloud function. I'm doing that instead of making a new callback, because it requires changes to significantly fewer files. Eventually it would be good combine modifyMesh, modifyHair, modifyPointCloud and modifyVolume into one modifyGeometrySet.
I temporarily disabled the displacement only modifiers for point clouds. Support can be added back a bit later. I assume those have not been used anywhere anyway.
The output of point cloud modifiers can not only be another point cloud, but also a mesh and/or some instances. I added a new geometry_set_eval field to Object_Runtime. For point cloud objects, the final geometry is now referenced by that pointer instead of data_eval. The data_eval field is still initialized after modifier evaluation to make some other code happy.
The evaluated geometry set is not yet passed to the renderer, so a point cloud is currently rendered empty.
This node takes an object as input and outputs its location, rotation, scale and geometry. Right now the loc/rot/scale are extracted from the objects `obmat`. The geometry is just the mesh in the local space of the source object.
We will likely need some more control over space transformations using enums in the node, but those can be added a bit later.
The fundamental difference between object sockets and the other existing data sockets is that an object is an ID data block. Changing the value of an object socket also changes the depsgraph.
The modifier has to analyse the node tree to figure out which other objects it depends on. Currently, this is done very simply by just looping over all sockets and collecting the objects. In the future this can be improved by also figuring out what components of an object are needed.
Instead of passing object pointers around in the node tree, we actually use a handle. This handle is just a number internally that identifies a specific object. The conversion between handles and object pointers is done using a map that is provided by the modifier.
This approach has a couple of benefits. It protects us a bit from passing around pointers that are not known to the modifier and therefore are not in the depsgraph. Furthermore, the object pointer can change while the handle stays the same. This is not important right now, but is not unlikely to become useful in the future.
The API for how nodes access object pointers is not ideal yet and will be improved in the future.
This commits implements multiple changes: * Adds a simple C API. * Improves the ownership handling by introducing GeometryOwnershipType. * Adds an InstancesComponent that stores positions and Object pointers.
Geometry Nodes: rename Geometry type to GeometrySet
This should not change any functionality.
After talking to Brecht, we agreed that it might be good not to have a class called Geometry for now. In the future we might want to use a Geometry class as base class for meshes, curves, etc.
This commit renames the Geometry class to GeometrySet, because it is essentially a container that can contain multiple geometries of different types.
Master Commits
MiikaHweb | 2003-2021