In late June a Nodes workshop took place at the Blender HQ in Amsterdam. The goal of that workshop was to map out the future of the Geometry Nodes and simulation systems. Besides formalizing some design decisions for the projects, a lot was done in regard to the solvers design. However there was still a […]
In late June a Nodes workshop took place at the Blender HQ in Amsterdam. The goal of that workshop was to map out the future of the Geometry Nodes and simulation systems. Besides formalizing some design decisions for the projects, a lot was done in regard to the solvers design. However there was still a big inconclusive topic: better attributes workflow.
Now in August it was time for another round of meetings to land this home.
The Geometry Nodes system has already been used in a few productions. Nonetheless, what is now in Blender (2.93) has clear shortcomings. The main one is that artists should be able operate directly on attributes. How to do that, however, was not clear.
After the June workshop the Geometry Nodes team worked on different proposals, and opened a discussion with the community:
To move the discussion forward two different designs were chosen:
A week of development was reserved for each design to build a working prototype. They were available to the community for testing and ready on time for another round of face-to-face workshops in early August. In the end the Fields was picked as the best option to move forward.
Fields introduces two distinct flows in the node tree: a data flow and a function flow. This design is closer to the underlying software design. That design is then exposed to the users in a true “form follow function” fashion.
The data flow goes from left to right and operates directly in the geometry (usually a geometry is passed to the node, which outputs a new modified geometry).
The function flow is a sequence of function nodes that are passed to the geometry nodes and are read backwards, as a callback.
The complexity of understanding how the different flows work is overcame when the system is used hands-on. Artists familiar with the shader system may see similarities with the fields and the shader node-trees.
The prototype didn’t manage to cover all the upcoming design changes (e.g., to more easily distinguish between the different flows). But it helped to sell the idea of operations directly in the attributes, and the flexibility of working with fields. Artists don’t need to worry about attribute domains (e.g., converting a face attribute to a vertex attribute), and are free the change the topology of the geometry while the function flow still works as expected.
There are still design topics that need to be addressed, but the main story of the system was better defined and reiterated over during the workshop.
Names may change when this moves to the final documentation. But the underlying definitions are valid already.
There are still a lot of open design questions on how to integrate Fields into Blender:
On top of the designs, there is work to be done for backward compatibility. This is all scheduled for Blender 3.0 and will be the focus of the Geometry Nodes module. That means the core developers and the community will prioritize this over adding new nodes/features.
After that, the focus will shift to expand the Fields design for future node systems.
Download the experimental build (
temp-geometry-nodes-fields-prototype) and the doughnut file to get a feeling of the new system. Remember that experimental builds should not be used in production as they might be unstable or corrupt your data.