# Subdivide and fold selected mesh edges by a fixed angle along the edge normal with geometry nodes?

With a fair amount of help from this community, I've figured out how to align instances along edges -- and get wonderful 3d prints in the process. Which brings me to the current challenge. With the constraints of my resin printer's build plate (about 12cm x about 20cm), I need to be able to print objects that "unfold" to up to 1.5x that size for my costume work.

This means that I need to be able to subdivide the objects and fold their edges at the subdivided points, so I can print them "folded" up on the printer, and then "unfold" them.

I'm almost there - I've got a geometry nodes setup that does the subdividing and the folding along the edge normals. The problem is that the edges are being folded at the wrong angle.

I'm using the following formula to calculate the distance to offset the selected vertices (those created by the subdivision itself) based on the desired fold angle:

The next part is that I scale the vector normal of the edge "N" by the distance "D" to get the offset.

And this is where the trouble begins. I know my trig is correct, so I think the issue is how I'm relating the "D" to the vector "N."

Here is my node setup:

With the current reltionship between "D" and "N," I'm getting angles that seem inappropriately scaled. At Angle = 0, and Angle = 180 I'm getting values consistent with a tangent curve, so I think there's an additional factor that needs to be added to the DxN equation that I'm not aware of, but I have no idea what it is. In addition, the fold angles generated are inconsistent between 2D wireframes with no faces and 3D meshes, like the icosphere I actually want to fold and print.

For example, when I run a test on a 2D wireframe mesh, when I enter 120 degrees as the desired bend angle, I get an actual bend angle of 98.21 degrees.

When I run a test on a 3D cube, and enter 90 degrees as the desired bend angle, I get an actual bend of 145.95.

And when I run a test on 2-frequency icosphere, I get different bend angles for the different edge lengths. What should be happening is that the bend angle should always be consistent, regardless of edge length "L." "D" should be adjusting accordingly, but something else is apparently happening.

Here are the images from my tests.

Square

Hex

Cube

Icosa

I've also included the .blend file for anyone who so desires to experiment. I think the fix -- getting selected edges to always fold at the correct angles should be fairly simple... I think it's in what I'm doing with "N" and "D." But again...?

I've included the Blend file for testing. Note, you'll need to have MeasureIt tools enabled in your blender setup to view & manipulate the tests and get accurate decimal angle reads. Also, I'm using blender 3.6.

EDIT 1: Based on recommendation by Chris in the comments below, I corrected the formula in the second image. The fundamental issue remains, however.

• Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Blender Meta, or in Blender Chat. Comments continuing discussion may be removed. Commented Jan 2 at 5:12
• @quellenform darn you caught us 😮‍💨 Commented Jan 2 at 5:26

# Divide Edges & Offset by Angle

## The Problem

[btw the following is in response to the question and I will repeat things that I’ve mentioned in the comments]

The main problem you are facing is: you are calculating the length after you subdivide the mesh. This is a problem because the set position works on points (the point domain) and the edge length is on the edge domain, and when you go between domains [that aren’t a subdomain like corners from a face and control points from spline] you get interpolation to reconcile the data conflict [there are multiple pieces of data going to one element e.g. there are two vertices per edge so both their data have to do to one edge, or in our case] - each vertex could have $$n$$ amount of edges each of which have to now go to one point. This “Interpolation” is taking the Mean (sum of elements divided by number of elements). Therefore, if all the neighboring edges of of a vertex have the same length, we still have the same number, but if they don't all have the same length we run into the issue that you don’t have the correct number.

Another issue that arises if you are calculating it (the length) after the subdivision, is that now the edges are half the size so you divide two part of the equation (which you changed to the denominator as a $$\times 2$$) is now dividing it an extra time totaling $$1\over 4$$ of the original length.

You can see that the edge length have to be taken before subdividing [or compensated for afterward], but i think it is also advantages to calculate the whole thing before subdividing; that way you could set the angle you want per edge (on the edge domain on the original geometry. Much easier to set or derive).

## Solution

Here I'll calculate the whole thing before subdividing the mesh and deal with a separate issue with the “Interpolation” that ‘Subdivide Mesh’ does. This isn’t just the Mean (as it is with changing domains); it first adds the new geometry, then takes the Mean. This includes the new geometry in the Mean as 0’s.

To solve this I’ll capture the value 1 (on the edge domain) and divide the value ($$D$$) I also calculated before the subdivision by this value (the captured 1), which cancels out the “interpolation” [its’s basically the ratio of how much our value went down]. And for the domain “Interpolation” issue (from edges to points), it’s a non-issue, because I’m capturing the calculated value (before the subdivision) on the edge domain, so the new vertex on that edge will interpolate (take the Mean) from the original edge [not an issue; this is what we wanted] and the newly generated edges, which the solution immediately above solved.

For the vertex selection for the set position, I compared the "new" index to old domain size - any new indices will be greater than $$1-n$$ i>1-n, or what I did 'equal to or greater that point count'i=>n.

An angle of 180 is $$D = 0$$, positive angles go outward (in direction of the Normal) until 180° (then it's negative), and negative angles go inwards (opposite direction of normal) until -180° (then it's positive) [basically it wraps].

I tested and it always gives the correct angle (except for the float-point precision errors, but nothing you could do about that).

• it looks like you solved the problem for the cube beautifully, but on the icosphere it's still not working right. There appear to be two issues on the ico. First, the output fold angle still does not agree with the input; second, the output angles for the edges forming the pentagons are different than the output angles for the edges forming hexagons. I also tried with an Ico with only 1 subdiv, and a 15 degree input yielded a 129.06 output. I poked around a bit and so far the only thing I can figure is that the value of the 2nd "capture attribute" node may be a variable? Commented Jan 3 at 1:49
• @EmmaScottLavin the second capture attribute node value is 1. also what are you using to measure the angle. I mapped my angle to be intuitive for me - flat (no fold) is 0°, a right angle outwards is 90°, right angle inwards is -90° etc.. your value association might be different so it will show as a different angle that mine even though it's the correct angle. Commented Jan 3 at 2:53
• @EmmaScottLavin if you have further issues, it might be better to have a discussion on discord, where we could share media back and forth. you could find be on the 'blender community' discord. Commented Jan 3 at 3:25
• Thank you... I am testing now. I'm using MeasureIt tools to measure the angles. For me, it looks like I have the polarity reversed -- an outward angle is negative, while a positive angle is inward, which suits my needs. But otherwise, I reconstructed your configuration exactly. It's working perfectly for the cube, but not for the icosa. I am noting that both a 0 angle and a 180 angle are generating no fold, so again it appears that there's some multiple that needs to be there but isn't. I'm happy to move the conversation to discord... Commented Jan 4 at 4:55
• I just joined the Discord. My username there is wearebelov3d. It looks like there are two accounts called "shmuel"-something, so feel free to message me from the one you want to use. Commented Jan 4 at 5:07