Hi every one,
is there a specific goal node to equalize the summation of a group of angles to be equal to a certain given angle?
For example I have a pyramid with 4 faces and I want to equalize the summation of the angles at the corner to 360. (I don’t want to set a specific angle for each one of them but I want Kangaroo to choose the more convenient angles with the only constraint that it must sum up to 360)
Maybe I didn’t understand what you’re trying to do, but
The sum of the [internal angles](https://en.wikipedia.org/wiki/InternalAngle.gh (23.1 KB) Internal_angle) of a polygon is π ( n − 2) radians, equivalently 180°×( n − 2), where n is the number of sides.
So in your case, there is no need to use any special component.
I do have an AngleSum goal, but I’m not sure if I’ve ever posted it before. I’ll clean it up and make an example file and post it today.
@Mahdiyar - if I’m understanding him correctly, Riccardo is looking for something that will work on the face angles surrounding a vertex in a mesh which does not lie flat in a plane.
Yes, that’s exactly what I meant! thanks Daniel, looking forward for it!
Hi Daniel, any news about this topic?
Hi @ThomasE and @riccardo.foschi2
Sorry I didn’t come back to this sooner. When I posted my last reply I really thought I’d already written something for this, but I could only find something I’d started but not finished.
Anyway, I wrote a new goal now - as input it takes a target angle sum (doesn’t have to be 2pi) a strength, and a list of 3n points. Each consecutive set of 3 points defines an angle, and it tries to make to total of all these angles equal to the target value.
I realise most of the time this is likely to be applied to angles around a mesh vertex, where many of these points will be coincident, but I wanted to make it as general as possible.
angleSum_goal.gh (15.7 KB)
I’ve only tested on very simple cases so far. It might need some adjustment after seeing how you want to use it.
-and here’s an example of using it to developablize a mesh:
angleSum_goal_mesh.gh (28.1 KB)
I also included something here to calculate and display the discrete gaussian curvature
thanks a lot! I’ll take a look at it in the next few days!
OK, I’m not sure if I understood the logic with which I need to set up the points list.
I need to extract all the neighborhood of each vertex and then duplicate the center point and copy paste it every two vertices?
I guess for my needs it would be easier to have a goal node where I can input just the mesh (or a grid of segments), and when 3 or more edges meet into a vertex it would force the assigned angle around each vertex. Maybe an optional input might be usefull where you can specify vertices that have to be affected by this calculation, if nothing is assigned all the points will be considered.
In this way if you want different angle summation at each vertex you might use several of these nodes specifying which vertices of the mesh to use.
However, even if it’s a bit tricky to set up the points, by your example I can see that the result is exaclty what I needed, Thank you very much!
PS: will it be implemented officially in a future release of kangaroo?
Another thing I have noticed is that none of the outer vertices moves ever but there are not anchor points on perimeter, can you explain why it does that? My guess is maybe it’s because the middle vertex of the triads is the one moving and you selected only the inner vertices to be affected?
Hi @riccardo.foschi2, thanks for testing it.
Yes, I agree - it would make sense to add a component that just takes a mesh and handles this point selection and indexing internally. Several other goals now work like this - planarize and smooth for example - the actual internal Goal functions take a list of points (for each face in the case of planarize, or each internal vert and its neighbours for smooth), but the component simply takes a mesh.
Yes, the goal only affects the vertex at the apex of each angle. I did also briefly look at adding a reaction force so the neighbours are also affected, but it seemed to make things less stable.
Note also that it only really makes sense to make angles around internal vertices sum to 2 pi. If the aim is to make something that can flatten out to a sheet with straight edges, you could make angles around edge vertices sum to 1 pi. The indexing becomes a bit more complex though, since you can’t just take all the angles between successive edges- you need to make sure not to include the angle between the 2 connected naked edges. You’d also need to identify and treat the corners differently - if you want it to flatten to a rectangular sheet, the face angles around each corner could sum to pi/2.
Any examples of use cases you have in mind would be helpful for making a good interface for this goal.
In some cases the planarized version of a mesh might be closer to the original one if also the naked vertices are allowed to move, so instead of moving the vertex centre on each iteration, maybe it would be much more robust to move the neighborhood vertices, and keep the internal vertex in place instead, but I understand that for this solution the code would be much less clean.
I’m working on an example, but I’m not 100 sure if it is actually correct yet, if it is I’ll upload it in one minute.
Ah, I see what you mean.
Yes, generally I think it probably is better for all goals to apply reaction forces where possible. This makes it easier to then swap around which parts drive and which are driven.
Also in terms of energy preservation and physical behaviour it makes sense for the forces created by each goal to cancel to zero. For example - a spring creates equal and opposite forces on its ends.
Something like developablization is pure geometric optimization and doesn’t correspond to any real physical force, but still keeping things balanced can be a good principle for keeping things stable.
I’ll have another look at adding in reactions to this goal.
Thanks, I added an example in the previous comment I’m not sure if you saw it, we posted it at the same time :). BTW thanks for all your precious work!
Another simple technique that I like for finding developables is to make a pair of triangulated meshes with matching topology, and keep one flat on a plane while equalizing their corresponding edges.
Having the developed version as an explicit part of the simulation can be perhaps more intuitive than the angle sum goal, and it makes it easy to choose which things to constrain in either the flat or folded mesh.
Yes I know that method, it is quite a standard method to enforce developability, and in this example is for sure much easier than angle summation enforcement, but the angle summation in my opinion is much more versatile, because guessing the unroll might be not that easy.
I only had this example in mind which might shows weaknesses of the angle summation method, but if you need I’ll try to think to an harder one.
Awesome @DanielPiker I took the @riccardo.foschi2 example and added a mesh to be fixed as an input (to prevent the straight result), the AngleSum should work not only with anchor points but also retain the shape, but again it looks quite predictable with this cylinder but it could be applied to a more complex shape.
