2022-1-17 - 2022-01-21 Geometry Nodes Sub-Module Meetings

Meetings
,
1

Info

Developers or artists interested in contributing are welcome to join at the links below.

Week of 2022-1-17

  • Named attribute node discussion
    • Hans created a document about this: Named Attribute Reasoning - HackMD
    • Main use cases:
      • A. Setting attributes from the middle of the nodetree.
      • B. Object info with object pointer inside the nodetree.
      • C. Global namespace (e.g., original_vertex_position or high-level node groups).
      • D. Dynamic creation of attributes based on names (e.g., bone weight).
      • E. Quicker scene layout/draft
      • F. Join geometry
    • Even with internal hard-coded attributes, users should be able to inspect the node group (or modifier) to see what it depends on (or outputs).
      • Maybe even mappable
    • Next steps:
      • Mockup for how node groups and modifiers communicate attribute dependencies. (Hans)
      • Explore overridable defaults for global attributes. (Simon)
  • Categories for field nodes (Hans)
    • “Accumulate Field” and “Field at Index” are in the “Utilities” category, which doesn’t do a great job at explaining what they do, since it’s so general.
    • A “Field” category might be better? However, that’s not very friendly to new users. There was no consensus on this topic, so it can stay as is for now.
  • D13757: Geometry Nodes: New Scale Elements node.
    • “Local space” input currently uses a forward and up vector. Could it use a rotation input instead?
    • The benefit of a rotation data type input is that it’s not overconstrained and there is no strong reason to prefer the X axis.
    • However, we don’t have the rotation socket type yet.
    • Using Eulers has a significant performance cost as well.
    • Jacques will test the patch with a rotation/orientation socket or only a single axis.
  • Follow up to D13550: Extending vector math node
    • (Hadriscus) Comment on math and interpolation on Devtalk
    • (Charlie) I’ve added a design task here with a proposal for a way forward.
      T94899: Float Math Functions in GN and Shaders
      • In summary:
        • In a similar way to recent changes to Map Range and Mix Node, extend existing Math node to support higher dimensions. This remains a common node for GN and Shaders.
        • Remove functions that operate on groups of floats from Vector Math node and version these to the Math node.
        • Allow Vector Math to diverge on GN and Shader to support addition of new functions.
        • Integer Math and Boolean Math remain separate nodes.
    • Current opinion of the group: As an end goal this makes sense. Also related is the type inference discussion, which may make the type dropdown on the math node unnecessary. We were a bit divided on this part, but it might make sense to delay this change until proper type inference is available.
      • Diverging math nodes in different editors should be avoided though, even if the operations are mostly useful in a “geometry” context.
  • D13804: Geometry Nodes: Triangulate Node - Add Selection Input
    • Keep the minimum vertices input or do full versioning?
    • There wasn’t complete agreement about this, but we agreed to keep the minimum vertices input.
    • We could possibly go further with versioning later on, for example when it’s easier/better to switch out a node for a node group with versioning.
  • D13809: Flip Mesh Faces Node
    • Sign off on naming-- the name here makes sense because it doesn’t flip the normal, it changes the order of vertices and edges in the face which then has the effect of flipping normals. It’s good to conceptually separate derived and original data.
  • Extrude back-face flipping vs. solidify node (Hans)
    • Generally it’s nice to have the same behavior as in edit mode. However, there are some drawbacks to it.
    • One drawback is code complexity, another is that the behavior doesn’t make as much sense in a procedural situation, where we want to be less “smart” and more predictable.
    • For 3.1, maybe forever, it’s okay for the node to not keep back faces like the edit mode operations.
    • In the cases where the duplicate back faces option is useful, it does the same thing as a solidify operation, which we want to add separately soon. In other cases the behavior is more confusing, and it would be different from edit mode anyway because it has to handle multiple selected regions
  • Curve component in the attribute transfer nodes
    • The “Nearest” mode should find the closest control point of the curve and copy the value to the result, without any interpolation.
    • A new “Nearest Curve Interpolated” interpolates the evaluated attribute value between the two evaluated points of the closest segment.
  • Order of “Domain” and “Type” options in nodes
    • No strong opinions from anyone.
    • The type can go on top, since the domain might be exposed as an enum socket eventually.
  • Operators to convert generic attributes into task specific data (UVLayers, etc)
    • The workaround operator isn’t intuitive in some situations because it works on original, not evaluated data.
    • We could add some info saying that the attributes on the evaluated geometry are different.
  • D12792: Geometry Nodes: Add Random value to Object Info node
    • Jacques can talk about the “Seed” in Amsterdam next week.
    • The seed should be changed in an object copy operator rather than the low-level functions.
    • The seed should be exposed in the UI.
    • Other than that, there’s nothing really new for us to say on this patch yet.
  • Copying and pasting nodes as XML or JSON (Dušan)
    • The goal would be to share nodes in a text-based format that’s easier to share than a blend file.
    • However, Blender couldn’t run versioning on the loaded nodes, which might end up breaking fairly quickly.
    • Generalizing this might be possible, making Blend files into text files, it depends on the use case though.
    • Making it easier to create a screenshot of the node group might be helpful.
9 Likes
2

All around great news, and I keep being flabbergasted at the pace of development.

Would this node work by finding the closest point on the curve, or just the closest segment ? I’m asking since “closest point on curve” is a rather valuable info to have at hand, so if it happens to be part of the calculation, it would be real nice to have it exposed. Of course the curve can always be highly resampled and every point checked for distance, but I would assume that is more costly. (Maybe incorrectly?)

That’s a good argument for named attributes too. Particularly thoughtful to differentiate between reusable assets vs. “one-shot” scene assembly. Even in my procedural tree modifier, which is made to be extra flexible, I find myself completely lost between all the kilometer-long connections, some of them going three levels deep… by digging too deep, we definitely awaken ancient evils.

3

I’d assume that if the “evaluated attribute value” input is position, then the interpolated position on a segment between the two closest points would end up being the closest point on the curve (?)

4

Not necessarily, this would only be true for order1 (linear interpolation). Instead you could have something like this :

closest
closest1270Ă—713 118 KB

Where the actual closest point on the curve from the sphere is somewhere along [0.1,0.2] whereas the interpolated position between the two closest points is strictly at [0,0]

if I’m making sense

5

Yes, totally. I originally assumed it’s the interpolation between the actual individual points making up the curvature such spline, not only the control points.

6

What we talked about was two modes:

  • "Nearest" This mode already exists on the node, it just gives the value on the closest control point (no evaluated points or anything). If you wanted the closest evaluated point value, then you would use the resample node on the curve first.
  • "Nearest Curve Interpolated" This would use the closest value on the evaluated curve (which doesn’t make a difference for poly splines). It would find the closest segment between two evaluated points, then do linear interpolation of the values between them. It would work like you’d expect in the screenshot @Hadriscus shared.

There was some disagreement about the naming/organization of the options. Mainly whether to make the mode generic, i.e. “Nearest Segment Interpolated” that would work on meshes or curves, or using separate modes for curves and meshes (which is the proposal above).

7

Alright, this much I had figured out from the meeting notes. I guess closest point on curve is something else then. I guess for most cases the margin of error isn’t too bad, and as you said we can always resample the curve to reduce it.

8

will there any design to improve node editor’s UX(for example, a frame in a frame), just like what have done to the search link.
By the way,I think search link are not use as much as the simple seartch.
First, considering how geo node works( It a geo output all the time), link from the existing geo flow will not immediately call the tree update just like search and insert (will not geo connect to the final output), as well as the field(will update until they was need.)
In my opinion, search and insert is more efficient than search and link , we can get real time result after add a node