2024-03-19 Nodes & Physics Module Meeting

Meetings
1

Check the overview thread for more information about the meeting.

Present

  • Hans Goudey
  • Jacques Lucke
  • Simon Thommes
  • Iliya Katushenock

Since the Last Meeting

Meeting Topics

  • Handling of nested disabled collections (#114681)
    • Exclusion should not be taken into account, that should just be used by the render engine.
    • The “eye” viewport visibility should also not be taken into account because it’s more of a temporary property of the view layer.
    • “Disable in Render” and “Disable in Viewports” should be taken into account. The semantics here are more like “disable” than “hide”.
    • This impacts any node that changes the geometry like “set material” not just the realize instances node.
    • Testing the legacy particle and instancing systems (so they can be replaced by geometry nodes), they seem to behave in this way. There are other places to check the current behavior so we can make it consistent.
      • The boolean modifier
      • The particle system
      • Legacy instancing
      • Line art modifier
      • Collection info node
      • Collision physics
  • Node tools features
    • Demo
      • Viewport transform node
      • Project point node
      • Mouse position node
      • Wait on Cursor option
    • Path to landing features-- ideally before work on modal node tools
    • Depends on Cursor
      • Should have a different name (e.g. Wait for Click)
      • Only makes sense when the Mouse Positio node exists
      • Should maybe be in a separate “Options” popover
      • Can be used to build more interactive operators that are still not modal operators
    • Viewport transform node
      • The matrix should maybe be world->viewport instead of object->viewport, but that would generally be inconsistent because everything is in object space
      • Don’t have a use case for the “Orthographic” boolean output yet
      • Could potentially output an object that is the camera that one viewport is looking through.
    • Mouse Position
      • Currently outputs integer mouse position, but there are alternatives:
        • relative 0 to 1
        • relative -1 to 1, could be used directly with the viewport transform matrix
      • Could output a vector, but probably better to keep it separate.
      • The output sockets should maybe be floats so that a higher level system can be implemented that interpolates mouse positions for e.g. smoother brush strokes.
13 Likes
2

If it’s object->viewport people are likely to be confused when the object is transformed. Why not have an expanded enum such as World/Object->Viewport

3

The way the notes are written makes that sound a bit confusing, but I don’t think it is in practice. Everything in geometry nodes is in the local space of the modified object-- this is no different.

4

Thanks for considering a fix for #114681 This has been a real friction in geometry nodes based setups. The workarounds for it were unnecessarily complicated.

5

Hello, I have a question. In the 2024 roadmap, it says “Projects like Geometry Nodes and Vulkan will be put on hold for the time being.” But from the meeting notes since 2024 started, it seems the development on Geometry Notes is still the main focus of the Nodes and Physics module, right?

It also says "Then shortly afterwards, at different moments during the second quarter, we have interesting projects lined up:

Physics & Simulation

Most of these projects need to have their design fleshed out in order to pinpoint their scope and planning. This will happen during the first quarter, or ultimately before the project officially kicks off."
May I ask if this is still the plan?

2 Likes