2021-09-20 - 2021-9-24 Geometry Nodes Sub-Module Meetings

Meetings
,
1

Info

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

Meeting Notes

  • T91529: Object/Collection info nodes redesign for fields.
    • It can work just like the Group Input node as to how to add new outputs and specify their data type.
    • When using the socket input for the object/collection, the attributes are then exposed to the Group Input, so the mapping can happen in the modifier (or higher node group).
  • T90871: Join/Switch node redesign for fields.
    • Multi-input sockets don’t work that well for joining attributes since the order would matter on for every single attribute
      • Defining the order in multiple places means it’s easy to get wrong.
    • Does the node really need to handle joining anonymous attributes? They could just be added afterwards.
      • That may be less efficient though.
  • Curve fillet node sign-off/demo.
    • Not creating the fillet for straight corners may cause issues when someone relies on the curve indices.
      • However, the alternative is adding many points in the same place, so changing this doesn’t feel like an obvious improvement.
      • It could become an option in the future if necessary.
  • Fields Visualization:
    • Use the Diamond with a circle dot for the sockets that can take either field or data.
    • Insist on the dashed line for a final solution (see how it looks).
    • Meanwhile use 0.7 thickness for function flow.
  • T91373: Random Number node.
    • Multiple types in the same node:
      • Yes.
      • Use a dropdown to choose between types.
    • Which data types (initial patch):
      • Float: uniform in range
      • Vector: uniform in range
      • Integer: uniform in range
      • Boolean: probability 0-1
    • Node name:
      • “Random” is too generic.
      • “Random Value” is ok, even though “Value” used to refer to only floats in the past.
        • “Number” wouldn’t fit as well for vectors and other data types
    • Seed(s):
      • Two seeds are necessary when one wants the to use two nodes in the same context, since otherwise the seed must be offset.
      • In the future there can be a generic-type multi-input socket for a dynamic number of seeds.
      • For now we can simply add “Seed 1” and “Seed 2” inputs.
        • After the meeting we decided to use “ID” and “Seed” instead (see T91373).
      • For a stable inputs one has to plug in the “Stable ID” output from the Distribute node.
        • That should be more intuitive now that that output has a better name.
      • Don’t change seeds when the node is copied (as was tried in D10142.
        • Could be added later on as a feature of the copy operator if necessary.
    • Implicit index input:
      • “Seed 1” has an implicit Index field input.
    • Distribution modes (should be added in separate patches afterwards):
      • vector: In sphere, on sphere, direction + spread angle
      • float/vector/int: Gaussian, midpoint
    • Deprecate Random Float node.
  • Distribution node names:
    • Scatter vs. Distribute:
      • Distribute sounds slightly better
      • Distribute has clearer implications for the poisson disk mode
      • Scatter sounds like there would be fewer points.
    • Surface vs. Faces:
      • One of these is necessary to distinguish is from other types of distribution like distributing in a volume.
      • Faces is more correct, since it only operates on meshes.
      • Faces is shorter.
      • There may be other surface types in the future that the node does not work with.
      • Making the node specific to faces allows us to output things like polygon index, barycentric coordinates, … in the future.
    • Points vs. no Points:
      • Without “Points” it is not clear enough what the node is doing.
    • Verb first:
      • Puts the action first, which is the most important part of the name.
      • Part of the UI human interface guidelines.
      • This rule can be applied most consistently.
      • Leads to natural sounding node names.
      • Downside is that it makes names longer.
    • → Distribute Points on Faces
    • → Distribute Points in Volume (for the future when that is added)
  • Transform Instances:
    • Seems to be better to have separate nodes for Translate, Rotate and Scale.
    • Otherwise there are many different modes for choosing pivots and orientations for the different operations.
    • Example from the Offset Matrix node in Animation Nodes, where all is done in one node:
  • Translate Position:
    • Could be a useful utility node next to the Set Position node.
    • Instead of updating the position, the input would just be added to the existing position.
    • However, it is better have an “Offset” boolean input in the Set Position node.
  • Revisit Join/Switch node redesigns from monday:
    • Can we keep them as they are given the workarounds we discussed? At least for now.
    • A stretch, but maybe the order for the attribute inputs can be inferred?
    • Not blocking for bcon2, maybe not even for 3.0, depending on how much users request the functionality.
  • When to use instances in nodes and when to realize them? (T91672):
    • Nodes could work on instances transparently, but then we don’t really have an improvement from the situation in 2.93 where it was confusing and arbitrary when they were used or realized.
    • The “Realize Instances” node can be used to change the behavior of the following nodes to work on the whole geometry.
    • However, that presents a performance problem, since the following nodes can sometimes work on all instances transparently as an optimization.
    • So the realize instances node will functionally realize instances, but internally it can just tag the geometry so it can act as realized geometry.
    • Many nodes should warn when there is a combination of instances and real geometry, because the output might feel arbitrary if they only affect the real geometry otherwise. They should even output an empty geometry.
      • The “Set Handle Type” node is an example of this.
      • Conversion nodes like curve to mesh and distribute points node should also have a warning, and we’ll need to remove the “read-only instances” optimization and optimize realize instances code instead.
    • Separate components node
      • This has to be deprecated so a new version can output instances.
      • That shouldn’t be an option, since that’s what the realize instances node is for.
  • D11522: Geometry Nodes: String to Curve
    • Final new feature before Bcon2-- discuss/sign off before committing
  • Implicit Instance Index in the Instance on Points node?
    • Implicit index input is fine-- it makes the node more friendly and gives more useful behavior by default, and is still intuitive.
    • Use modulo on the index.
    • Show warning when Pick Instance is on and there is realized geometry in Instance.
  • Node menu cleanup.
  • D12574: Geometry Nodes: Separate + Delete Geometry for fields
    • Eventually the separate geometry node could have an index input and output a list of instances
    • The nodes also work on instances, even though a selection field input could only depend on position and index for now.
10 Likes
2

Instead of “Pont instance” it would much easier to understand if it is called Instance on Points

For a long time I thought that the purpose of the point instance node is to instance points not objects on those points.

4 Likes
3

Yeah, we wanted to make that clearer too. I guess it isn’t mentioned explicitly here, but the new fields version of the node has that name.

5 Likes
4

As far as I know, String is currently used as sort of “text input”. So, a Text naming, like Text Input, wouldn’t make more sense for the average user?

3 Likes
5

I think the “string to curve” node name is misleading and should be “text to curve” or something with “text” in the name. Anyone that codes, knows what a string is, but for many artists that may search for a node to create text, may find the node name confusing. Having a string as an input is fine though, imo.

6 Likes
6

Yeah, something like that. A String to Curve node desn’t say anything about a text output.

7

I don’t know If I properly understood this, but As far as I Understand, the current set position node (The last time I used it in the fields prototype, I may be wrong) sets the position of all points selected , to a specific point in space , specified via the input vector. The result is that all points affected by the node are collapsed to a point. So far so good, this has It’s use cases.

The proposal here is to add a “translate points” node that just move the points by an offset specified via the input vector, or similarly, add an "offset " option to make the "set position " node act as a “translate node” Is that correct?

If yes, How is it different from using the “Transform” node that just translates the points (other than having the selection input, Wich should be included in the “Transform” well Imho)

In another thread (I can’t remember where exactly) I proposed another option for the “set position” node: The offset boolean option you mentioned, could set the position of the “centroid” or “baricenter” of the selected points to the input position vector, instead of adding it to the original position.

This way the node would basically be a nodal version of the “snap selection to active” and “snap selection to active(offset)” operators, It would even use the same terminology. But instead of snapping to the active object or the cursor, you specify whatever position you want.

For future development, the user could also be able to input a custom pivot to move to position, instead of the default “centroid” or “baricenter”.

Let me know your thoughts about this Idea!

8

Well, to be proficient with Geometry Nodes, you are expected to know at least basic programing data type nomenclature such as integer, float, bool, string and so on. In the programming context, string and text seem to be two different things, where string is usually raw “string” of characters, hence the name, where as text is something more complex. Something that tends to carry not just a continuous string of characters, but additional data to define formatting and display of such text.

On the one hand, I agree that for new users it’s not that important, and would reduce learning curve. On the other hand, diverging from the programming terminology could introduce more debacles similar to the fact that the float constant input in Geometry Nodes is not called float, but a very ambiguously a “value” (which can mean anything). So a person who actually is familiar with programming terminology will now have harder, and more confusing time finding a float constant.

We should decide whether to botch the programming terminology to make GN more available to beginners, or not. But the worst possible scenario is where part of the terminology is adhered to, and part is broken. In that case, both the beginner and experienced camps of users will be equally as confused.

2 Likes
9

What are your thoughts on Texture > Noise Texture in Geo Nodes. Should it not be Generate > Noise.

10

The set position node takes a field. It doesn’t collapse all points to a position unless you provide it a “constant” field

image
image1361Ă—867 140 KB

11

Makes sense, Infact I happen to have used that with constant fields. The setup you did basically emulates what I think @HooglyBoogly would do with the boolean “offset” if I’m not mistaken.

Which is the same of this (except for the possibility to select points), correct me if I’m wrong:

image
image1030Ă—906 122 KB

What I meant with my proposal is actually this:

image
image1488Ă—995 210 KB