Hello, I had a question. What’s the difference between be doing game.Workspace.Part.Position = _______ and then doing game.Workspace.Part.CFrame
Why should I use CFrame instead of doing what I did in the 1st example? What is CFrame for?
Hello, I had a question. What’s the difference between be doing game.Workspace.Part.Position = _______ and then doing game.Workspace.Part.CFrame
Why should I use CFrame instead of doing what I did in the 1st example? What is CFrame for?
CFrames are used for setting the position and orientation at the same time and mostly used for pointing things at a certain direction or math operations that require CFrame.
One of the most common use cases is
CFrame.new(Origin,Lookat) --both inputs are Vector3 Values
This will create a CFrame value which well, looks at the Lookat position from Origin
CFrame is better than Position, but it really depends on the situation of using Positions/Vector3s & CFrames.
It’s also confirmed to be faster than Position by a ROBLOX engineer. I would use CFrame to make parts face at a certain point, while Vector3s are used for velocity & physics.
You can get a Part’s rotation by doing the following:
local rotation = cframe - cframe.Position
I think the main difference is CFrame allows you to do more then position.
than*
CFrames allow you to modify a physical instance’s positional and rotational data in a single expression. ‘CFrame’ property assignments are also more performant in comparison to other property assignments.
You can think of CFrame as ‘Position + Orientation’. Which means yes, you can teleport objects and also give a specific orientation.
CFrame can be used for orientation too, I believe
Although updating the CFrame will inherently be faster than doing other property changes, it’s important to remember that it might be because of the way in which that property change is done. For example, CFrames and vectors are comparable in time difference because both of the data types they collect are able to be cached in the program from the garbage collector. Color3s or to an extent strings (interning) for example can’t do that, so if you are creating a new color3 instance for example and compare it to using cframe it gives the illusion that changing the cframe of an object is much faster than changing the color3. What this misconception can lead to is people storing caches of colored blocks and changing their cframe, however, if the color data is already cached it will be comparably as fast yet it will take up less memory usage.
CFrame will inherently be faster
Speed here isn’t the key, the key is that ‘CFrame’ is the only property where per-frame assignments can be made without a significant performance impact.