This node is similar to the subdivision surface modifier. It subdivides the mesh component of a geometry. The options have the same meaning as in the modifier.
Geometry Nodes: Rename node category based on functionality
Naming based on supported geometry components only works in some cases. For nodes that work with multiple data types, it's better to categorize them based on their functionality.
Geometry Nodes: Add errors for out of sync sockets and properties
Theoretically the modifier's properties could be changed or removed by Python, so it may be useful to have errors printed and added to the modifier in that case.
I kept the check as a separate step from the `compute_geometry` pass because the object is needed to set the modifier error message. But it could easily be moved there in the future.
Geometry Nodes: Allow node group inputs with the same name
If we add the "name" label manually with uiItemR, we can use the socket identifier instead of the name for the IDProperty name. This will also allow us more flexibility in how to draw the settings in the future, and removes the empty _RNA_UI proprety that was drawn before.
Geometry Nodes: Use UI settings for properties in modifier
The system for exposing property settings like min, max, default, subtype, etc. for ID properties is quite convoluted currently, so I won't give a full description here, but this commit creates the tree of ID properties needed to store that information. This means that property subtypes like "angle" or "XYZ" will affect the display in the modifier.
Limitations: - The _RNA_UI property is displayed in the modifier. This may require a modification to uiDefAutoButsRNA to fix. - IDProperties must have unique names, but node sockets don't have that limitation. This can be solved by adding a "UI name" field to IDProperties.
Geometry Nodes: do not reference custom data layers when copying mesh
We can't use that for now, because the original mesh might be freed before the new copied mesh. When the original mesh is freed, the shared layers will be freed as well.
This can probably be improved in the future, so that we can actually share attribute arrays between meshes. An approach similar to how geometries and components are shared should work as well.
A geometry now contains zero or more geometry components. A geometry component is a subclass off GeometryComponent. Currently, there is a MeshComponent and PointCloudComponent.
A geometry contains at most one component of each type. Individual components can be shared between multiple geometries to avoid unnecessary copies. For that, each component has a user count that determines when the component will be freed and whether it is mutable.
Code working with geometries can either work with the components directly, or use the utility functions on the geometry that cover the most common operations.
In the future, additional component types can be added. For example, we'll probably need components for curves and volumes. Furthermore, something like an InstancesComponent can be added, which contains points with attributes and references a geometry/object/collection that is instanced on all the points.
Master Commits
MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021