Hey there dev forum.
I’m making a tycoon/sandbox alike game.
So far its al working, But there is a problem with performance.
Basicly in my game you place droppers they drop parts and the parts give money. But when there are to many bricks the game performance is getting worse. How would i fix this without reducing the part count?
I havent tried any solutions since I dont know any.
Google didnt help me well either.
Anyway I hope anyone off you guys knows a solution.
Try disabling global shadows and using meshes, for high part places.
Could you could increment the player money with a script and then spawn the parts on the client side as a visual effect?
The reason that high brick counts generally reduce performance is for two reasons.
One, triangle count
Two, physics
You should set the network ownership of your dropped parts to the server. This will stop clients from trying to do physics. You might also set Anchored on and CanCollide/CanTouch both to false to stop all collision detection. (Iirc CanTouch is temporarily disabled due to crashing. It doesn’t cause errors when used in scripts though, it just doesn’t have an effect)
Additionally, if your parts have a high triangle count, you should find or create meshes for them that have less triangles. The more triangles there are to render, the laggier things will get. If you are on shadow map disable CastsShadow as well.
I have one last trick as well, set your parts/meshes to the Neon material, and, if you don’t want them to glow, darken their color. It’s not commonly known, but, Neon parts are actually faster to render than Plastic & SmoothPlastic parts, and ForceField parts can be second fastest depending on a few different factors.
In one of my games, I have a Simple Materials setting which turns most parts to the Neon Material. I saw about a 30-60% performance increase by using Neon instead of Plastic/SmoothPlastic parts.
I believe the reason for this is that Neon and ForceField parts don’t have any lighting or specular highlights. They use a perfectly flat color no matter the angle, and, thus, they cost way less to render per triangle.
thank you very much for all this detailed options i will take a look at all of them but i guess it will work since the server side always seems to work smother than client side
All this would do is guarantee the client more lag depending on their device hardware, as then all the parts and their physics would be handled solely by the client.
This isn’t necessarily true, because, network stuff does have a performance cost, but, generally I would expect the physics impact to be pretty negligable (usually). Sometimes you will get better performance by creating effects client sided, since, sending a lot of instances a lot of times can be very laggy. That won’t effect passive FPS unless you are constantly creating a lot of instances at once though.
@Michel2003g
The reason things tend to feel smoother on the server is because FPS lag is caused when the amount of time to do everything in the game takes longer than the amount of time that a frame should take. If it takes 100 milliseconds for everything in the game to happen on the client (not including when you use wait or wait for events or anything) you won’t be able to get more than 10 FPS. (1000/100 = 10)
When you put that strain on the server, now the server is the one doing the physics work, so, the client is spending less time on that. That might cause you a bit of server lag (the server has something like FPS too, Heartbeat) which will end up slowing down your game without lowering FPS, but, usually physics doesn’t cost that much, most of the lag is render lag.
Sorry, I know how this is going to sound, so just a disclaimer that I’m not trying to be snippy. My question is this: If the physics impact is negligible then why do they spread it out among the server and clients?
I am simplifying it a little because I don’t want to be misleading, generally the cost for physics isn’t that big of a deal, especially for a few small loose parts being on the server instead of the client. Each loose object is an assembly, and when you have a lot of assemblies there can be more of a problem, but, a high part doesn’t generally mean lots of physics lag, and, if your assemblies aren’t that big the performance cost isn’t nearly as bad either. A lot of the time physics calculations between assemblies are only done for nearby assemblies.
If you have ever played an older Roblox game where there are a lot of exploding parts and things you’ll probably have noticed that things start to go slow mo. That’s a way Roblox will automatically save on performance, by essentially slowing down physics (physics throttling). Roblox physics have been getting faster and physics throttling has been getting better, and, now we have variable physics rates (The engine can step between 30hz <-> 60hz <-> 240hz so that physics is happening at the same speed but is doing less steps to save performance)
Generally, the worry about physics on the client is when you have lots and lots and lots of assemblies close to eachother because they can be costly enough to reduce FPS but not necessarily costly enough to reduce server heartbeat. Roblox servers are actually quite fast, and, they don’t have to do any rendering or graphics processing so they have a pretty nice amount of extra resources compared to the client even for servers that are realistically slower than your computer, so, you can generally do more stuff on a Roblox server than someone’s computer.
It gets complicated, but, I think Roblox’s automatic network ownership is starting to become a little outdated and its contributing less and less to performance saving. It’s great for a lot of older Roblox games, but, at the same time, very exploitable, its sort of a remnant of before FilteringEnabled and before the engine had so many optimizations and such.
That’s not to say you shouldn’t leave Automatic network ownership on for most things though, saving server performance is saving server performance and after a certain point you will start to see more performance problems by not using it, its just that that point is a lot further along than it used to be, and, those bars are different on the server vs the client. (It’s a lot worse when you have a lot of parts on one client vs 10 or 20 projectiles, and, its also a lot worse if you have one or two really really massive assemblies that are calculating for everything)
how could i remove pysics throttling or is that not possible. because theres still some lagg in the pysics when i spawn much parts
Afaik you can’t disable Physics Throttling. Physics Throttling just makes the parts move in slow motion though, which, keeps the overall performance better.
If the droppers are dropping the same parts then tri count shouldnt be a problem due to the optimization method called instancing, its not the tri count causing the lag, its probably the physics, the parts are probably unanchored, instead of unanchoring them try tweening them out of the dropper, then the conveyer belt should do the rest, Aotrou is the master of optimization (I don’t want to tag him) so I’ll post a link of him on RDC talking on building worlds for game performance, if you want just skip to the part where he talks about instancing, but StreamingEnabled can also help you, but only works in some cases, if the player is always moving at walks peed then it should be fine, or as long as they aren’t moving too fast, if they are, don’t turn on StreamingEnabled, by the way, StreamingEnabled is one of the properties of the Workspace.
the whole problem is that the parts move slower 
Another way you can reduce lag is with part pooling. Generally there isn’t that much of a performance decrease when you destroy or create new instances, but if you are doing it a lot then it can have a pretty big impact on performance and create much lag. That said, many tycoon games do this and only a few use part-pooling. Part pooling, if you don’t know, is a way to reduce the performance loss from instancing by keeping a queue of parts that are never destroyed. Here’s a module from community resources to help get you started:
Also, if this is a tycoon game then having so many parts managed by the server that physics throttling kicks in doesn’t change the fact that with that many parts the player is still receiving a large amount of money.
I have one last trick as well, set your parts/meshes to the Neon material, and, if you don’t want them to glow, darken their color. It’s not commonly known, but, Neon parts are actually faster to render than Plastic & SmoothPlastic parts, and ForceField parts can be second fastest depending on a few different factors.
Any repro or source on this? Very curious
Actually, because they move slower, destroyable effects such as a fire effect that kills an ore in 4 seconds might be impossible to do. (Miner’s haven reference, so annoying)
The source is me 
But in all seriousness I talk about it here in more detail and give a possible explanation for why its the case:
(PSA) The Neon material is one of the fastest materials - Development Discussion - DevForum | Roblox
The best repro I have is my own game which I linked in the replies there, and, its where I ended up figuring this out. Really the easiest way to test this is to generate a very large grid of parts with the SmoothPlastic or Plastic material with their faces all on Smooth. If you switch all of these parts to Neon, you should see a pretty noticeable boost in your FPS. I’ve had six or seven people test this out already on varying hardwares, and, they’ve confirmed its the case for them.
Here’s a brief summary on why I think this is the case:
1 can exist and will have a bloom effect applied to them. (That also means that just by darkening the color of Neon parts you should be able to get the original color of your parts exactly)@Enk514 Part instancing does not remove the cost of rendering extra triangles. Part instancing is an optimization that reduces the cost for rendering the same mesh data. It still costs more frame time to render 100 parts vs 10 parts, its just that with Part instancing it costs a lot less to render the same 100 parts than it did before. The triangle count is still absolutely a problem when it comes to FPS lag.
@Michel2003g I apologize for not responding before. Unfortunately, there isn’t a way to get rid of physics throttling. Physics throttling is primarily caused by low server heartbeat or low player FPS. Since the issue isn’t FPS lag like I thought it was, I would actually recommend doing the opposite of what I said in this case. Rather than setting all dropper parts to be simulated server side, you can set them all to be simulated client side. This would allow exploiters to control the physics of those parts, but, for a tycoon game that’s not too big of a deal. Just make sure that those parts have collision groups that don’t collide with players.
Alternatively, you could just not use Roblox physics at all, and instead simulate your dropped parts yourself. That would allow you to completely disable collisions so there isn’t any physics cost at all, you won’t get throttling, and, since Roblox is adding some optimizations with CanTouch, if CanTouch and CanCollide are both off, and the part is Anchored, it will pretty much cost nothing.
One way you could do this is to anchor your dropped parts and on Heartbeat move the object conveyor.AssemblyLinearVelocity * frameTime to simulate the conveyor movement. You could do a ray cast below each dropped part to find the conveyor below it, and, if you don’t find a conveyor or you find a part with no velocity you could just use what ever the last conveyor’s velocity was. The initial previous conveyor velocity could just be 0 0 0 that way if you’re spawning the part off the conveyor initially you won’t get any errors.
If you want the part to fall, when you raycast, you can start simulating the part falling when there is no conveyor. You can store its speed in AssemblyLinearVelocity. You could just use some basic physics and subtract droppedPart:GetMass() * workspace.Gravity from its Y velocity. (E.g. droppedPart.AssemblyLinearVelocity += Vector3.new(0, -droppedPart:GetMass() * workspace.Gravity, 0).
And, lastly, so that the part doesn’t float above the conveyor, you could calculate the correct height for your dropped part with conveyor.Position + Vector3.new(0, conveyor.Size.Y + droppedPart.Size.Y, 0)/2 (from the center of the conveyor, you add half its Y size to get the top. Then you add half the dropped part’s size since you want the bottom of the dropped part to be touching that height, not the center. You can just set the part’s CFrame to CFrame.new(part.Position.X, calculatedHeight, part.Position.Z) in your heartbeat loop.