2024-05-28 Nodes & Physics Module Meeting

Check the overview thread for more information about the meeting.


  • Cartesian Caramel
  • Hans Goudey
  • Jacques Lucke
  • Simon Thommes
  • Iliya Katueshenock

Meeting Topics

  • Things we still want to get into 4.2
  • Feedback from Cartesian Caramel
    • The “Deform Curves on Surface” node is a black box with some issues currently
      • We are missing some low-level features to implement this as a node group with consistent abstraction levels.
      • The plan is to expose the surface object at the modifier level rather than retrieving it from the geometry socket. That relates more generally to the ability to expose more than one geometry socket to the geometry.
      • The tangents are problematic currently, both Ben and Simon replaced them with a node group that calculated tangents from a UV map.
      • We need the ability to get the original geometry of an object
    • Geometry Nodes: Quaternion to Axis Angle: There is always shift on 90 degree
    • UDIM textures are not supported
      • This wasn’t a big technical challenge (might have to look into only loading used images)
    • Vertex groups can be edited but not created
      • The ideal solution is that vertex groups become attributes, and that modifiers become node groups that support attributes.
    • High level (more global) inputs would be helpful in some cases
      • View layer custom properties could be accessible in geometry nodes. It may be possible to make dependencies granular, but everything should at least update-- granularity would just be an optimization.
    • Curve to Mesh UVs
      • Outputing the length along the main and profile curves as anonymous attributes on the face corner domain would make this less hacky and still not make arbitrary decisions for users.
    • Access to Parent object
      • Before geometry nodes starts evaluating we need to know which other data-blocks it depends on. Granualar dependencies are necessary to avoid cyclic dependencies and unnecessary updates.
    • Camera info
      • The node itself would be great. Idealy we would want a more minimal set of inputs and try to reduce reduncancy. Panels might be a way to organize things better.
    • Need for image socket in shader nodes
    • Scene time in shader nodes
      • Needs implementation! Removing drivers can help reduce unnecessary updates too.
  • Geometry Nodes: Curve Plane node

Need Help

  • Implementation of the scene time node in shader nodes would be helpful.

Think it should say shader nodes.

Hope this gets a good look this year!

  1. I hope “sample by ID” can land.
  2. Curve to Mesh UV.
    This is a very tricky problem in my opinion, because in actual practice, both the “Factor” and “Length” methods of “spline parameter” can be very important.

While I don’t remember the exact details right now, I recall cases like “Trim Curve” where I want to keep the UV stable, and therefore, I use the “Factor” method. “Factor” is also useful for various masking tasks since “float curve” and “color ramp” are bound to 0-1 by default. Thus, I think “Factor” should be used more.

“Length” is also crucial because it removes the “stretch” of UVs, which can stabilize image textures, especially in static cases.

In a nutshell, both methods of UV generation are essential for different use cases. My current design outputs both “Factor” and “Length” UVs simultaneously. I don’t use a menu switch because “Factor” is always stable and helpful for masking, while “Length” is sometimes useful as a “Second UV”.
If I don’t have either of them, I am afraid people will have to end up making their own group node eventually.

I wasn’t able to track the progress and discussions closely for the last year, so sorry if I ask a question that has been answered many times already.

Do you still have a plan/roadmap to implement RBD/Liquid/sofbody physics in GeoNodes?

I’ve seen some of those simulations implemented by hardcore Geonodes artists, but the implementation is quite complex and low-level, thus a steep learning curve.

“built-in” Geonodes groups with that functionality similar to Hair nodes, could’ve been handy to use as a starting point.



That would be nice to have, especially if it could be possible to plug into the Image sequence node to work as a time remapping…


This will not be possible.

It could be done via driver currently. Not elegant, but okay-ish.
Why is it not possible to pass a scene time as a single value from Scene Time node to Image Sequence node?

Along with what has already been said in the PR, and that this will probably get polished and added in more nodes in the future, I wanted to add that besides visual feedback before renaming, it would be nice to have it closer to how it is in the rest of Blender, with a black box appearing and the selection overlay being blue.