algorithmic modeling for Rhino

I just came across this theoretical question while playing with the chain collision.

I found that there is not a Collision between surface & points, only solid. In almost all the examples/videos i have seen so far, people tend to use a flat box to represent a collision surface. When I tried to make a thin extrusion of a surface to trick the effect, it doesn't work unless I make it pretty thick. I don't understand. How does the thickness take part in the computation of collision? Shouldn't it be irrelevant?

Since Kangaroo is computing everything by vertices, why do we have to build geometries solid? Is there a way to build a customized goal to collide open surface/mesh with points?

Views: 170


Replies to This Discussion

In the file you posted it looks like the problem is actually that the mesh being created by the 'Simple Mesh' component is not closed, even when the Brep is. If a quad mesh has T-junction vertices like this:

then Rhino sees the mesh as open, since the vertices do not match between the side and the top. Using the Mesh Brep component (making sure the 'Jagged Seams' option is off) instead avoids this.

However, it is still an interesting question why Kangaroo needs a closed solid at all.

All of the currently implemented collision types are based on discrete collision detection.

Like frames of a film, the physical simulation is made up of a series of discrete instants. At each iteration it checks whether collisions are happening at that moment, and tries to correct it for the next iteration. With fast moving objects and very thin or zero thickness geometry, this can lead to an effect known as tunnelling, where objects pass completely through each other over the course of one iteration, causing the simulator to miss the collision (since at both the start and end of the iteration no overlap is present, even though to the observer it may be obvious that to get from one state to the other some overlap must have happened in between).

Thicker geometry and slower movement can mitigate this, but the only way to prevent it for sure in all cases is to use continuous collision detection, where we consider not just the instantaneous positions of the bodies, but the paths they take over the course of the time step. For complex moving and rotating objects this can get pretty complicated, especially if by responding to one collision we cause another collision within the same step. That said, I think for some simpler cases like fixed-surface/moving point it might not be too hard to implement.







  • Add Photos
  • View All

© 2018   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service