Currently what I am doing is on every frame on the client I am setting positions for hundreds of parts. (This is necessary to ensure the movement looks smooth.)
The main problem is having roughly 200+ parts all constantly moving at once seems to cause huge CPU spikes and low fps. (Less performance on lower-end devices.)
I’ve narrowed the issue down to rendering of the part movement and or either setting the position either by CFrame or direct position change. I’ve ruled out implementation inefficiency and suspect its something more fundamental with the engine? Could this just be a physical limitation of Roblox?
Also to add I am not dealing with physics/collisions, all parts are anchored and uncancollided. Also we are not talking complex geometry or textures, these are just simple block parts.
And sure I can utilize stuff such as spatial partitioning to only move nearby parts and even lower the part movement frequency for further away parts. However this doesn’t address the fact that having hundreds of moving parts on screen is very expensive.
I’m posting this to see if anyone has any optimization ideas or something I maybe haven’t considered.
Updating CFrame is very fast, but if you desire something faster than that, roblox physics are the way to go! Just use the new body movers. Not sure if this is going to be applicable for your use case tho…
@stagstagstagstag
I think it’s not really setting the CFrame that’s the problem. More like the Roblox engine struggling to render all the movements.
Yea physics aren’t really what I need here because I don’t need collisions. If anything wouldn’t that negatively impact performance even more since not only are you moving parts but having to perform physics calculations too?
No it would run wayy faster. Not only are roblox physics faster than manually updating CFrame, the new body movers run in parallel! This should make a significant performance difference. And collisions can be disabled, no problem.
EDIT: Terribly sorry but I was mistaken about the body movers running in parallel. I misunderstood the post made by Hajimalago. It’s constraints that run in parallel and not body movers (deprecated or new). Here’s the link to the post. https://devforum.roblox.com/t/adaptive-timestepping-by-default-feedback/2047141/17
ROBLOX physics are still faster than manually updating the CFrame nonetheless.
That is the culprit. As @stagstagstagstag stated, you should probably use physics in this case, or you can weld all the parts to one root part and move that root part.
1.3k parts moving at a random velocity with collisions and shadows enabled! I do have a pretty powerful PC and physics may throttle based on the device’s performance.
that’s crazy.