# How to rotate my points so that they point outside like windows on a building?

Is it possible with geometry nodes and a grid node

with some "clever" math so that the outer "boxes" rotates to "outside"?

Or easier:

i have this:

and of course i want the windows to be on the outside and not all in one direction.

I have this basic little setup here:

and of course the windows should be on the "small side" as well as on the "long" side.

for the "corners" i have a solution, but not for the rotation of the cubes for the 4 sides.

I have two geo-nodes modifiers, the second one is just this:

• Can you show us a little more context to what you're doing? How you want to make/place the cubes? The simple solution is to instance a mesh that has windows on all 6 sides. You will need at least 2 sides, for the corners, even if creating the mesh completely procedurally (no instancing.) But everything depends on the limits you impose on the problem. Commented Jul 6, 2021 at 14:40
• good idea with windows on all sides ;) sometimes the easiest solutions are the best. Yes, i will update my question. Commented Jul 6, 2021 at 14:45
• Do you also want cubes inside the grid perimeter ? Commented Jul 6, 2021 at 14:47
• @Gorgious: It can but it doesn't have to be. I don't really care. Commented Jul 6, 2021 at 14:48
• With your updated geonodes setup, how are you then creating the cubes? Are you point instancing another object? Commented Jul 6, 2021 at 14:54

I nicked Nathan's idea of normalising the grid positions from -1 to 1 in X and Y, so credit goes to him for that, not here, please.

Then, by rounding the positions towards 0, you can interpret them as vectors to align to directly, without further work:

.. unfortunately, Attribute Vector Math doesn't provide an element-wise round, so we have to make our own.

Ocasionally, at some dimensions, this method does flip out. (I think, divisions by 0 at some values?). I'll try to fix that .. any suggestions would be welcome, of course.

Blender 3.0a

• wow...this is a really short solution....love that!!! Commented Jul 7, 2021 at 6:50
• don't beat me...just by trying out - i have no idea what i did - if you change scale from .5 to .49999 ...it works! :D Commented Jul 7, 2021 at 6:55
• @Chris Thanks! Yes.. looks like floating-point error on the Floor. Sometimes 0 when it should be 1. (There's a chance your fix doesn't work at all scales, I suppose.) Will have to check it out. Commented Jul 7, 2021 at 7:17
• @Chris BTW.. this answer is entirely dependent on Nathan 's. If you're handing ticks out at any stage, you should prefer his answer to mine. :) Commented Jul 7, 2021 at 7:51
• This is good! There should be a safe you amount you can upscale your unit grid, something like verticesX/(verticesX-1), etc. And you deserve your check :) Solutions don't spring fully formed from the rib of Adam, but they're no less notable for that, and simpler solutions are better. Commented Jul 7, 2021 at 14:36

Okay, so like I said in comments, the easiest solution is to instance a cube with 6 windows. And if you want a single window, you're going to have problems at the corners.

But, I think part of the point to this, for you, is gaining a better understanding of how to handle problems in geonodes, so I treated this as a more abstract problem than that. The problem is, how to align point rotation orthogonal to a grid?

It's a little bit complicated when you just look at the nodes. That's because there are quite a few repeated elements. When you organize it mentally into separate processes, it ought to make more sense. But without further ado....

So the first question is, how do we divide our points into four groups by facing? We're going to be doing that by looking at the dot product of their position with arbitrary vectors (the +X vector and the +Y vector). That will let us know which quadrant they belong in. After we assign quadrants, we can separate these points into four groups and rotate each group with a different rotation.

That's the basic plan. Let's talk about some of the nitty gritty.

The first thing I do is to create a rescaled copy of my position. That's because if verticesX and verticesY disagree, the angles defining my quadrants won't actually be at 45 degrees. By scaling my grid back into a square, no matter what its original dimensions, the quadrants will be properly represented at 45 degree angles. I store this temporary position in an implicit attribute I named "squaredPos".

After that, I do a bit of separation and combination to eliminate the Z component of squaredPos. This is because I anticipate you're going to want multiple stories. The angle we're interested isn't actually the angle from the origin-- it's that angle, projected onto a Z plane. So by eliminating the Z component, that's what I'll get.

Then, we have to normalize this vector so that we can compare it to our arbitrary vectors. The dot product of two unit-length vectors is the cosine of the angle between those two vectors. These angles define our quadrants. The cosine of 45 degrees is 0.707-- the square root of 2, divided by 2-- which is why we're testing for those values. (The cosine of 225 is -2^0.5/2.)

We assign our points into four different groups based on the values of our two dot products, then we use these groups to separate our points into four different sets of points that we can rotate. Finally, we rejoin all of these points and instance our geometry.

Note what I was saying: the corners aren't right. These corners are places where the dot product was exactly 0.7 or -0.7-- they fit into two different categories. If we really wanted, we could actually create four more groups-- points that fit into multiple facings-- and rotate and instance new, different geometry based on these groups. That would make this tangle of nodes even harder to understand though, and I think if you understand the processes of what I've described so far, you should be able to reason your way there.

• Thank you for your answer which i try to rebuild. Unfortunately i don't know how you did this: [1]: i.sstatic.net/xXb8Q.png -> the right most node is connected to a value although A is an attribute!? how is this possible? Commented Jul 7, 2021 at 6:47
• @Chris Oops, a bug. I updated the picture. It should have been connected to B, with "dotPlusY" as the attribute-- should be visible now. In this case, that node doesn't actually do anything meaningful, it only demonstrates the assignment of "front", while later nodes don't use front (it's merely what's left over after separating out back, right, and left.) Commented Jul 7, 2021 at 14:15
• Ok thank you but I am curious: how could you make that picture without getting red noodle? Did you copy a node above it?! Commented Jul 7, 2021 at 14:47
• @Chris Dunno. I just plugged things in. Guess Blender failed to warn me about my bug. (Maybe, because the attribute was unused, it ignored the node, and so it never triggered any "compiler warnings.") Commented Jul 7, 2021 at 14:48