I been trying to set up a kangaroo system to solve this problem but I’m not sure it is possible at the moment.
The challenge is this:
All objects are rigid - that means they can collide but not changing their shapes.
The red curves are offset from the black curves.
The red curve in the photos cannot touch each other. The red curves can touch the boundary in blue.
The black curves cannot touch the boundary.
The black curves and their offset twin (in red) should always move together.
Included here is the grasshopper file of my attempt. The first attempt is the classic set up for rigid curve collision system, which do not work with the offset in this case.
My second attempt is to create a shape that include both inner curve and offset curve then extract the points of inner curve and include them in other goal such as insideMesh or curve point inclusion. This of course did not work either because the two goals act independently from each other. But I still include here as food for thought.
One way to work around is to offset the boundary but I want to research if there’s a more elegant and accurate method211031_KangarooOffset.gh (520.8 KB)
You can use the ‘Frame’ inputs and outputs to identify rigid curves and lock them together like this: offset_collide.gh (7.2 KB)
Here the offset rectangles collide with each other, while the inner rectangles collide with the containing ellipse, and the corresponding inner/offset rectangles are locked together.
To get the outer boundary you need to use this trick to make it external
Hi @DanielPiker. I tried coupling the curve collide with other K2 goals and it seem that they are working independently. The curves collide and move with their frames but if their points have to move due to other forces they don\t move along. Why is that? And is there a way to couple the curve collide with the rest? offset_collide.gh (27.0 KB)
The Curve colliders do not automatically create particles for the corners of the curves - they act as rigid bodies, where a single frame (i.e. an oriented particle) tracks the position/rotation of the curve, and the collisions are calculated directly from the curves by finding intersections.
If you do want to also include the vertices as particles which can be acted on by other goals, then you can use the “RigidPointSet” goal.
This adds the given set of points to that frame then keeps them in the same position relative to the frame as it moves (and it’s bidirectional, so pulling the points also applies a pull and torque to the frame).
Ahh so that’s where it was. I had made another script doing that without actually realising that there is such a thing and it worked and felt very natural. Now when it wasn’t working, it became very strange. Thank you so so much for the prompt reply . Will transfer the logic to the mane script now.
I just discovered this thread. This is very useful for me but I do need to lock the rotation of the objects, so that the objects wont rotate when they do collide. I do want to use this to quickly arrange parts on sheets for CNC cutting and I do need to always leave a 12mm gap between the parts for the cutter. How I can achieve this?
I do use the OpenNest but most of the time I do need to make manual adjustments to the nested parts because the nesting process it is not perfect at all.
really nice @DanielPiker The non-rotation setup is great.
How could I fix one element in place and move the other XXYYZZlockedCurve with a vector (instead of manually), so that it stops at its first collision — like a ‘vector snap’?
Here it is done geometrically. Essentially we treat the vertical axis as time, so the moving curve extrudes at an angle, while the fixed one extrudes straight up. The lowest point on the intersection of those extrusions gives us their first collision, so we know we need to move the 2d shape by that amount.
Thank you @DanielPiker , this is exactly what I needed! The geometric method works great as well. The next step would be to apply this logic to 3D meshes
I was trying with RigidBodyCollide, but I haven’t been able to figure out how to define the Support Frame.
Unfortunately I don’t think the geometric method will extend to 3d objects. The example above solves a 2d+time problem by offloading the numerical solving to Rhino’s built in 3d surface-surface intersector.
There is no equivalent built-in Rhino ‘hypersurface intersector’ function to use when we go up a dimension, so we’re back to doing the iteration ourselves.
. Will transfer the logic to the mane script now.