2022-1-31 - 2022-02-14 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-02-14

  • GSoC ideas
    • There are some potential projects like converting the bevel modifier to a node, which really need a motivated, experienced developer. Beyond that, there aren’t that many remaining modifiers to convert that don’t have significant design challenged.
    • OpenVDB level set nodes is one potential project (i.e. finishing the functionality from D12100 where the design is complete enough that work could start (see How to deal with multiple volume grids in a geometry.

Week of 2022-02-07

  • D13749: Mix node
    • Charlie asked for some advice on versioning with python addons
    • We could keep the old ID name registered as an alias of the new node.
    • If we actually intend to remove the old ID name at some point then, we could show a deprecation warning.
    • We should get Brecht’s opinion about the patch.
  • D12746: Random Spherical
    • The patch still had pending code review.
    • For similar reasons to the easing node patch, it may make more sense to implement this as a node group
      • Inner loops can be devirtualized when more smaller functions have fewer inputs.
      • Optimizing smaller functions with SIMD and GPU acceleration is in the plans, but hand-optimizing every node becomes much harder
      • With things like this implemented as node groups, there is less code to maintain as we refactor things in the future.
    • With a builtin “coordinate space conversion” node and the random value node, a node group should be relatively simple. It would be good to at least see what the node looks like as a node group.
  • D13827: Geometry Nodes: New Face Vertex/Edge node
    • Useful for detecting geometry deformation for stretch maps
    • There should be some idea of other “final” mesh topology nodes before these nodes are committed. For example, having list field support would significantly change the possibilities.
    • Theoretically the node could have an attribute input and output. However, there will probably be more nodes that output indices, and the separation might be helpful conceptually too.
    • The question is whether it’s worth adding these nodes when we have general plans to add this topology information with lists in the future.
    • There is no conclusion, but some followups:
      • Make the MLOMVN (minumum list of maximum value nodes) without lists.
      • Make the MLOMVN of nodes with lists, including mockups.
  • T94722: Nodes to convert between cartesian/spherical coordinates
    • We had a long discussion (with some misunderstandings) about how vectors should still be stored in cartesian coordinates, and vectors shouldn’t become a “bag of floats”
    • Color and vector should be separate nodes
    • Rename “Combine/Separate XYZ” to “Combine/Separate Vector”
    • Add “Cartesian”, “Spherical”, and “Cylindrical” options to both nodes
    • Socket Names: “Radius”, “Azimuth”, “Zenith”
    • Zenith has a soft range from -Ď€/2 to 0 (at the horizon) to Ď€/2.
    • Azimuth has no soft range (but for the output is wrapped from -Ď€ to Ď€)
    • Radius has a soft limit of zero, but negative radii are flipped.’
    • Don’t change the node ID names, since they’re still basically correct and are probably used in a lot of scripts.

Week of 2022-01-31

  • “Instance Bounds” field input node
    • What space should it be in? The same space as the position node: the local space of the modifier object.
    • It could make sense to have a node to transform from the local space of the instance to the modifier object space.
      • Or, exposing the transform matrix of each instance as a field would work too, and would be more general.
    • No task created yet, because of the uncertainties described above.
  • D13936: Nodes: Dynamic node class for Map Range node
    • Looks good.
    • There was agreement that the node class isn’t a useful concept.
    • Any concept that doesn’t work with node groups should be changed, anyway.
  • Transfer attribute from curve evaluated points
    • The transfer attribute node works on the evaluated points internally, but …
    • What should the domains in “Nearest” mode do?
      • “Point” find the value from the nearest control point
      • “Spline” find the value from the nearest spline (using the average position of all control points in each spline for proximity).
    • Evaluate the input attribute on the control points, then interpolate it to the evaluated points with the generic utility, then sample it with the “closest” edges and factors.
    • “Spline” and “Instance” shouldn’t be in the domain list yet.
  • Initial 3.2 priorities: Geometry Nodes 3.2 Priorities - HackMD (Hans)
  • Okay to fix merge by distance default value in 3.1? 0.1m wasn’t purposeful and is way too large
    • Yes, sounds good.
  • Short demo of the Node layers prototype
6 Likes