Capture the normal attribute on the original geometry, using face as the domain. Use the align euler to vector node to align the instance rotation to the captured attribute.
Also, to make the attribute capturing cleaner, I would recommend using the mesh to points node instead of dual mesh.
Can you show me how the nodes should be? That is the thought I had but I have no idea what itâs actually supposed to look like.
Nothing happens, no matter what I change in the Align Euler node.
The mesh to points node puts the instances on all 4 corners of the faces. I need the instances in the middle of the faces only.
Attribute Capture âfollowsâ the geometry⌠So, it needs to connect with the rest of the network.
Like so:
⌠so, itâs like saying âremember this for laterâ⌠and in this case by being in âFaceâ mode, its like saying âFor each point, remember the face normalâ.
Hope that makes sense.
Here:
Two important things to note:
This is extremely unintuitive. Intuitive would be âat this point in the process, capture the face normals, and then send them over to a point later in the process to be used. (like using a simple variable)â 
Thatâs what the transfer attribute node is for. Transferring an attribute has no geometry output and allows you to evaluate the attribute later. Capturing is faster, and has better interpolation in the case that the geometry is modified.
I mean, thatâs essentially what it does⌠still need to tell it where in the process the âdataâ needs to go, and you get that control by âfollowingâ a geometry chain. i.e. you can have many âdata-flowâ paths⌠so it canât be avoided.
âŚand yes, good point about Attribute Transfer nodes by Zorro - those are used to âjumpâ geometry gaps to allow even more powerful âdata-flowâ, but requires a lot more processing.
just fixed lots of bugs in my 2D plant factory. still some strange normal flipping but Iâm getting close 
Geonodes are the one feature added to blender that I never knew I needed so badly
I thought there was some kind of flip normals node added recently. I canât find it. Am I remembering wrong?
itâs in the mesh submenu, flip faces, 3rd from top
Just for fun I tried Attribute Transfer node. After trying every possible combination of options in both that and the euler node I deduce that I am not smart.
I know itâs technically not flipping the normal based on what I remember reading but ânormalâ is the thing a lot of people will have in their heads as theyâre searching for it.
Flipping a face can mean only one thing⌠flipping a normal is something you do with a vector math node⌠Scale by -1.
Is there any way to keep uv map after realize instances?
Or is there any way to have the verts of instances snap to the nearest vert of nearby instances without actually merging⌠like a âsnap by distanceâ node. Or is there a way to have a face that is being instanced on faces of varying sizes, snap each of its own verts to the corner verts of the parent face?
To work around not being able to do any of the above I would like to apply the Geometry Nodes modifier and manually weld the verts. But applying the modifier produces no geometry unless I add a Realize Instances node, which destroys the UV.
I am fairly sure that I read that this node actually just changes the winding order of the poly, so it switches from clockwise to anticlockwise or vice versa. As a result of changing the winding order, the normal is flipped.
Created this procedural rock/cliff thingyâŚ
But the initial question still stands, why do you need to connect the capture attribute output?
Thatâs a good question, I donât conceptually understand this either.
Recap for context: Making a node-group to âdisconnectâ cyclic curves by creating a duplicate vert at the start-point (for multiple curves). This is 1st step in attempt to fix weird twists in curve-to-mesh when attempting things like mobius strips.
Progress on âDisconnect Cyclic Curveâ support node-group:
Could not do this in 3.0⌠had to use extrude node from 3.1 to achieve above.
Issues in 3.0: Could not figure out how to index into separate curves. Anyone know how you can get vert-count per-curve (for multiple curves)?
Was thinking for 3.0 I could make a bunch of realized lines with vert count equal to vert-count of biggest curve then delete extra verts per-curve and re-map positions⌠was doable to just ignore all that and just use an extrude node in 3.1 but Iâm stuck in 3.0.
Hi⌠I can attempt to answer this using the node-group I just posted above as example:
Its important to understand that the cyan noodles represent a âflowâ of geometry data.
If you look at the bit labeled âEnd-Point Storeâ above, there Iâm making new geometry by performing a delete on the original geometry. This âsplitsâ the âflowâ of geometry as you now have 2 different sets of geometry.
Capture Attribute only adds to the geometry âflowâ it is on, so even though in the example you give the geometries are compatible, that is a special case⌠in general, the geometry âflowâ can (and will) come from anywhere.
Without explicitly putting the Capture Attribute on that geometry âflowâ the next node up the chain has no way of knowing how to âinterpretâ the incoming geometry.
In cases where there is a âsplitâ in geometry âflowâ you require a Transfer Attribute node (see the bit labeled âEnd Point OffSet Calcâ above for example) to allow the next node up the chain to do things like distance checking, index-matching and whatnot to get the data across.
The point though is that Transfer Attribute is not a direct data mapping, it is inferred, whereas Capture Attribute is part of a geometry âflowâ so therefore is a direct mapping.
Hope that makes sense.
