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

Question

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...?

Thanks in advance for your help!

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.

Answer 1

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).