I’ve heard that apparently workspace:BulkToMove() is more optimized than both CFrames and physics.
What I mean when I say “CFrames” is that some people will choose to lerp CFrames instead of using roblox’s physics engine because they believe it’s more optimized.
Using workspace:BulkMoveTo() can actually be more optimized compared to other methods of moving objects, such as CFrame interpolation or using the Roblox physics engine. This is because BulkMoveTo() allows you to move multiple objects at once, minimizing the amount of network and computational resources spent updating the objects’ positions.
Answering your question directly, yes, the workspace:BulkToMove() method is more optimized. But it is worth considering that for different situations it is better to use different methods.
If I was moving one single basepart, would bulktomove still be more optimized?
I think this method is more effective for moving most objects rather than just one. In this case, it is better to use CFrame. Even if there is a difference in optimization, it will be extremely insignificant.
Pretty sure even with a single part it would be quicker - as the reason it is faster is that events are not triggered. However if you are using part.toched or cframe.whatever events these will not fire.
Tho as Mr_Sdows said its a pretty meaningless gain on a single part
Well I mean technically it’s moving alot of baseparts I guess because I’m moving the primary part’s CFrame, so would workspace:BulkToMove() be more optimized?
the difference is that bultmoveto doesnt fire events and its by skipping this step that it becomes quicker.
So yeah it is faster,
…unless you need to use those fired events to trigger something… in which case it wont trigger…
The other thing to consider is you need to prep the data for bulkmoveto as it only takes an array of cframes, making this array may actually take more time that just firing the events if you only have <10 parts…
But in terms of performance? Is it more optimized?
you can just test – use os.time() thats v accurate
run it before and after the function find the difference between the 2 times and thats how long the function takes.
run it a few times cos there will be some variation…
and find out which one is faster
Why not just use os.clock for benchmarking like this?
mybad os.clock() is the correct command
Optimization depends.
Case 1:
You have around 5 parts that need to be positioned/rotated every frame. For this case, it’s better to set .CFrame property
Case 2:
You have 100 parts that need to be positioned/rotated every frame. For this case BulkMoveTo would be way better. Usually in games with many parts that need to be manually moved, developers create a simple pooling system where every next frame, the “queued” part would get “CFrame’d” to the desired position. An example of this could be Pet Simulator 99, according to the microprofiler logs.
The provided function on models, Model:PivotTo(), is what you’d use for this exact case. If you set the PrimaryPart, that method follows the Pivot of the PrimaryPart, or the entire models pivot at the centre. You can optionally choose to edit the entire models pivot, which will use that new Pivot when calling Model:GetPivot().
I’m pretty sure that is the more efficient way of doing it, and it’s relatively new to the API. I’d recommend checking that out as it’s extremely helpful, and it makes teleporting player characters a ton easier as well!
workspace.Vyntrick:PivotTo(workspace.Username:GetPivot())
rather than using
workspace.Vyntrick.HumanoidRootPart.CFrame = workspace.Username.HumanoidRootPart.CFrame
In my opinion the second option is easier for me to use, and I don’t think there’s an actual benefit for using pivot to over primary part’s CFrame. Both will do the same thing as intended.
PivotTo is a good method, just not really useful for the character model for me.
That’s fair, it’s not necessary when teleporting characters, though it does provide a workaround to an issue that results in using models with constraints and such.
Using Model:PivotTo() will transform all descendants along with the Models Pivot, so you don’t need to weld objects anymore and unanchor just to get them to follow the single part you were trying to create a pivot around.
I just prefer to use it for the Character side of things too, because I like consistency. If I can use the same things to achieve the same results, I will.
It’s probably just me because I’ve been setting the primary part’s CFrame instead of pivot for so long.
That’s respectable. If it ain’t broke, don’t fix it.
I just remember creating a door system a while back and didn’t like how intuitive it was to use the Welds + Unanchor combo on all the pieces for the door just so I can tween the Doors PrimaryPart.
This method seems to clean a bit of that up, although I don’t think it would work great with Model:PivotTo(), but I just haven’t given it much testing.
I’d definitely recommend exploring what it can do for you, you might just find a use case for it.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.