I have managed to attach the boxes to strings but have not been able to constrain their movement to the curve. More specifically, I want the box centroids to be constrained on the curve. What would be the best way to achieve this?
On a side note, I would also like to have the strings collide with a specific plane, like how I’ve used SolidPlaneCollide for the boxes. For example, when the string length is too long I would like the strings to lay out naturally on a plane. Is there a way to do this other than using the Floor component? It does not seem like I can set a different plane for Floor.
I’m struggling to picture the result you are after here.
Do you want all the boxes to always lay horizontal on the ground plane and push each other along the curve like train cars on a rail?
How do the strings come in - does the top anchor need to move along a parallel curve to the rail the boxes are on?
As a start I made a few tweaks to your definition just to improve the collision between the boxes, starting with mesh boxes instead of meshing Breps: rigid_body_collision.gh (41.7 KB)
Yes indeed, I would like the boxes to be arranged as you so aptly described, laying horizontal on the ground/plane like a train with the curve being the track. The strings are used as springs with a deliberately short rest length to minimize the gaps between the boxes. The top anchor is not constrained and can move freely in 3D space, and the idea is that I can grab the point and pull the boxes along the curve.
I think in this case it can be simpler if we use 2d curve-curve collision.
Should the boxes also stay aligned to the curve like a train, or are they only held on the curve by a central point and free to spin around that?
They should be aligned to the curve like a train, yes. I’ve just used the centroid to start with as it was the simplest to build.
I am building towards a more complex simulation where I have obstacles at various points on the curve which will force the boxes to separate from each other. Thus the motivation for having the strings is 1) to allow me to move all the boxes around using a single anchor point, 2) to force the boxes to be as close as possible to each other in the presence of obstacles.
Can you explain more about these obstacles? Maybe a sketch of the end result would help.
If the boxes are kept on and aligned with the rail, I guess they have no way of moving past the obstacles.
I apologise for not being clear from the start! I have attached a screenshot showing a 2D sketch of the movement I want to achieve. The sketch illustrates how the boxes should respond as I move the anchor from one position to another.
To be more precise: I have n number of boxes (green) connected to one anchor (blue) using strings (orange). The strings are used to minimise the distance between the boxes and the anchor. The box centroids are constrained to lie on/be coincident with the rail curve (black), and each box’s orientation should be equal to the tangent of the rail curve at where it coincides with the box’s centroid. In 3D space the boxes should also be flat. There are a number of obstacles (red) that intersect the rail, and as the boxes follow the anchor around by moving along the rail, they should separate naturally to not collide with the obstacles while still trying to minimise the string length. The obstacles can be any solid geometry, are stationary, and their construction has no relation to the rail.
What does “separate naturally to not collide with the obstacles” mean? And why have “strings” attached to each car instead of only one car that moves the other cars in the train?
boxrail2.gh (17.6 KB)
To keep the boxes aligned with the curve I added a new goal. You might need to set the KangarooSolver.dll reference assembly location when you open it.
(typically something like C:\Program Files\Rhino 7\Plug-ins\Grasshopper\Components)
Beautiful! That explains what happens with a “string” attached to every car. But I still don’t get the part about “separate naturally to not collide with the obstacles” ?
I interpreted it as meaning just that the boxes are blocked by the obstacles, so separated into groups depending which obstacles they’re stuck between. I could have misunderstood though.
That looks amazing! Thanks for all the help, I’ll be able to learn so much from this example.
In terms of how I’d like the blocks to separate across obstacles, it might be clearer if I rephrase it as an optimisation problem where I am trying to minimise the total length of the strings (or equivalently the total distance between the box centroids and the anchor), subject to the boxes satisfying all collision requirements (between each other and with the obstacles), and all positioning requirements (centroids confined to lie the rail and box orientation aligned with local tangents).
Going back to the sketch, I have one anchor that I move from position 1 to position 2. When the anchor is at position 1, the leftmost box sits to the left of the leftmost obstacle, even though a “better” position for it would be to the right of this leftmost obstacle since it would be closer to the anchor. It doesn’t sit to the right because by doing so it would push the next box (to its right) further down the curve, increasing that box’s distance to the anchor by an amount that is even greater than the reduction of distance in the first box, and thus increasing the total distance across all boxes. It is only when I am in the process of moving the anchor from position 1 to position 2, and box 2 follows the anchor to the right naturally to minimise its distance to it, that allows box 1 to “jump” over that leftmost obstacle in its bid to minimise its distance.
I suspect that it might not be clear that the dashed and solid lines in the sketch represent the before and after “optimal” arrangements. I should be able to use the file you’ve provided as a starting point for developing this mechanism, nonetheless. Thanks again for the help!
