for face in geometry.faces:
p1 = geometry.vectices[face.vertices[0]].co
p2 = geometry.vectices[face.vertices[1]].co
p3 = geometry.vectices[face.vertices[2]].co
if len(face.vertices[0)>3:
p4 = geometry.vectices[face.vertices[2]].co
else:
p4= Vector([0,0,0])
add instance at face center and use data to align / stretch / skew it
If a group has published fields, then Blender itself would add a âselectionâ field to the group node. Considering that the iteration of the group is controlled outside of the node, I donât understand why it needs to be a special âloopâ node.
Groups are from a user POV iterated already, right now we just canât control the individual non-field aspects of the group composition.
I possibly have this part really wrong:
Why not have selection as a publishable input parameter in the child group as well?
And pass that value into the group, and allow the user to do the maths inside the child group?
My gut feeling is to use the current 3.1 GN model as much as possible, without having to resort to custom nodes.
Build this behaviour into the very foundation of how GN works.
Or possibly âInstance on Pointsâ for example could feed the selection back into the connected instance?
It is a good news that advanced topics like looping are being discussed, the proposal has almost every corner about loops covered, so I will just list my suggestion below.
Personally I am ok with building loops inside something like a node group, it makes the boundary more clear, but I donât think it is necessary to make the loop node create or reference a node group. Reusing a loop network is not a common case, looping is kind of a local and one-pass stuff, and when you build another loop somewhere, there is always something different. And even someone do want to reuse the node group, he/she can create a normal node group inside the loop manually, just one more shortcut.
It might be a good idea to bring the unknown socket of the Group Input outside of the loop node. User can then connect any value they want to bring into the loop to this socket and create a corresponding socket inside and outside the loop automatically. This workflow makes sense because usually you get the preparation done before diving into the node, and it is kind inconvenient when you have to come out to reconnect the inputs after you finish the job inside.
I donât think it is necessary to have Entry/Break as nodes, a better solution is to have a while loop node or just give the sequential loop node an optional condition output that can be wired in for each step. Having these two as nodes can make things a little bit confusing when it comes to the parallel looping, it doesnât make sense to break a parallel loop, and if you want to skip rather than break the loop, the switch node would be enough.
pretty exciting proposal, I canât wait to start having loops.
A few quick remarks:
The simple Loop seems pretty straightforward, the Geometry Loop seems to have pretty steep learning curve.
It seems the Geometry Loop is a proposal to replace the âGeometry Fieldâ which makes it essential in terms of functionality.
The âElement Geometryâ and âEvaluate at Elementâ feel a bit of a patch-solution to the strictly abstract approach of the rest of the system.
As a user, I would wonder why is it so different to instance objects on a grid, than to instance slightly varied objects in a grid?
It seems like previous workflows shouldâve worked like a loop all along but now we are forced to invent a different workflow in order to break the restrictions of the previous, abstracted system.
Also, having a loop which depends on the use of additional nodes specific to that loop, already increases the difficulty of using it by a ten-fold. Itâs a bit of an obscure workflow.
I donât have better answers right now, but this is my first impression.
If this produces variable âclonesâ, is it possible to instance the clones that are identical, for most efficiency? For example, on the example with the random circles, if we produce four 3-segment circles, and three 5-segment circles, can these be instances of a 3-segment and a 5-segment geometry?
Can we use a âThresholdâ limit for a loop, like a âwhileâ loop? We could still have a maximum amount of iterations to make sure we donât create infinite loops.
Overall itâs a strong start, thanks for making and presenting this proposal!
I donât think you should tie the loop domain to the logic whether the results per element are independent from each other. Iâm thinking of distributing some points on e.g. a tree stem to seed branches. I would want to iterate over all points sequentially, so I could grow the branches non-intersecting. Having the first branch accessible in the growth of the second would allow to grow around the first one. Having all branches being evaluated in parallel you canât prevent them intersecting.
Similarly the interval based loop you described before shouldnât necessarily be a serial loop.
Maybe I just want to create 10 different versions of something, that I scatter afterwards to thousands of points. Those 10 elements would be independent and could run in parallel. I wouldnât want to use a geometry loop to create thousands of individual geometries for each scattered point, but first create a sufficient number of geometries to scatter and reuse them afterwards.
About the geometry loop, I think it would be nice if that one could get an input field for elements. This one should be a discrete valued field and the geometry loop iterates over all pieces with unique values of that field. This would allow to iterate not only over e.g. single triangles, but maybe groups of 10 triangles. Or you provide e.g. a node, that computes a field assigning topologically connected pieces their own id.
I feel like Iâve come a little late to this party ( Australian timezone and all!)
As a programmer, I would like to see an implementation for the 4 basic loop types:
Finite Numbered (Loop x times only)
Conditional (Loop until a condition is true i.e. While )
Series (Iterate for each item in a list or collection)
(Recursion (New instance of loop for each iteration) Special case below)
It might be handy to look at a separate Loop node for each type with a parameter of the loop node being a node group (name). This way, the main flow can be kept clean and loop âcodeâ groups can be organised elsewhere in the Note Group screen (Or indeed in a different Geometry Nodes instance for re-use)
Selecting the Node Group would add the In/Out connectors from that group to the Loop node, customising it and allowing parameters to be passed in and results out.
Recursion could be handled in this way by placing the Loop node inside the group that it references.
The more complex the things you try to do with nodes, the more unwieldy they become.
One thing that would short-circuit the need for a whole lot of different node types would be to implement a âscriptingâ node, analogous to OSL nodes in Cycles shaders. Depending on the performance, you might even getting away with letting the scripts be written in Python.
I think that, in terms of UI/UX, there is no reason to go back to old groups with their tiny fields to name sockets.
We could imagine an easier socket definition without going to sidebar. Like selecting a socket and then, calling a menu to rename,change its type or call a floating panel to set its limits.
We can imagine shortcuts to add or remove inputs/outputs sockets.
As it was said, reflex would probably to create a group, first.
I imagine that operators to convert a nodegroup into a loop could be a valid way to create loops, at low cost. Conversion could abort with warnings when nodetree would be irrelevant for a loop.
I agree with BD3D. A different icon + a very different color (violet, brown or orange) for label should be sufficient to avoid confusion. Color could be to tinted background of editing view.
It looks like point against using nodes similar to groups is the way to create and edit them.
IMHO, making loops as frames will not help those people to benefit from nodegroups advantages.
The solution to that is rather to create a âframe-likeâ display for nodegroups and loops in between default and editing display.
Of course, basic loops and basic groups should probably be added to official Node Presets addon.
Canât wait for the first flavor of Loops. (the sequential ones)
Especially to build strange attractors
Having as a return value not only the last iteration, but maybe a list of the iterations may be interesting in some cases (scan vs reduce). Scanning a list of vector 3 and using them to set position based on vertex index may be an option. Guess building a point cloud can also be done including a join node inside the loop, and passing along another vector 3 output as input. Some existing node addons such as svershock or animation nodes have been dealing with lists, donât know if lists are a whole different direction as fields and are never supposed to be implemented. If ever they are a thing at some point, really think a âscanâ option may be useful.
Can new field nodes specific to loops be used instead of âevaluate at elementâ be used. A âLoop element positionâ or âIterated faceâ may be more straightforward to understand.
Programming terms are not that understandable at first glance for some who donât use that function, a more âaccessibleâ name is desirable/understandable .
Geometry node is already visual programming tho
so the arg of âProgramming terms are not artist friendlyâ is a bit weak IMO
itâs important to remember that this kind of system audience is more advanced than the norm
imho GN should ease âthe norm userâ to get into programming
my students learn much quicker using nodes than scripting, and learning fast means building interest
Itâs been clear many many times that GN is not for new users or ânormâ users, that does not mean that it cannot be used, but itâs not the target and should not limit GN or define what terms are used
I think that the Blender community needs to decide whether nodes are:
A way to bring in people who havenât programmed but need a way to build complex scenes.
A visual language that mirrors programming capabilities - to what end vs programming?
A fusion of these that has constructs that are approachable and constructs allow for complexity as your learning progresses.
For the 1st you would want to lean into making sure the terminology and structure of nodes more closely mirrors a non-programmerâs mental model for how they would assemble what they are imagining. With this model it might be more difficult to do complex logic or less efficient but it would be more learnable.
For the 2nd you can structure for efficiency and complex data or flow constructs but non-programmers may find it difficult to engage and accomplish things quickly.
The best would be a fusion of these, and that requires a good amount of user research to both understand users model of creation (how they imagine their vision would come together) and their understanding of different kinds of logic so that the nomenclature and structure can mirror, match, blend and/or extend their construction paths.
The best way imo is to name things according to existing conventions and not reinvent the wheel.
(For, foreach, while etc.)
If you are worried about users with very little technical knowledge, tooltips are a better way to explain what a node does than names.