Page MenuHome

Geometry Nodes: Refactor internal attribute access architecture.
ClosedPublic

Authored by Jacques Lucke (JacquesLucke) on Feb 6 2021, 12:11 AM.

Details

Summary

This refactor also helps with T84297.

Goals of this refactor:

  • 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 reach 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 independent set of attributes.

The separation of builtin and other attributes is now done at the attribute provider level (there are two types of providers).

The most important functions, where everything comes together are create_attribute_providers_for_mesh and create_attribute_providers_for_point_cloud.
Those functions list the providers used by the different geometry types.

Diff Detail

Repository
rB Blender

Event Timeline

Jacques Lucke (JacquesLucke) requested review of this revision.Feb 6 2021, 12:11 AM
Jacques Lucke (JacquesLucke) created this revision.
  • Merge branch 'master' into attribute-providers
  • comments
Jacques Lucke (JacquesLucke) retitled this revision from Geometry Nodes: Refactor internal attribute access architecture (WIP). to Geometry Nodes: Refactor internal attribute access architecture..Feb 8 2021, 5:34 PM

I expected to have more comments on this patch since it's a large change, but I couldn't see much of anything I would change. The abstractions seem like the right ones to make, and the explicit "write-able" "delete-able" enums are a really nice improvement. Much better than trying to ensure that behavior all around the code.

Splitting up this file should be a next step, it's doing way too much right now, and the doxygen sections don't help much. Splitting it up by component type specific code is probably the most natural way to divide it.

source/blender/blenkernel/intern/attribute_access.cc
494

had -> hard

882

Some comment about where this comes from would be helpful.

1108

Looks like this is used more like a set. I guess it's small enough and simple enough that there isn't much benefit to storing it that way though.

source/blender/blenkernel/intern/geometry_set.cc
380

Could note here that this is only exposed for the internal attribute API and should not be used elsewhere.

This revision is now accepted and ready to land.Feb 8 2021, 7:10 PM
source/blender/blenkernel/intern/attribute_access.cc
882

I'm not sure what you mean by "where this comes from".

1108

Yeah, this could also be a set, in fact I wanted to implement it as a set first. The main complication was that AttributeDomain does not have a default hash function yet. I'll at that on another day.

source/blender/blenkernel/intern/attribute_access.cc
882

Oh, I just didn't recognize the 1ULL, thought it was something Blender specific. I just looked it up, guess i just never learned about that.