How would I calculate in which direction a part is going based on it's velocity?

The title says it all, I’m trying to use raycasting with this

Image example:

LookVector or UpVector or anything like that is very unreliable. Just like in real life, things may or may not rotate while falling down


You can use a part’s AssemblyLinearVelocity to find out where it goes, since it is the rate of change in studs of its center of mass per second.

For example, let’s say a part is at 10,10,0, and its AssemblyLinearVelocity is 2,5,0.

In one second, its position will be at 8,5,0
In two seconds, its position will be at 6,0,0

Then you can calculate the direction of the raycast using this information, the DevHub has a useful equation for this:


Yes AssemblyLinearVelocity would be the way to go.

If you want just the direction you can do .Unit which returns the unit vector for the direction of the assembly’s velocity.

1 Like

Thank you Friendly4Crafter and thank you kozhiass aswell, but, i’ve found out that just doing ((Part.Position + Part.Velocity) - Part.Position).Unit works aswell, REALLY well actually! I’m probaly going to use AssemblyLinearVelocity for other stuff in the future, I wasn’t even aware that existed.


Wait, why are you adding and subtracting the part position? Isn’t that redundant? You could just use Part.Velocity.Unit


No, this doesn’t subtract it, (position - position) provides a direction.

That’s not entirly true.
Direction is a unit vector
Position1 - Position2 Gives a Vector that is a vector from Position2 to Position1. Yes, it includes a direction but it also has a Magnitude which isn’t always 1.

It is quite confusing yes but put simply.

VectorA - VectorB Gives a vector from B>A (Which includes the direction)
(VectorA - VectorB) .Unit gives the direction from VectorB to VectorA

1 Like

Yes, but my point is that the Part.Velocity itself is the direction. All the other math you’re doing is unnecessary. It’s like adding 2 + 1 - 2 = 1. The two’s are completely unnecessary so why have them? Even if you did need the magnitude it wouldn’t matter, because it will always be zero.

So again, all you really need is Part.Velocity.Unit because it still provides you the direction. Subtracting a parts position from itself doesn’t give you anything because your subtracting the same value. In other words, because each value is the same position you can’t get a direction vector to anywhere since you are already there.

Also, as you mentioned

you really should use BasePart.AssemblyLinearVelocity instead of BasePart | Roblox Creator Documentation, as BasePart.Velocity is deprecated now.

If you want to learn more about vector math you should visit the resources listed below.

On this one go to the Math Operations section.

This one will be helpful for understanding the Vector3:Cross and Vector3:Dot functions.


Personally, using deprecated functions is okay (sometimes it isn’t but most of the time it is).

For example, tick() has miliseconds which very is needed most of the time, os.clock() however only provides seconds. Yes, os.clock is in vanilla lua, but this is roblox so I dont need it, so tick is way more efficient.

Anyways about the ((part.Velocity + Part.Position) - part.Position).Unit, I did that just to be safe, it might use more resources and be a nano second slower but it is what it is I guess. Thanks anyways!

What do you mean by this? I’ve explained how you are basically adding 0 to the velocity which just gives you the velocity itself. How is this safer in any way? Doing this doesn’t even add any additional functionality.

For this use the DateTime | Roblox Creator Documentation userdata, as it provides you with milliseconds and many other units of time measurement. For milliseconds use Also, according to the documentation for os | Roblox Creator Documentation, os.clock uses microseconds, which is even more accurate than milliseconds. Below is a table of how much of a second a millisecond and microsecond is.

Milliseconds 0.001
Microseconds 0.000001

As you can see, microseconds is clearly more accurate than milliseconds. os.clock is also specifically meant for benchmarking.

You should not use deprecated methods because newer methods that replace them also add additional functionality and are generally more efficient. Deprecated methods are no longer supported meaning that if they break in the future then all the code you wrote with them will no longer work. So while you can still use deprecated methods it isn’t good practice to nor is it safe.