Easy solution is to use two align rotation nodes, one for Z alignment and other for X or Y
5 Likes
I would be very interested in this as well. Until now itâs not completely clear to me what the relation is between the density number you put in and the number of points you get out.
3 Likes
If we go back to the basics, when distributing, the monkeys are aligned with the normals. When only instanced, they are all aligned with the original monkey. My two cents: maybe it should be consistant?
I know you just need to add an align rotation to vector to align the monkeys to the normals but if you want to do the opposite, distribute but get them all aligned like the first monkey, itâs a bit more complicated. I think by default they should not be aligned to the normals so I donât need to counteract the rotations.
5 Likes
"When only instanced, they are all aligned with the original monkey. " Its not aligned to the monkey, the instances are inheriting the monkeyâs rotations.
When you Instance with using Point Instance, all point Rotations are zero. ( actually 0,-0,0 ?? )
If you add is a Point Distribute Node you now have random Rotations per point.
Use the Spreadsheet Editor to see whats happening.
Its working as intended albeit a bit confusing. The Point Distribute could have a " Grid " option that distributes to the Vertices.
1 Like
Re-iterating a question (haha) that is perhaps on the internal roadmap: Whether there is a plan for iteration, recursion, or the like in geometry nodes. Could be useful for many things, a couple of obvious examples are L-systems or array-modifier like nodes. Iâm not personally invested in which style, just curious on the if/when it would happen.
1 Like
Hi, there are no specific plans for any of those things right now. A âfor loopâ node has been mentioned a few times, but a good design would be needed for something like this.
More recently weâve been talking about list sockets. The first use case is to specify multiple attributes at the same time for things like the attribute remove node or for choosing which attributes to interpolate in the attribute transfer node. I know thatâs not what you had in mind, but itâs slightly related.
4 Likes
Are list sockets ordered multi-input sockets ?
@HooglyBoogly Just wondering if this is a known issue or not? The parameters from a geonodes modifier arenât named correctly in the dopesheet or timeline, which makes it a nightmare to animate with. You just get âinput_7â etc. Only by mousing over the parameter in the modifier do you even know which input relates to which parameter.
You also get the parameters listed in the order they were keyed in which just further aggravates the issue. They ideally should be listed in the order that is shown in the modifier. If you have a vec3 parameter and only key one component of it, then come back later and key another component, they will be listed in the wrong order.
Really hoping that this may be able to be fixed before 2.93 is released. I was going to lodge a bug report, but it is hard to know if this is classified as a bug or a feature request 
2 Likes
Iâm really loving geometry nodes. It definitely feels like thereâs a certain mindset to get into when designing nodes; itâs not immediately intuitive, but I feel like itâll click someday. It reminds me a bit of switching to a massively-parallel mindset for writing shaders or material nodes. Not the same paradigm as that, the whole âeverything is one geometry structâ is severely serial, but itâs just the same experience of âI have to learn how to think about this differently.â
I just designed a set of geometry nodes to create a displaced hull outline, with displacement being measured in screen space or something like it, with the intention of reuse, and I suddenly realized a potential problem that might impact the portability of geometry nodes like this: scope of variables.
Iâm using implicit attributes, naming them as appropriate for my particular node group, but if I reuse these nodes, I canât know that the next geometry I use with it wonât have those attributes as explicit attributes, in the form of named vertex groups (for example.) I could initialize them with an attribute fill, but thatâs wasteful, and will still lead to the problem that those vertex groups will no longer be usable after the geometry nodes evaluation.
I would recommend making a distinction between implict and explicit attributes because of this. An explicit distinction How? Via explicit and implicit attribute input nodes. Explicit attribute inputs can be dropdown lists of existing attributes, which also helps with the current discoverability problems. Implicit attribute nodes can have names that are merely handles, with the actual name of the attribute being determined at time of compile. This will also help with bugs caused by misspellings.
Note that it would be ideal for this scope to be on a node group basis-- node groups are as important for reusability as node sets. An explicitly implicit attribute inside a node group shouldnât be the same as one with the same name outside, unless that attribute is used as an input to the group.
(Although it looks like VGs arenât being written in the 2.93 I downloaded, which solves half the problem-- still, I imagine thatâs a bug, since itâs such a clear step backwards from 2.92.)
2 Likes
In terms of attribute names, it would be nice if every attribute name string input (the blue sockets) got an output blue socket on the other side.
This wouldnât change functionality or the way or order the node graph is evaluated at at all, but users could use it to make the flow more visible, by only using the text box when creating new attributes, and then dragging connections beyond that
4 Likes
I think the proposed Attribute Processor (T85655) is going to be a better approach to solve the current UX issues.
While inconvenient, the current UI at least correctly conveys the idea that the strings only reference the attributes existing on the geometry.
Having string outputs could create potentially misleading node graphs:
Try explaining to someone, that input A and B in the third node actually refer to the same values, without making it seem, like the system is actively made to be confusing. 
Donât get me wrong, I totally agree that the current workflow can be frustrating, but at least itâs not intentionally misleading.
3 Likes
Yeah, I think the socket would look the same. The key is using a single noodle to pass around multiple strings though, otherwise it doesnât have any benefit over a multi-input socket. But I think any socket that accepts lists would also be a multi-input socket.
Isnât it important to communicate order clearly ? in case operations are heavy and non-commutable (such as booleans)
Not to mention these would have to be reorderable
Yeah, unfortunately thatâs a known issue currently. Thatâs just the way that unique names are generated for group node sockets. It would be good to improve that in the future, or at least make the animation editor aware of the corresponding socket labels.
1 Like
Hello, is there a way to invert the normals of a mesh ? I was trying to create a mirror modifier node group but scaling -1 along an axis obviously produces inverted normals.
It seems the face normal attribute is write only. I understand that it is tied to the actual geometry and modifying it may lead to unexpected shenanigans, but a âRecalculate Normalsâ or âNormal Editâ like the modifier would be nice.
Cheers
Iâve put a copy of my experimental script node for geonodes on github, be sure to read the readme front to end as it contains important information on what this experiment is/meant to be.
12 Likes
Yeah, the normal attribute is read-only. Thatâs because normals are inherent to the mesh topology and the vertex positions, changing them requires changing one of those two things. In the future we can support custom normals on the face corner domain.
2 Likes
But also, an âInvert normalsâ node that would reverse the order of the vertices for each face would be very simple to implement, thatâs a good idea.
4 Likes
Thanks, at least I know it is on your radar! My current workaround is to key all parameters on frame zero, even if most are not used. This at least gives me the same order of the animation channels that are in the modifier.
When I create new group input through the UI, how do I define the type of that input?
Dragging a node socket type into the Group Input node certainly isnât the only way to specify the socket type⌠that would be embarrassing.
1 Like