I’d like to know how laggy can it get or if there would be no lag at all, someone has already told me there wouldnt be any lag since anchoring disables physics so im just here to make sure.
2 Likes
It would be so laggy that roblox will crash if you played it on tablet and can use a lot of ram loading those 100k parts
Why dont u try it.
Run this script
wait(10)
while wait() do
local Part = Instance.new("Part")
Part.Anchored = true
Part.CanCollide = false
Part.Parent = workspace
end
Whenever u press play
Make this a ServerScript inside of the Workspace. Your computer will have a fun time.
Psst. Hit Ctrl+Alt+Del to bring up the Task Manager. Make sure you save everything on ur computer before you run this
That will only make the part spawn every 0.1 second if you want it to spawn very fast (like 1 part per 0.00001 seconds which will most likely not since the script cant create a part that fast but still will make it very fast) than just do the same script except the while wait(0.1) do should be replaced to while wait() do
You forgot to anchor it. That will be The Lag Test.
It wont be as laggy as unanchored parts, but it would still be extremely laggy as roblox would have to load/render all those parts. Jailbreak has around 20,000 parts for scale.
1 Like
If user plays on IPad , phone or Mac it will crash completely game . But if player plays on PC then it will lag really big . I don’t think it’s good idea so …
I would say it would lag extremely badly. I have a map which is struggling to clone a wall made up of 32 layers of individual 6,1,2 parts across 1000 studs. So I think 100k parts would be much worse.
Edit: I use a Dell laptop
any ways to optimize it so that there can be 100k parts?
The thing is, some tests like these can be in-accurate to how this would play out.
Lets think of it as this:
Now, if you had 10 parts spread out every 20 studs, it of course won’t be laggy when you look at all of them/some of them. Now lets do that again but instead put every part in the middle, condensed together, with a bunch of z-fighting, now try looking at them again. It might not be laggy for you however, go for much higher numbers than the increase of lag becomes very noticable.
If the parts are already spread out (which It should since its a map, I don’t know why you would have a 100k part map inside eachother (lol) then you can implement a chunking system.
Chunk the lands off with each being seen. Chunks that aren’t seen and or are too far away don’t have to be rendered. This will take an exponential stress off the client’s rendering capability. Of course, there is limits, having 100k parts in workspace will hurt the server with a full fury punch depending on how its implemented. But surprisngly, roblox can handle quite the sum of parts if implemented correctly.
Use roblox’s build in LOD options of meshes and terrain if you can as well to improve performance. And disable collisions on any objects that don’t need them/set collisions to box.
Of course, you can try shoving the entire map into replicated storage to take stress of client (kinda) and rely it on client entirely (dont worry, won’t really matter 
, workspace replicates to client anyways so its still stealable) (but will still probably cause alot of issues such as actual organization, server script touched events (you can still do them but you’ll have to access replicated storage instead).
Basically, the more higher amount of parts you use, the more issues you’ll run into HOWEVER depending on the amount, most can be fixed.
Fantastic Frontier is an amazing roblox game that has 147k parts within it, it runs perfectly due to streaming enabled and optimisation, many of the parts are anchored and quite a bit of them are collision off so I’d say if you have 100k parts just sitting there in 1 spot then your computer will die, however if they are spaced out and some parts are a lot more further than others so that your pc doesn’t need to render as much then it won’t lag
1 Like