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.
Implement your own arbitrary collision solver (highly not recommended), or
Simplify the problem massively, or
Use a bunch of raycasts and live with imperfections, or
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.
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.
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.