How to move a part somewhere with infinite velocity while resolving collisions on the way

For the past few weeks i’ve been having trouble with something.

I need a way to move a part to a location instantaneously and resolve collisions on the way. I tried using align position but even when I enabled RigidityEnabled it’s still takes a noticeable amount of time for the part to move to a location.

The reason I can’t use raycasting is because it’s 1 stud thick. I’m aware I need to implement some sort of custom CCD detection, but i’m not really sure how to get started.

1 Like

What does this mean? What’s one stud thick?

What application is this for?

It sounds like you will need raycasts, despite your protests :slight_smile:

So let me give you an example.

I move a part to a new location, and I raycast to that position from the old position of the part.

The left ball is the ball’s initial position, while the right ball is it’s final position.

Even through the ball should go through the pink part, raycasting wouldn’t detect since it’s essentialy a line.

I would need some sort of boxcasting.

Honestly, I suggest just casting more rays to avoid the problem. There are probably modules that will assist in this, or you could implement it yourself.

What are you trying to do at a higher level, though? Are you making a gun, or like teleporting a player with some special move?

Maybe there’s a different solution we can find.

Well, basically what i’m trying to do is a building system. The part blueprint tries to go to the location of your mouse, and if anything is blocking it collides with the parts.

Unfortunately, casting more rays won’t work as i’m planning to allow players to place pretty big parts.

I’m really bad at explaining things, if you need more explanation ask me.

Ah I see. So if the target position is at the mouse, what is the initial position? Where is it trying to get there from?

The initial position is the camera position.

Also here is my building test game, which shows the problem of the one raycast method, if you want to see what I mean in more detail.

Btw to add on, I mean something like this game:

However this game uses alignposition so the part just moves from it’s last position to the next targetposition of alignposition.

What Im trying though is it instantly goes to the targetposition every frame.

Hmmm. It’s not easy.

The new studio dragger uses a private API for solving collisions without physics.

Even when it’s made public, that API will still only be for plugins. It is released, and just for plugins: WorldRoot | Roblox Creator Documentation

So, what to do?

A few options.

  1. Implement your own arbitrary collision solver (highly not recommended), or
  2. Simplify the problem massively, or
  3. Use a bunch of raycasts and live with imperfections, or
  4. Use physics like you have and deal with the delay.

The second option means like “put things on a grid” or “only use spheres for the collision hull” or “make everything out of axis-aligned bounding boxes”, all of which would make this problem at least doable.

You could almost hack this with Model | Roblox Creator Documentation by making a clone world, rotated so that the cameras LookVector is pointing down… but MoveTo doesn’t preserve rotation so that wouldn’t quite work.

1 Like

It is public, and has been for quite a while now! (though still only for plugins)

What exactly are you trying to do that you need it for ingame?

1 Like

Just saw that, cool!

I think the goal is just to place a model as far along a line as possible without colliding with existing parts.

Assuming everything is anchored, it seems like something the solver could figure out?

Basically what MoveTo does, but along axes other than the Y (and allowing rotation?)

The reason that the API is not usable ingame is that in order to be efficient it re-uses the same data structures as the runtime physics. That means that if you were able to use it ingame it would mess up the normal physics simulation.

Also, if that’s what they need, it also wouldn’t do what they want. What IKMoveTo does is move the objects directly to the target, and then apply the solver to resolve any collisions. So, the part would move right past the obstruction if there were free space on the other side.

If you want a way to move something up to the fist obstruction, there is a good API for that too: With WorldRoot:ArePartsTouchingOthers you can move the objects one step at a time and keep calling that function to find when they begin colliding with something at a very low cost.


I tried doing something similar using GetTouchingParts(), however i’m not sure how I would actually resolve the collision. This would cause the part to be stuck inside the part as there would be no way to push it out by the intersection amount.

You could binary search it, like if you go from not colliding to colliding, try the halfway point between the two positions. If you collide there, test the half behind. If you don’t, test the half in front. Repeat until you’re not moving very much and you’ve found the turning point.

Also it sounds like worldroot:ArePartsTouchingOthers is faster than GetTouchingParts. But either would probably work.

Hmm, that sounds good to. Do you know how collision resolving is usually implemented, I really suppose there should be a faster/more efficient way to resolve collision.

It’s probably possible since the internal engine has access to the collision data of the parts (like which vertex is intersected in the other part).

Is there a way to implement something like this on roblox or would I have to do my own simulation?

That’s the answer, and what the Draggers in Studio actually do when you have the “Collisions” toggle turned on, they use binary search to narrow down exactly where the collision occurred using ArePartsTouchingOthers. It’s not as expensive as it sounds, because it should only take ~20 iterations of the loop to narrow down the collision point all the way.

You could even use a hybrid, where you raycast from each of the corners of the object’s bounding box to get a rough collision point, and then use the binary search at that rough collision point.

The long term answer is an “object sweep”, where you effectively raycast using an entire piece of geometry rather than a single ray. The engine doesn’t support these right now, but we definitely want to support that at some point in the future.