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.
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?
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.
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.
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.