2021-08-09 - 2021-9-03 Geometry Nodes Sub-Module Meetings

Meetings
,
1

Meeting notes from the geometry nodes sub-module. Multiple weeks included because I’ve been bad about posting the notes here for a bit.

Links

Week starting 2021-08-30

  • Naming of the “field” concept.
    • “Field” was chosen
      • The concept isn’t so visible in the UI anyway
      • “Field” works well, and though it might stretch existing definitions, that is okay.
      • Generally liked by all
  • Naming of the “anonymous attribute” concept.
    • The sockets coming out of nodes that reference temporary attribute data will be called “Attribute Fields”
      • “Attribute Field” is just another kind of field, and it purposefully doesn’t distinguish where the data came from (named vs. anonymous) because both are just data anyway.
    • That is not the name for the temporary anonymous attribute data itself, but the output of the node
      • The name for the data itself isn’t so visible, so we don’t have to decide quite yet
  • Visualization of sockets and links.
    • There was discussion of using double lines, but the general consensus thought it was too heavy and busy.
      • Generally, emphasizing the data flow links over the field links seems to be the way to go.
    • We will try the dash lined for the function flow.
    • Pablo wants to try to color for the noodles.
  • Nodes names
    • Some new nodes will be merged next week. We took the time to decide on their names
    • Input Nodes: Position, Index, Normal
      • There was discussion about whether to use “Get” in front of the input node names, but it was decided not to, since Blender does not do that already and it should be clear from the category (search can be improved)
    • Set Position
      • It could have used “Output Position” or “Write Position”, but the consensus was that “Set Position” is best, and is also consistent with some other node names already in Blender.
    • Attribute Freeze
      • Attribute Freeze This implies it is not interpolated afterwards, i.e. it wouldn’t change
      • Attribute Lock Same as above
      • Propagate Value as Attribute “Value” sounds single
      • Propagate Attribute A bit vague, and propogation happens anyway, without the node
      • Attribute Snapshot It implies it is frozen in time
      • Attribute Store Was strongly considered, but the node only temporarily keeps that data, store may be misleading
      • Attribute Keep Same problem as “Store”
      • Attribute Hold / Hold Attribute Keep it out, doesn’t work well enough as a metaphor
      • Attribute Catch Implies motion, feels very physical
      • Attribute Capture / Capture Attribute :trophy: :trophy: :trophy:

image

Week starting 2021-08-23

  • Fields Visualization.
    • Backend shows the different socket types we need, as well as the logic for showing different flows.
    • Pablo will make mockups for various ideas as the next step.
  • Persistent/Named attributes
    • Generally there is disagreement among the team about how retrieving “named/persistent” attributes should be possible.
    • On on hand, design directive is to reduce reliance on attribute names so node groups can be shareable. Only allowing names exposed in the object/collection info and group input nodes may help with that.
    • On the other hand, that makes assumptions about the process and sharing of node trees and may harm usability.
    • More discussion needed to reach consensus.
  • Fields Visualization presentation.
    • Pablo mapped different readable shapes that could be used.
    • When zooming out the double lines may look too busy. Option: to switch to dash line in this case.
    • The double-line makes the noodles more pronounced than the single line. So they may be a better fit for the data flow, not the function flow.
    • Follow up: High fidelity mockup for the noodle lines.
  • T91049: Geometry Nodes versioning in Blender 3.x
    • Discussion about whether “fancy” versioning is necessary. The Blender studio will convert all files manually anyway.
    • Get & set named attribute nodes would make the “simple” versioning method possible.
    • Dalai will create a thread on devtalk.

image
image495×538 28.3 KB

image

Week starting 2021-08-16

No regular kickoffs this week, Hans is on vacation.

Week starting 2021-08-09

  • Jacques is heading to the studio for the week. Discussions mostly happened in person there, with the goal of finally deciding which proposal to use for the future of geometry nodes and the attribute workflow.
  • Curve to mesh node attribute transfer (Miro, Hans)
    • There are two geometry inputs to possibly transfer attributes from
    • Transferring from both attributes (combining when they have the same name) has a potentially high performance cost
    • Should the default behavior be to transfer attributes like the point distribute and mesh to curve nodes, even when they usually aren’t used?
    • How do future plans impact this?
      • In the fields proposal, this could possibly be solved by using the same anonymous attribute before and after the conversion.
    • Results of discussion
      • Yes, automatically transfer all attributes for now.
      • In the future we can only transfer the necessary attributes (with anonymous attributes and references we can analyze this statically)
      • When attributes have the same name, it should vary in the V direction-- the “Curve” first geometry input attribute takes precedence.
  • T90432: Recent change flips profile curve extruded along spline upside down (Miro)
    • Before +Y in the profile became “up/+Z” when the profile was extruded, now it is the opposite.
    • The “right” behavior is arbitrary, but users may expect the old behavior more.
    • Hans will check if a relatively small change can change that part of the behavior back.
  • Level set nodes high level overview (Hans)
    • The two larger design considerations for the future
      • How to deal with volumes with multiple grids?
      • Is the rendering fine? If not, rendering as a mask grid works nicely in the view port.
    • No time to get into these conversations this week, not enough people present.
  • Choose names for curve built-in attributes (Hans)
    • NURBS weight
      • No decision on this one.
    • Bezier handle positions
      • “Left” and “Right” are arbitrary, it should use “start” and “end” instead.
      • “handle” should come first in the name so that alphabetical sorting puts them in the same spot.
      • These names will be less important in the future anyway, when built-in attributes have special sockets.
  • Brief discussion about implementation of field nodes that depend on another geometry set.
    • Hans noted that it’s nice when each node’s implementation doesn’t have to know about fields.
  • Hans spent Wednesday and Thursday on patch review. All patches are now “Needs Revision”, waiting on the new attribute system, or waiting for review from Jacques. The few cases where more design discussion is needed are below:
  • Has been reviewed or accepted by Hans, needs review from Jacques
10 Likes
2

@Hadriscus noted in the Geometry nodes devtalk thread that he thinks that the torus primitive has its place, and I would agree with him. I would be interested to see a response to the feedback given after the abandoning of the D11787 Torus primitive patch on that patch page. Would the node group method proposed by @HooglyBoogly be able to avoid the deficiencies that @AieKick says would accompany the node group solution? If not (and even if so, given my preference for the Torus being a useful primitive and one that is considered a standard primitive elsewhere, in addition to it being considered so in Blender in the mesh category), I would recommend the inclusion of the Torus as a primitive.

3 Likes
3

+1. I totally agree with this point.

4

Yes. Please keep the torus if possible, you already have it done basically!

We want GN donuts! :slight_smile:

2 Likes