This is a simplified yet exaggerated example of the problem I’m facing and can’t find a solution to.
I have meshes/lists of curves and by using kangaroo length goals I try to extend/shorten them so they will form back a desired shape. The problem is that sometimes when lines pull each other, the shape may collapse and still fully satisfy the length goals. I can’t add an angle or area goals because they are unknown, I know however which curves form the outside boundary and I need to be 100% sure they will stay this way. This is a 2D operation.
What can I add to the definition to avoid such problems?
Thanks for the tip. This method may work, but it relies on the strength of given goals, there might be cases in complex shapes where it will not work and failure will go unnoticed. I have a desired mesh to compare only for testing purposes, in a real-life scenario I will have only a network and lengths. I wonder if there is some method that will not rely on strength.
All your particles (mesh vertexes) are already at Z=0 , but use a project before everything just in case (to avoid flipping of triangles.
Normal solver is too much quick. The particle of your vertexes jump directly over the other side of other springs and everything tangle up.
You can use BouncySolver , which has damping, and that will slow down everything, avoiding tangling but still reaching convergence. You can increase iteration count input to make it faster:
(10000 iterations is fine only for very simple scenarios, use smaller numbers for more complex ones or you’ll have to wait a lot…)
Lower damping to 0.98 or less if it is not working in other cases.
@DanielPiker is it possible with a custom goal to limit particle movement, a max travel distance, from one iteration to the other? Haven’t even tried, but will…
If so, I’ll try to make a custom goal like that… and we could avoid tangling even while using normal Solver.
Maybe some more context will help in looking for a good solution. I’m experimenting with “self-solving” building interior measurement drawings this is the reason why I’ve set iterations of the solver high. It was tricky for me to set Kangaroo to perform as fast as it could and receive very precise results at the same time.
From what I observed especially small triangles around window openings tend to flip incorrectly.
I was thinking if there might be a circle inside every triangle that would collide with other circles, from other triangles during shape-solving and this could prevent triangle flipping, but I didn’t manage to set it up.
The general idea is to turn hand-drawn network topology drawings with measurements into real-life, correct shapes.
Test - lines reaching correct lengths turn green, angles within tolerance turn white.
Interesting.
I think the setup is simple, and what you did might just work, if your starting measurements are realistic with the topology, it should work.
Try with bouncysolver and damping, it should work.
If not, please provide the data where it doesn’t work…
I’m just catching up with this thread and I’m still a bit unclear on what is being solved for.
If we have a triangulated mesh A and we set external and internal edge length goals to match another mesh B of the same topology, then the only geometry which will meet those edge lengths without triangles flipping over is a rigid transformation of mesh B, with the same angles and areas, so adding goals for these would lead to conflicts.
In your original gh file you have lengths set for internal and external edges. I’m guessing maybe in the real problem this isn’t the case and you’re using only external edges, but also with angles?
Depending on this I have some custom goals that might help - for signed angles in a given plane, and for oriented triangle area in a given plane (to prevent triangle inversion).
I try to recreate floor plans based on measurements taken on-site. My mesh is basically a triangulated floor plan of some interior. Every mesh edge is a made measurement (in some cases there might be some edge that I couldn’t measure and I don’t know the length of). I have only lengths of mesh edges which may be slightly inaccurate due to the human error when pointing a laser or a tape measure.
All I want to do is turn this network of on-site measurements into a shape that will represent the real shape of the interior with the correct area, real angles between the walls, etc.
When I measure some interior I know which edge is a wall (exterior boundary) and which edge is a diagonal measurement from some corner to another.
The problem I’m facing is that sometimes during solving one some external lines are pulled and flipped inward, which produces incorrect results - this happens even if I use an artificial test mesh and 100% correct, precise mesh edge lengths.
As shown in my first post, the length goal will be equally satisfied even if one triangle of the shape will flip inward and I try to find something that will prevent it from flipping over.
Maybe knowing which internal corners are convex and which are concave would help and blocking them from changing from one to another will solve the issue - exact angles are not known
Here’s an additional goal which preserves triangle orientation to stop these sorts of foldovers. triangle_orientations.gh (9.4 KB)
When we know the triangles are all in the XY plane, if the vertices of a face are ordered counter-clockwise, that face normal points in the positive Z direction.
If it is pointing the other way, we know that face has flipped and we can consider it to have negative area, so the new Goal increases the area of that face until it is positive.
Thank you very much, Daniel. So far it’s working well. I’ve added some components. Without a coplanar goal, mesh was often folding on itself and started to fly around, flipping mesh face orientation also prevented mesh from unnecessary rotations and rolling over.
The coplanar goal makes slowers the solver but sometimes I had to use it, without it, some triangles often acted like small wings and kept on flapping.
I think any rotations out of plane must come from the input geometry not being perfectly flat - even if only by some miniscule amount. If you project everything first, I suspect you can avoid the need for the coplanar goal.
Projecting meshes onto a plane didn’t make any difference for me, personally coplanar goal slowdown doesn’t bother me that much at the moment but I updated the GH file if you are curious. (I’ve updated the GH file in my previous post, internalised geometry and projected it on plane)
Ah I see, it looks like the triangle orientation goal was correcting too aggressively. Changing its strength to 0.1 lets it converge fast without the need for the CoPlanar.
