2022-09-07 Geometry Nodes sub-module meeting

Meetings
,
1

Live Meeting Notes

The meeting will be open for everybody interested in joining the video call (link below).

Meeting time: 15:00 CEST (Your local time: 2022-09-07T13:00:00Z).

Links

Present

  • Dalai Felinto
  • Hans Goudey
  • Iliya Katueshenock
  • Jacques Lucke
  • Kshitij Rajgude

General Discussion

  • 3.4 priorities
  • T100010: Splitting the “Attribute Transfer” node
    • “Sample at Index” and “Sample Nearest” should work for naming.
    • The design seems solid enough to start work on this. It’s hard to discuss more until we can see it in action.
  • T100020: Curve and Mesh Topology Inputs
    • These should be in a separate section of the add menu. Definitely not just the top-level “Mesh” category
    • Many nodes or a single node with a dropdown?
      • Many different nodes are preferred since the use cases are rather separate
      • Using many nodes also helps to clarify the naming and make the semantics more obvious when reading a node tree.
  • T100859: Custom normals design for curves
    • Basic design seems fine, the “up” attribute solution is preferred.
    • How (or not) to change the existing Z-Up method can be determined when it’s working.
  • Versioning away the old curve type
    • The previous topic transitioned into this.
    • The main blockers are missing edit mode and a few procedural operations that can probably be built with node groups.
    • Rendering is also problematic, since Cycles and EEVEE curves drawing only supports non-cyclic Catmull Rom curves.
    • The benefits are a huge amount of cleanup and faster
    • Are node assets available during versioning?
      • Should probably use a specific node group for versioning anyway.

Patch Review & Decision Time

  • D15887: UI: Add Mix Node to color section of add node menu
    • We may have talked about duplicating nodes in the add menu before, but forgot the result of that discussion.
    • The node asset search patch (D15568) will fix the duplication in the search menu
    • The change seems helpful overall. The node should just be called “Mix” even in the color menu though.
  • D15479: Geometry Nodes: Add Selections to Curve to Mesh Node
    • This has came up a couple of times. It’s a hard design topic because it requires choosing what redundancy we want for ease of use vs. making things generic.
    • Overall there was agreement that at least some of the outputs would be good to add.
    • The best approach is probably to look at node groups for the same features and see how they compare.
  • D15313: Fix T99161: Set reroute node active when adding through lasso gesture
    • This a large, potentially controversial topic since it relates to T82359: Stronger binding of Active and Selected.
    • Jacques mentioned a previous patch that tried to make box selections of single vertices active that was abandoned.
    • The conclusion was that we should just leave it as is for now until a bigger picture design becomes clearer.
  • D15876: Indices Selection
    • This seems like useful feature, and the string input even seems convenient and performant enough.
    • However, it’s comes down to adding a new “language” to Blender-- deciding the syntax, etc. The consensus was that there wasn’t time to work through these design topics given all the other priorities.

Help Needed

  • One thing we will need is node groups that replicate the behavior of the old curve object.

Next Meeting

The next meeting will be on Wednesday 21 September, 15:00-16 CEST (Your local time: 2022-09-21T13:00:00Z), which is 2 weeks from this meeting. The provisional meeting agenda will be linked in the #geometry-nodes channel before the meeting.

13 Likes
2

What’s meant here? Happy to help if I can

5 Likes
3

I appreciate the offer, thanks!
Most of the remaining work is in adding an edit mode for the new curves object and getting the rendering finished, but to actually version away the old curve object type (which is important from a maintenance burden perspective), we have to be able to replicate the procedural features of the old curve object too-- the stuff below, minus the “Curve Deform” section.

image
image357Ă—580 33.3 KB

Personally I think it’s okay if we don’t replace every feature directly. And even if we can’t replace some of the more niche features, maybe that’s okay. But the final idea would be to convert original Curve data to the new type and add a geometry nodes modifier with versioning that replaced the features in the screenshot. So prototyping that node group would be a great start.

4 Likes
4

@HooglyBoogly are there any plans to rename the “value” input node to “float”? I realise that it is a legacy name, but feels very out of place now that there are input node types for integer, vector, boolean and string. Float is explicitly referred to all over geonodes, except maybe the random value node, where it does make sense.

8 Likes
5

It will be a handy node, I hope you include it for now. Later it might be replaced or refactored according to your general design? no?

6

I’m pretty sure that node is shared with the shader editor, so it’s a bit more complicated than it seems, because the shader editor doesn’t use the “float” naming at the moment. Unifying naming would be good but it’s sort of a larger design task-- it means more people have to agree on naming, which is always a bit difficult.

Personally I do like the consistency argument. Apart from that, it’s just not too high on my priority list compared to other things.

That sort of “temporary” design often causes more trouble than it’s worth. Better to think of the bigger picture of how we want users to create selections. In that context, it doesn’t look like the right solution IMO. Indices are not a great way to interact with topology-changing geometry. But anyway, like we said above, it’s not a priority to resolve that design for 3.4.

6 Likes
7

Thanks for your reply. It was my guess that it would also require a refactor for the shader editor. Hopefully this happens at some stage, but not a big deal.

If you don’t mind me asking a couple of other questions. Is there any word on instance attributes being usable in Cycles? Also, for the remesh and solidify nodes patches that have been in limbo for a while…are they likely to be finished by the main devs or waiting for the community to complete them?

8

Not at the moment. It’s an awkward intersection of two different systems which means the implementation is a bit less obvious. Definitely doable though.

No news here. The remesh node can be recreated by the mesh to volume and volume to mesh node now anyway. Porting solidify to geometry nodes isn’t a trivial task unfortunately, made harder by the fact that there aren’t any automated tests for the modifier.

3 Likes
9

waiting for this too, much needed

10

Just to make things clear in my mind. IF you plan to start working on “simulation/particle nodes” will it be a part of the “Geometry nodes” module or Physics module?

Also, do you plan to start working on it within Blender 3.4 or it is planned for later versions?
Thanks a lot!

11

The geometry nodes module is a “sub-module” of the nodes and physics module. Any development on simulation would happen in the same area, since it will be mostly/partially implemented with geometry nodes.

The 3.4 plans are basically just what’s listed above. I’d expect simulation to be one of the next things after that though. Hopefully, anyway!

1 Like
12

Thanks for the answers!

Can’t wait for Blender to have a new node-based particle system! :mountain_snow: :mountain: :volcano:

1 Like