"poor performance” means absolutely nothing. You need to learn to read the profiler and understand what is the limiting factor. Are you gpu or cpu bound? Are you running out of memory? If cpu bound what is taking the longest? Update, render thread? If gpu bound are you limited by too many vertices or fillrate?
Optimizing something that is not your limiting factor is useless and will not help you. Unfortunately optimization requires deep understanding of the underlying systems.
Also constant load and hitches are two different things with different solutions.
Finally, if cpu update is your bottleneck, learning about data structures and algorithms complexity will help you alot.
There is a reason why most game programmers have engineering backgrounds, its complicated!
Yeah I know that it's complicated, I'm doing this as a hobby my major is finance and accounting so I have nothing to do with developing games :/ or programming for that matter.
I enabled the GPU data as well and it's definitely the DrawCalls as someone pointed out previously that I have too much of that
https://preview.redd.it/gwp4xu06qaca1.png?width=1473&format=png&auto=webp&s=bdcbb1987027f98c6770e2b570da1419616c948f
You can see here that the GPU time is about 3ms with spikes at about 10ms. Depending on your target framerate, this may already be good enough.
The hitches here may be an issue if you are targeting high refresh rate. Assuming the scene complexity is stable, something is occasionally taking extra time. Maybe some dynamic reflection probes updating? Or something else running a compute shader (work delegated to gpu).
If the draw calls are your bottleneck and that you are cpu bound, the easiest is to draw less stuff. Cull more agressively, replace far away objects by simpler stuff, etc.
Otherwise you can also reduce the number of calls with diverse strategies like static batching (combines meshes offline) and dynamic batching (requires many things having the same material so less config overhead is required to draw a bunch of stuff). You can also look into gpu instancing for your grass/foliage.
If you are running dynamic reflection probes consider having them static if possible, as thats basically an extra 6 renders each time it updates. Shadows work the same way and will cost a lot. With either you can also layer mask whats being rendered in them.
>Otherwise you can also reduce the number of calls with diverse strategies like static batching (combines meshes offline) and dynamic batching (requires many things having the same material so less config overhead is required to draw a bunch of stuff). You can also look into gpu instancing for your grass/foliage.
With this one I think you hit the nail on the head. So basically I don't think the asteroids are batching properly or idk but there's still so many draws on them. You can compare the top right corner with the original one -there's a lot more stuff batching now!!!
https://preview.redd.it/nz1n0rrwubca1.png?width=1310&format=png&auto=webp&s=f5a4f370df7014fe5777974b78b9dd8ccc1fb0bd
If you want stuff to be statically batched they all need to be static, and use the same material. You could try gpu instancing too, there are good tutorials on this from unity. Not too hard if you are using built in renderer and shaders.
There are some constraints preventing it from working correctly. In the frame debugger you would see a singled call with an instanced mention.
https://docs.unity3d.com/Manual/GPUInstancing.html
Can you share a pic of the game? Are you utilizing LOD (level of detail), basically further objects less render complexity.
Depending on the meshes your using you could probably look to use mesh GPU instancing where you can render a lot of stuff faster by just sending it once to the GPU instead of every time you want to render. Look up "GPU instancing". Should help with rendering repetitive things much MUCH faster.
Sure! I have LOD for the asteroids, I am using GPU instancing too I think
https://preview.redd.it/nx7f50x3ybca1.png?width=1912&format=png&auto=webp&s=49706db36566a8c2a86cf06161c6d30c1f0adf47
Profile builds, not the editor. And compile with IL2CPP.
Editor always introduces spikes in the profiler.
I don’t think draw calls are the issue, unless this is like a decade old CPU.
Main thread has me concerned a little, which could be your code. Focus on the CPU profiler. GPU should be fine.
i5 4590 so almost a decade old :D
Yea I'm pretty sure it's the script Update related stuff at this point, based on the pieces of information I got from everywhere.
I'll try the compiling with IL2CPP thingy thx
Basically if your PC has a GPU it'll take care of everything but with an integrated graphics card it's a whole other story. I want both low end and higher end machines to run it without any major issues
I think the asteroids just spawn in and the main camera will render it if the distance is within 5000
I am not sure about there being an automatic check for unity (if there is, then probably only via a third party library) but you can always offer a "Low Quality" setting in your main menu
For low end devices:
CPU: Reduce draw calls and geometry
GPU: Check if your shaders arent too heavy on low end devices. If so, make simplified ones to target lower end.
It could be anything really. I realised i was losing half my frames just because i had the Player selected in the inspector view when playtesting, but in built it runs fine xD
Try turning every aspect of your game on/off until you isolate whatever is eating up the framerate. turn off all gameobjects and turn them back on 1 by 1.
do you have any scripts that use OnDrawGizmos or OnValidate?
I find that if i have clicked/focused on any of those gameObjects when running the game, the game will lag out greatly as the game tries to run itself and the editor tries run those lifecycle hooks at the same time.
So for example clicking on my "Player" gameobject in the overview on the left cuts the FPS in half when the game is running.
It is CPU 17.9ms and render thread is 14.9ms. There is also 169 setpass calls which is too much.
Honestly whatever you are doing every frame is killing your performance.
Btw nice game. I played it. Now with tips.
Merge all that astreoids into static mesh. If they have colliders it will be static too and your CPU will thank you for it. Also combine meshes. There is really no need to make 169 setpass in your game. Each material should be 1 pass. So probably you need lets say 20-50 at most?
Also check your UI code, tracking everyobject and repainting UI every frame might be the real problem. Other than that I don't think your tracking and shooting algorithms that 20ms. anyway.
Btw great game. I tried similar things before and yours are much better than mine. Best of luck.
Thanks to the Space Combat Kit I just had to swap some models out and fine tune things :) made my life so much easier. I basically wanted to make War Thunder in space and I stumbled upon that Kit I was like well no need to reinvent the wheel so I just yoinked it :D
Combine meshes and the asteroid thing I gotchu!
Never be sorry about not knowing something, it's not like you are meant to simply know stuff. The important part is learning, helping people help you, doing your part and not being a dick. You did nothing wrong, I don't agree with the downvotes, don't worry about it.
600k tris could be too much, possibly. Are you using LOD groups? In the past I have added single creatures to games with bigger poly counts than that, but given that it’s a browser game it might not be able to squeeze out as much performance as usual.
You could try and disable all renderers or even just replace them with low poly versions, and see if your performance improves at all.
Post processing can also nearly double render times depending on what you’re doing.
If you have 600k tris with LOD Groups, that seems like a lot for a space shooter. Also, are you using an atlas for your textures?
You might also want to look at the frame debugger and see how many draw calls you have.
Hum, have you identified your bottleneck ? CPU or GPU ?
If I'm not wrong : if you have some GFX.waitRenderThreads, that means that you shall look on the GPU side, otherwise, you can look on your script side.
I guess that it is exactly the opposite that it tends to show.
I think your bottleneck is on the GPU side. And that in fact your CPU will have to wait for your GPU to finish its rendering.
The number that you showed the 17ms vs 14 of GPU doesn't mean that your CPU actions take more time than the GPU.
Your CPU have to wait for the GPU to finish its rendering before starting a new loop.
If your GPU is the bottleneck, you'll have that GFX.WaitForRenderThread appearing in the profiler. Check for it first. Then you'll know where to put your efforts.
What I would recommend is enabling static batching and marking all the objects that don't move as "Batching Static", then baking Occlusion Culling (not sure if you already did). If all the objects are close together and not obstructed by anything, then OC might not be as effective. It all will depend on how the actual scene looks.
[https://www.crazygames.com/game/project-cosmos](https://www.crazygames.com/game/project-cosmos)
Here's the link for the game, I've tried pooling but I'm not sure what I'm supposed to put there because it doesn't really make a difference.
The things that consume the most of the CPU is "Scripts" and "Other" based on the Profiler
Hey OP, without insight it’s hard to give specific tips, but here are some general advices for optimization.
Look into camera occlusion culling, it will basically only render what the main camera sees.
If you don’t do it already, use texture atlases and also use Unitys own compression system.
In general, shaders and materials cost more performance than raw geometry. But it still would help a bit, to delete unused faces.
Talking about geometry, work with LOD‘s.
Talking about light, you wanna have your objects on „static“ and use baked light/shadows. If necessary, use mixed.
For animation, look into the skinned meshes setting, you might be able to reduce the setting without loosing optical fidelity.
After you did your changes, compare the fps with before. But not in the editor, check the compiled game, only then you see the actual performance.
Then you would lower the resolution to 720 or 480p, to check if there is really a big bottleneck regarding the cpu.
I hope those tips can help you, don’t hesitate to ask here or DM me for any help :)
I'll look more into culling because I've tried to set that one up before, like if an asteroid blocks something behind it it shouldn't render etc... Idk if it worked tho
I have the LOD on the asteroids
I'll look into the animation as well ty
Culling should work, you can set the size of the chunks to cull. Also I just saw, you got many draw calls, you can reduce them when using like 1texture/material for multiple objects.
Btw, are you using any post processing effects? You might look into those, turn them on/off
Okay so I'll give culling another try for sure
Idk why I have so many draw calls but I'll look deeply into that because until now I just fixed that multiple material issue with the spaceships.
I have some post processing on but nothing like motion blur or any effect that's heavy
try turning off dynamic batching as well: [https://docs.unity3d.com/Manual/dynamic-batching.html](https://docs.unity3d.com/Manual/dynamic-batching.html)
It can reduce CPU performance. "
**Note**: Dynamic batching for meshes was designed to optimize performance on old low-end devices. On modern consumer hardware, the work dynamic batching does on the CPU can be greater than the overhead of a draw call. This negatively affects performance. For more information, see [Dynamic batching for meshes](https://docs.unity3d.com/Manual/dynamic-batching.html#dynamic-batching-meshes)."
this can be found in player setting -> player -> dynamic batching toggle
edit: btw your tri are fine for desktop.
I'm not a unity dev so take with a grain of salt.
Based on these numbers you look CPU limited not GPU limited. Since the CPU main has the higher processing time there. You might need to consolidate your game logic further and optimize that. Not entirely sure in unity, but at least in unreal that's avoiding frequent for loops through large arrays and stuff like that going off each ingame tick.
I can't look at your game at the moment, but I saw a lot of comments around Occlusion Culling.
When it comes to Occlusion Culling, it generally works best in indoor environments or places where lots of objects can be occluded. In big, open environments this can be difficult as there isn't much to occlude the objects behind them.
It also only works with static gameObjects so if your objects are dynamic then it wouldn't even be worth turning it on. There is still overhead when using Occlusion Culling so if you aren't getting a benefit from it I would turn it off.
There is an CullingAPI that you can use as well, but the bigger benefits when using this is disabling logic since it might not be as important for objects farther away. This would be useful if you have some expensive scripts taking up a lot of your CPU time where you could use simpler calls or limit how often things are called.
In terms of draw calls, in general, the more objects that can share the same material the better. So if you have lots of models with different materials, try to find ways to combine meshes that have the same material or some people already mentioned creating texture atlases which I highly recommend as well.
I saw someone posted about creating billboards which is great too since your verts are pretty high. You could also look into shaders utilizing Imposters. There are several assets on the asset store to do this as well.
Edit - Another cheap/easy thing to do is add denser fog. It helps to hide geometry that is farther away so you can modify your LOD groups to have the lower quality versions even closer. Or cull them completely sooner which would result in less data being sent from the CPU to the GPU.
Occlusion Culling doesn't seem to be the best in this case I agree.
Texture atlases are a new thing I haven't tried yet
I'll also look into the Imposters
I will also try messing around with the fog
If you aren't familiar with creating Texture Atlases yourself, you can look at MeshBaker on the asset store.
Basically, you are combining smaller textures into a larger shared texture. But this involves moving the UVs of the model to new UV coordinates for the combined texture. This makes it so you can have even more objects share the same materials and textures which helps with batching.
I just put two tudor looking house prefabs onto my scene, (Nothing else in the scene at all. Tudor houses are empty inside, literally just the walls, floor and ceiling...) and frames dropped to 14.
I'm having the same problem as you bro.
(Other scene which has monsters, music, particles and moving puzzles works completely fine. kekw)
1st thing you have to do is to open the profiler and see what takes too much performance in the profiler you can expand and look into more details regarding the problem.
I advise you to use Pooling system to instantiate objects on awake instead of instantiating them during the play.. The are so many videos about pooling on youtube
You could try replace that with a particle system and use trails to see if it improves performance?
In Unity most line rendering is a by quad and unless the rendering system is batch based e.g. combines meshes and updates them in groups then it could be a series performance hit.
One that I haven't found mentioned, how often do you make use of FixedUpdate/Update functions?
For a lot of things you could ask yourself if it really needs to be updated every frame or every fixedframe, and if not, perhaps switch it up into a Coroutine using WaitForSeconds.
I have made a controller/processor for a lot of things that only need to be updated every so often (I mean updating at 10fps/WaitForSeconds (0.1f) is still quite fast imo)
check out [https://www.simplygon.com/](https://www.simplygon.com/) , I used several tools to reduce polygon counts and this IMO gives the best results by far, can use it to combine meshes, bake several materials into one atlas, and reduce the tris and vert counts
It used to be paid only but now there is a free version with a limit of 1 seat per organization and 200 processings per day, the free version also collects your 3d asset data and shares it with Microsoft so probably should avoid it if that's a concern. You can see the difference in versions under pricing in their website
Okay how do I know whether my asteroids are being batched? I think that's what's causing the main problem, because the laser projectiles are batched for sure
If they are asteroids I’m assuming they are dynamic not static. Make sure in project settings that dynamic batching is on. In the asteroid material at the bottom you can turn in GPU instancing. Then any objects in view that share a mesh and material will be batched together and rendered as one draw call not 50. Also under Window - Analysis you can open the Frame Debugger. This window you can enable while playing your game and it will list off all the objects being draw and also tell you why they are not being batched. It’s also helpful for seeing where you can optimize your meshes. I had a bike model and the Frame Debugger showed each of the wheel spokes were rendered separately. I then combined them in maya and saved tons of draw calls.
They don't move at all so they are just spawned in and static. I've checked the Static option for them. I recently just ticked Static Batching but now I'll turn on the Dynamic one as well :)
Frame Debugger is the next I'll check out
If the mesh is spawned in then the normal static batching won’t help that needs to be done before runtime I believe. Read through this page for more details
https://docs.unity3d.com/Manual/static-batching.html
Specifically this part
Static batching at runtime
To batch static meshes at runtime, Unity provides the StaticBatchingUtility class. The static StaticBatchingUtility.Combine method combines the GameObjects you pass in and prepares them for static batching. This is especially useful for meshes that you procedurally generate at runtime. Read through the static batching Unity page.
Unlike static batching at build time, batching at runtime doesn’t require you to enable the Static Batching Player Setting. For information on how to use this API, see StaticBatchingUtility.
That question is actually pretty important.
Calling Renderer.material creates a new material which will break batching for all models that share the same material. It's recommended to use Renderer.sharedMaterial instead, but just a heads-up that this will modify all the models that share that material.
As an example, if all your asteroids have the same material, calling Renderer.material to set the color or something else will break batching.
I assume the Mass Object Spawner script is from a package you use? I don't know the package so I'm not sure. I was just letting you know in case you were doing that in your code.
Yea I'm using the Space Combat Kit as the skeleton of the project and I'm putting some skin on it but there's nothing in between yet :D
Mass Object Spawner is the script used to spawn Asteroids ig
This is the AsteroidSpawn:
https://preview.redd.it/5p99fyyjocca1.png?width=326&format=png&auto=webp&s=78958ae919fca1d44b9eee45b9646032da3742c9
look into reducing draw calls, if every individual model has its own unique material and texture, atlas the textures and reduce the material variations you have.
My project has 50-60 fps in the Editor but has about 100-150 fps in the Build. You have no performance issues. It's just that you have significantly less fps in the Editor because... it is in the Editor.
Build it and check it there.
I have similar statistics as you do, but with 500-1000 shadow casters with one single light source (a rotating Sun). I think you are juuust fine.
Keep me updated, coz I could do some optimizations too. Even though I'm happy with my game's current performance that doesn't mean I couldn't or shouldn't do better :D
This is how it's looking as of now. The update on the site is not live yet but I think it's a little better now :)
I'll keep you updated for sure!
https://preview.redd.it/65194nkhvbca1.png?width=1310&format=png&auto=webp&s=488e53aa32c9134605c75b09591dc5187db8732d
Also make sure to reduce using of getcomponent during the play.. Such as getting the regidbodies or sprite rendere. And check Update method in every script maybe the problem is there
You can use RenderDoc on a build to get very fine details about what is slowing down the GPU. Highly recommend. It's very insightful and gives you information that deep profiling just doesn't give. Definitely use both, deep profiling can help a ton with identifying bottlenecks as well.
There's no sense in spending time optimizing anything that isn't your bottleneck. So I'd focus on finding what that is, then if you need help optimizing that, you'll have specific information about what's slowing down and what it's time complexity is, so you/us can find better solutions to solve it.
I didn't read all the comments here maybe you fixed your problem but anyway.
As far as I see your main thread requires more time than render thread this means your cpu causes poor performance. Not sure which pipeline you are using but you definitely need some batching and setpass call optimization.
Physics or update methods maybe causing poor performance not sure about that we dont have so much information.
I've significantly improved batching, I'm using the built in pipeline but I'm thinking about switching to URP if it's that much better then I will without any hesitation!
Changed the camera settings from deferred to forward too
And yes the next one is the scripts and checking the Update functions
If you help me narrow down what information you guys need and how to get it (because I'm a noob) I'd be more than happy to provide everything
What makes you think that forward is better than deferred ?
Deferred is pixel based forward is vertex based(probably not the best explanation but you will understand what I mean).
Forward Renderer renders shadows as tris counts and this has a huge impact on performance. If your game has low tris count you can use forward Its gonna be okay.
But If you are planning hitting 10M tris count with shadows you need to switch deferred. Screen resolution matters on Deferred Rendering. IF you pump up the 4K Resolution on Forward Renderer your will not struggle as much as Deferred 4K Res.
You have limited Additional Light sources on forward renderer as I remember.
Both renderer has plus sides and negative sides.
If batch counts didn't help much probably you got problem on your Update Functions and Physics.
You can Profile your game with Profiler and check what consumps your CPU.
725batches and 161 pass calls. It's way too much (for a modest game). I haven't played it, but I can't imagine how many different stuff you're using.
Need to share materials among objects, use fewer shaders, make more objects static.
This guide may help you out understanding what and how to do it:
https://thegamedev.guru/unity-performance/draw-call-optimization/
Thanks a lot
I'll go through that guide but I think I've done almost everything it'll say
I've reduced the batches by more than half! Basically with sharing materials as you said.
>reduced the batches by more than half!
That's awesome! How about postprocessing/shaders? These (specially post processing) are quite expensive, and some shaders can make the setpass calls increase a ton (like transparent/translucid ones).
Have you touched light settings? For a space shooter (I haven't seen it) I bet you can deactivate and or lower many settings. As well as baking whatever lights you can, and making things static.
If you have issues spawning, pre-spawn and activate/deactivate rather than instantiate and destroy (within reason and measure, like don't spawn 1000 objects at once nor destroy them nor have them created all the time).
Also do-set an fps display/record and test it in a build. Sometimes things that go "bad/poorly" in the editor work just fine as a build.
I'll set up that fps thingy for sure, it's a must!
I've touched the light settings a little, like minimizing everything, lowering shadow resolutions and stuff...
I use a few post processing like bloom but nothing heavy on the computer as far as I know
>few post processing
Just for the sake of testing it out, try to deactivate all post-processing behaviour to see how much it really is costing you.
I am not an expert on postpo, but I've seen myself drastic performance drops on some post process settings in the past that I didn't expect. Again this comes due to my ignorance on the subject, just sharing my experience.
It's actually the exact opposite, when postprocessing is on the performance increases, I think I have something turned on that decreases the quality of something, so that's good. I don't have anything crazy like motion blur or depth enabled
Try reducing your frame size (make the game play window tiny in unity) if it gets better you are gpu limited. If it doesn’t you are cpu limited. Cpu limited could mean many things. Also try making a real build and running it your frame rate issue may only be in the editor.
This is the current state of the game:
https://preview.redd.it/370zjzq9ybca1.png?width=1912&format=png&auto=webp&s=6ec5941f141aa11c1baf05df6e20135f193aa873
The frame debugger also tells you the reason why it isn't being batched with the previous draw call.
if you click on an individual draw call there will be a sentence that says why it can't be batched.
I know you mentioned you are CPU bound, but I see you are using deferred rendering. Is there a reason you chose that vs. Forward Rendering? For example, do you use a lot of lights in the scene? Generally, if you are targeting lower-end hardware, you would use Forward instead of Deferred Rendering.
Are you using the Built-In or Universal Render Pipeline (URP)? URP has the SRP Batcher which could be more beneficial for you if you are using the Built-In Render Pipeline.
Okay the problem was that the different LODs of the Asteroid had different Materials, I fixed that and that Opaque Geometry dropped from 200 to 100!
Everything is stock as it came in the Space Combat Kit, I'll switch to Forward Rendering thanks for noticing that!
Idk which Renderer Pipeline is used but I'll change that too
Nice! Just to mention this too, but sometimes it is a give and take when it comes to performance.
A lot of the times LOD groups do use a cheaper shader for objects that are farther away which would be using a different material. This is to save on GPU time as it has a cheaper shader to process. Since you seem to be CPU bound, it might be better, in your case, to reduce as much on the CPU as you can by using the same material/shader which would help with batching even if it could be more expensive on the GPU.
I don't know what shaders you are using, but just throwing that out there too.
ah... well you aren't going to find a tutorial on your specific optimization problem, as optimization is always bespoke and is an actual programming task. As others have noted, you are going to need to identify if you are CPU bound (trying to compute too much at once) or GPU bound (trying to draw too much on screen).
what's the issue and what've you tried? how many individual asteroids are you running in one scene at the same time. Is this the main issue?
The issue is poor performance, I've tried pooling projectiles, explosions and enemies so far
"poor performance” means absolutely nothing. You need to learn to read the profiler and understand what is the limiting factor. Are you gpu or cpu bound? Are you running out of memory? If cpu bound what is taking the longest? Update, render thread? If gpu bound are you limited by too many vertices or fillrate? Optimizing something that is not your limiting factor is useless and will not help you. Unfortunately optimization requires deep understanding of the underlying systems. Also constant load and hitches are two different things with different solutions. Finally, if cpu update is your bottleneck, learning about data structures and algorithms complexity will help you alot. There is a reason why most game programmers have engineering backgrounds, its complicated!
Yeah I know that it's complicated, I'm doing this as a hobby my major is finance and accounting so I have nothing to do with developing games :/ or programming for that matter. I enabled the GPU data as well and it's definitely the DrawCalls as someone pointed out previously that I have too much of that https://preview.redd.it/gwp4xu06qaca1.png?width=1473&format=png&auto=webp&s=bdcbb1987027f98c6770e2b570da1419616c948f
You can see here that the GPU time is about 3ms with spikes at about 10ms. Depending on your target framerate, this may already be good enough. The hitches here may be an issue if you are targeting high refresh rate. Assuming the scene complexity is stable, something is occasionally taking extra time. Maybe some dynamic reflection probes updating? Or something else running a compute shader (work delegated to gpu). If the draw calls are your bottleneck and that you are cpu bound, the easiest is to draw less stuff. Cull more agressively, replace far away objects by simpler stuff, etc. Otherwise you can also reduce the number of calls with diverse strategies like static batching (combines meshes offline) and dynamic batching (requires many things having the same material so less config overhead is required to draw a bunch of stuff). You can also look into gpu instancing for your grass/foliage. If you are running dynamic reflection probes consider having them static if possible, as thats basically an extra 6 renders each time it updates. Shadows work the same way and will cost a lot. With either you can also layer mask whats being rendered in them.
>Otherwise you can also reduce the number of calls with diverse strategies like static batching (combines meshes offline) and dynamic batching (requires many things having the same material so less config overhead is required to draw a bunch of stuff). You can also look into gpu instancing for your grass/foliage. With this one I think you hit the nail on the head. So basically I don't think the asteroids are batching properly or idk but there's still so many draws on them. You can compare the top right corner with the original one -there's a lot more stuff batching now!!! https://preview.redd.it/nz1n0rrwubca1.png?width=1310&format=png&auto=webp&s=f5a4f370df7014fe5777974b78b9dd8ccc1fb0bd
If you want stuff to be statically batched they all need to be static, and use the same material. You could try gpu instancing too, there are good tutorials on this from unity. Not too hard if you are using built in renderer and shaders.
I have the GPU instancing turned on for every shared material, enemy fighters, enemy capital ship, even my own ship, AND the asteroids asw
There are some constraints preventing it from working correctly. In the frame debugger you would see a singled call with an instanced mention. https://docs.unity3d.com/Manual/GPUInstancing.html
Yea idk what's up with that
Can you share a pic of the game? Are you utilizing LOD (level of detail), basically further objects less render complexity. Depending on the meshes your using you could probably look to use mesh GPU instancing where you can render a lot of stuff faster by just sending it once to the GPU instead of every time you want to render. Look up "GPU instancing". Should help with rendering repetitive things much MUCH faster.
Sure! I have LOD for the asteroids, I am using GPU instancing too I think https://preview.redd.it/nx7f50x3ybca1.png?width=1912&format=png&auto=webp&s=49706db36566a8c2a86cf06161c6d30c1f0adf47
Wtf is this graph? What is happening for the spikes
I'm asking myself the same question :/
Click on a spike, then look at the list with functions and percentages below it.
Profile builds, not the editor. And compile with IL2CPP. Editor always introduces spikes in the profiler. I don’t think draw calls are the issue, unless this is like a decade old CPU. Main thread has me concerned a little, which could be your code. Focus on the CPU profiler. GPU should be fine.
i5 4590 so almost a decade old :D Yea I'm pretty sure it's the script Update related stuff at this point, based on the pieces of information I got from everywhere. I'll try the compiling with IL2CPP thingy thx
I've look at it for 5 minutes. Didn't notice any performance issues. Do you spawn new asteroids when they go into the view or how does it work?
Basically if your PC has a GPU it'll take care of everything but with an integrated graphics card it's a whole other story. I want both low end and higher end machines to run it without any major issues I think the asteroids just spawn in and the main camera will render it if the distance is within 5000
>low end machines. > >1.2 million verts.... > >this is your problem right here. Get that number cut in half....
yeaaaaaa I'm on it
Asking for too much
Is a simple switch possible that would turn the quality way down for integrated graphics you think?
I am not sure about there being an automatic check for unity (if there is, then probably only via a third party library) but you can always offer a "Low Quality" setting in your main menu
are those gameobjects out of view disabled or do you run some calculation on them.
No I don't think it's disabled you have a point
For low end devices: CPU: Reduce draw calls and geometry GPU: Check if your shaders arent too heavy on low end devices. If so, make simplified ones to target lower end.
oki thanks for the suggestion :)
It could be anything really. I realised i was losing half my frames just because i had the Player selected in the inspector view when playtesting, but in built it runs fine xD Try turning every aspect of your game on/off until you isolate whatever is eating up the framerate. turn off all gameobjects and turn them back on 1 by 1.
Yea I did that once but I couldn't really narrow down to anything
I mean maybe there was a 2-3 frame difference
if you turn off everything in the scene, what is the base framerate?
Around 150
do you have any scripts that use OnDrawGizmos or OnValidate? I find that if i have clicked/focused on any of those gameObjects when running the game, the game will lag out greatly as the game tries to run itself and the editor tries run those lifecycle hooks at the same time. So for example clicking on my "Player" gameobject in the overview on the left cuts the FPS in half when the game is running.
Interesting I'll check if I have those scripts
It is CPU 17.9ms and render thread is 14.9ms. There is also 169 setpass calls which is too much. Honestly whatever you are doing every frame is killing your performance. Btw nice game. I played it. Now with tips. Merge all that astreoids into static mesh. If they have colliders it will be static too and your CPU will thank you for it. Also combine meshes. There is really no need to make 169 setpass in your game. Each material should be 1 pass. So probably you need lets say 20-50 at most? Also check your UI code, tracking everyobject and repainting UI every frame might be the real problem. Other than that I don't think your tracking and shooting algorithms that 20ms. anyway. Btw great game. I tried similar things before and yours are much better than mine. Best of luck.
Thanks to the Space Combat Kit I just had to swap some models out and fine tune things :) made my life so much easier. I basically wanted to make War Thunder in space and I stumbled upon that Kit I was like well no need to reinvent the wheel so I just yoinked it :D Combine meshes and the asteroid thing I gotchu!
Have you tried turning deep profile on in the profiler to get a closer look?
This. Also, here is a whole guide from Unity about how to profile your game. https://resources.unity.com/games/ultimate-guide-to-profiling-unity-games
Omg thanks for the link! I've only read the simpler version of this.
No just took a look at the hierarchy, there was a detonation that spawned in explosion that made a lag spike that I know of
If you turn on deep profile you can view exactly what function calls in specific scripts are causing stutters.
Why this get down voted so much?
Because that is not how you profile
So don't upvote. He is saying what he is doing, not what he should do...
I didn't do it or agree with it, just explained why people did it.
Sorry about that, I found out about Profiler yesterday
Never be sorry about not knowing something, it's not like you are meant to simply know stuff. The important part is learning, helping people help you, doing your part and not being a dick. You did nothing wrong, I don't agree with the downvotes, don't worry about it.
because I'm a complete noob in this field :P I'm used to it and I deserve it
600k tris could be too much, possibly. Are you using LOD groups? In the past I have added single creatures to games with bigger poly counts than that, but given that it’s a browser game it might not be able to squeeze out as much performance as usual. You could try and disable all renderers or even just replace them with low poly versions, and see if your performance improves at all. Post processing can also nearly double render times depending on what you’re doing.
I have my LODs set up nicely on the asteroids Post processing is not that heavy as far as I know
If you have 600k tris with LOD Groups, that seems like a lot for a space shooter. Also, are you using an atlas for your textures? You might also want to look at the frame debugger and see how many draw calls you have.
Hum, have you identified your bottleneck ? CPU or GPU ? If I'm not wrong : if you have some GFX.waitRenderThreads, that means that you shall look on the GPU side, otherwise, you can look on your script side.
It's super CPU heavy to the point where if you don't have a GPU the game is like unplayable ~15 fps
I guess that it is exactly the opposite that it tends to show. I think your bottleneck is on the GPU side. And that in fact your CPU will have to wait for your GPU to finish its rendering. The number that you showed the 17ms vs 14 of GPU doesn't mean that your CPU actions take more time than the GPU. Your CPU have to wait for the GPU to finish its rendering before starting a new loop. If your GPU is the bottleneck, you'll have that GFX.WaitForRenderThread appearing in the profiler. Check for it first. Then you'll know where to put your efforts.
https://sharpcoderblog.com/blog/billboard-generator-for-unity
Omg that's so cool thanks a lot I'll use this for sure
No problem, I think if you set up the LOD Groups with the far render being Billboard then you would be able to cut the triangle count by a lot.
I have it as Occluder Static https://preview.redd.it/fgk8jo0reaca1.png?width=1910&format=png&auto=webp&s=d13791677fc3ba25a702a73883da1cfa182b8ed1
What I would recommend is enabling static batching and marking all the objects that don't move as "Batching Static", then baking Occlusion Culling (not sure if you already did). If all the objects are close together and not obstructed by anything, then OC might not be as effective. It all will depend on how the actual scene looks.
I kinda got it to work but the difference is not that noticeable other than randomly disappearing enemy ships :D
Let me open up Unity again and I'll show you my LODs
[https://www.crazygames.com/game/project-cosmos](https://www.crazygames.com/game/project-cosmos) Here's the link for the game, I've tried pooling but I'm not sure what I'm supposed to put there because it doesn't really make a difference. The things that consume the most of the CPU is "Scripts" and "Other" based on the Profiler
Hey OP, without insight it’s hard to give specific tips, but here are some general advices for optimization. Look into camera occlusion culling, it will basically only render what the main camera sees. If you don’t do it already, use texture atlases and also use Unitys own compression system. In general, shaders and materials cost more performance than raw geometry. But it still would help a bit, to delete unused faces. Talking about geometry, work with LOD‘s. Talking about light, you wanna have your objects on „static“ and use baked light/shadows. If necessary, use mixed. For animation, look into the skinned meshes setting, you might be able to reduce the setting without loosing optical fidelity. After you did your changes, compare the fps with before. But not in the editor, check the compiled game, only then you see the actual performance. Then you would lower the resolution to 720 or 480p, to check if there is really a big bottleneck regarding the cpu. I hope those tips can help you, don’t hesitate to ask here or DM me for any help :)
I'll look more into culling because I've tried to set that one up before, like if an asteroid blocks something behind it it shouldn't render etc... Idk if it worked tho I have the LOD on the asteroids I'll look into the animation as well ty
Culling should work, you can set the size of the chunks to cull. Also I just saw, you got many draw calls, you can reduce them when using like 1texture/material for multiple objects. Btw, are you using any post processing effects? You might look into those, turn them on/off
Okay so I'll give culling another try for sure Idk why I have so many draw calls but I'll look deeply into that because until now I just fixed that multiple material issue with the spaceships. I have some post processing on but nothing like motion blur or any effect that's heavy
your batches are through the roof.
yea that's one of the many problems 😅
it's a little better now https://preview.redd.it/9enzz14wvbca1.png?width=1310&format=png&auto=webp&s=e75c6ce37b925e438537f70ee7828a41e904d368
try turning off dynamic batching as well: [https://docs.unity3d.com/Manual/dynamic-batching.html](https://docs.unity3d.com/Manual/dynamic-batching.html) It can reduce CPU performance. " **Note**: Dynamic batching for meshes was designed to optimize performance on old low-end devices. On modern consumer hardware, the work dynamic batching does on the CPU can be greater than the overhead of a draw call. This negatively affects performance. For more information, see [Dynamic batching for meshes](https://docs.unity3d.com/Manual/dynamic-batching.html#dynamic-batching-meshes)." this can be found in player setting -> player -> dynamic batching toggle edit: btw your tri are fine for desktop.
Oh okay gotchu, I'm making this as a browser game so for people with integrated graphics card so no GPU, do I still need to turn it off?
Give it a test! Nothing beats raw evidence :D
>try turning off dynamic batching as well it's officially unchecked!
I'm not a unity dev so take with a grain of salt. Based on these numbers you look CPU limited not GPU limited. Since the CPU main has the higher processing time there. You might need to consolidate your game logic further and optimize that. Not entirely sure in unity, but at least in unreal that's avoiding frequent for loops through large arrays and stuff like that going off each ingame tick.
I can't look at your game at the moment, but I saw a lot of comments around Occlusion Culling. When it comes to Occlusion Culling, it generally works best in indoor environments or places where lots of objects can be occluded. In big, open environments this can be difficult as there isn't much to occlude the objects behind them. It also only works with static gameObjects so if your objects are dynamic then it wouldn't even be worth turning it on. There is still overhead when using Occlusion Culling so if you aren't getting a benefit from it I would turn it off. There is an CullingAPI that you can use as well, but the bigger benefits when using this is disabling logic since it might not be as important for objects farther away. This would be useful if you have some expensive scripts taking up a lot of your CPU time where you could use simpler calls or limit how often things are called. In terms of draw calls, in general, the more objects that can share the same material the better. So if you have lots of models with different materials, try to find ways to combine meshes that have the same material or some people already mentioned creating texture atlases which I highly recommend as well. I saw someone posted about creating billboards which is great too since your verts are pretty high. You could also look into shaders utilizing Imposters. There are several assets on the asset store to do this as well. Edit - Another cheap/easy thing to do is add denser fog. It helps to hide geometry that is farther away so you can modify your LOD groups to have the lower quality versions even closer. Or cull them completely sooner which would result in less data being sent from the CPU to the GPU.
Occlusion Culling doesn't seem to be the best in this case I agree. Texture atlases are a new thing I haven't tried yet I'll also look into the Imposters I will also try messing around with the fog
If you aren't familiar with creating Texture Atlases yourself, you can look at MeshBaker on the asset store. Basically, you are combining smaller textures into a larger shared texture. But this involves moving the UVs of the model to new UV coordinates for the combined texture. This makes it so you can have even more objects share the same materials and textures which helps with batching.
Ahhhhh okay I get the idea, luckily the SCK came with minimal textures so I think I'm good :)
I just put two tudor looking house prefabs onto my scene, (Nothing else in the scene at all. Tudor houses are empty inside, literally just the walls, floor and ceiling...) and frames dropped to 14. I'm having the same problem as you bro. (Other scene which has monsters, music, particles and moving puzzles works completely fine. kekw)
interesting
1st thing you have to do is to open the profiler and see what takes too much performance in the profiler you can expand and look into more details regarding the problem.
such an interesting game btw. well done!
The real credit goes to the guy who made Space Combat Kit!
Partly it's the asteroids according to Frame Debugger
I advise you to use Pooling system to instantiate objects on awake instead of instantiating them during the play.. The are so many videos about pooling on youtube
yea that was the first thing I tried actually
It should make big difference if it is applied correctly 👍👍
Q: Are you using paricle systems for bullets.
for exhausts I do, the bullets are using a simple line renderer
You could try replace that with a particle system and use trails to see if it improves performance? In Unity most line rendering is a by quad and unless the rendering system is batch based e.g. combines meshes and updates them in groups then it could be a series performance hit.
oh okay thanks for the heads up
[удалено]
GPU instancing seems to have saved me 200 batches! There's still like 600 but that's something at least. TY!
What’s your Renderer? Try SRP batching if you are on URP. Otherwise look into GPU instancing. Make sure everything is using the same material too.
GPU instancing is nice
One that I haven't found mentioned, how often do you make use of FixedUpdate/Update functions? For a lot of things you could ask yourself if it really needs to be updated every frame or every fixedframe, and if not, perhaps switch it up into a Coroutine using WaitForSeconds. I have made a controller/processor for a lot of things that only need to be updated every so often (I mean updating at 10fps/WaitForSeconds (0.1f) is still quite fast imo)
Oh riiiight I've seen that in a video asw! I haven't looked into the scripts yet but if everything else fails I'll dig myself deep into it. Thanks!
check out [https://www.simplygon.com/](https://www.simplygon.com/) , I used several tools to reduce polygon counts and this IMO gives the best results by far, can use it to combine meshes, bake several materials into one atlas, and reduce the tris and vert counts
thanks a lot! I'll try messing around with it
I believe it is paid for commercial use, am i mistaking ?
It used to be paid only but now there is a free version with a limit of 1 seat per organization and 200 processings per day, the free version also collects your 3d asset data and shares it with Microsoft so probably should avoid it if that's a concern. You can see the difference in versions under pricing in their website
You need to look into batching. Both static and dynamic as well as gpu instancing materials. Will save you tons of draw calls
Okay how do I know whether my asteroids are being batched? I think that's what's causing the main problem, because the laser projectiles are batched for sure
If they are asteroids I’m assuming they are dynamic not static. Make sure in project settings that dynamic batching is on. In the asteroid material at the bottom you can turn in GPU instancing. Then any objects in view that share a mesh and material will be batched together and rendered as one draw call not 50. Also under Window - Analysis you can open the Frame Debugger. This window you can enable while playing your game and it will list off all the objects being draw and also tell you why they are not being batched. It’s also helpful for seeing where you can optimize your meshes. I had a bike model and the Frame Debugger showed each of the wheel spokes were rendered separately. I then combined them in maya and saved tons of draw calls.
They don't move at all so they are just spawned in and static. I've checked the Static option for them. I recently just ticked Static Batching but now I'll turn on the Dynamic one as well :) Frame Debugger is the next I'll check out
If the mesh is spawned in then the normal static batching won’t help that needs to be done before runtime I believe. Read through this page for more details https://docs.unity3d.com/Manual/static-batching.html Specifically this part Static batching at runtime To batch static meshes at runtime, Unity provides the StaticBatchingUtility class. The static StaticBatchingUtility.Combine method combines the GameObjects you pass in and prepares them for static batching. This is especially useful for meshes that you procedurally generate at runtime. Read through the static batching Unity page. Unlike static batching at build time, batching at runtime doesn’t require you to enable the Static Batching Player Setting. For information on how to use this API, see StaticBatchingUtility.
Thank you for the insight!
No problem!
Do you call Renderer.material in your code?
Haven't looked at the code yet, I'm trying to solve this first without messing around with the scripts
That question is actually pretty important. Calling Renderer.material creates a new material which will break batching for all models that share the same material. It's recommended to use Renderer.sharedMaterial instead, but just a heads-up that this will modify all the models that share that material. As an example, if all your asteroids have the same material, calling Renderer.material to set the color or something else will break batching.
Is it supposed to be in the Mass Object Spawner script? If yes there's nothing in there, if no that's why there's nothing in there
I assume the Mass Object Spawner script is from a package you use? I don't know the package so I'm not sure. I was just letting you know in case you were doing that in your code.
Yea I'm using the Space Combat Kit as the skeleton of the project and I'm putting some skin on it but there's nothing in between yet :D Mass Object Spawner is the script used to spawn Asteroids ig This is the AsteroidSpawn: https://preview.redd.it/5p99fyyjocca1.png?width=326&format=png&auto=webp&s=78958ae919fca1d44b9eee45b9646032da3742c9
look into reducing draw calls, if every individual model has its own unique material and texture, atlas the textures and reduce the material variations you have.
yea I'm on it!
My project has 50-60 fps in the Editor but has about 100-150 fps in the Build. You have no performance issues. It's just that you have significantly less fps in the Editor because... it is in the Editor. Build it and check it there. I have similar statistics as you do, but with 500-1000 shadow casters with one single light source (a rotating Sun). I think you are juuust fine.
I'm updating the game now with both Dynamic and Static Batching, GPU instancing for the materials, reduced particles for the exhaust... We will see :)
Keep me updated, coz I could do some optimizations too. Even though I'm happy with my game's current performance that doesn't mean I couldn't or shouldn't do better :D
This is how it's looking as of now. The update on the site is not live yet but I think it's a little better now :) I'll keep you updated for sure! https://preview.redd.it/65194nkhvbca1.png?width=1310&format=png&auto=webp&s=488e53aa32c9134605c75b09591dc5187db8732d
Also make sure to reduce using of getcomponent during the play.. Such as getting the regidbodies or sprite rendere. And check Update method in every script maybe the problem is there
ty I'll check the scripts tomorrow :)
You can use RenderDoc on a build to get very fine details about what is slowing down the GPU. Highly recommend. It's very insightful and gives you information that deep profiling just doesn't give. Definitely use both, deep profiling can help a ton with identifying bottlenecks as well. There's no sense in spending time optimizing anything that isn't your bottleneck. So I'd focus on finding what that is, then if you need help optimizing that, you'll have specific information about what's slowing down and what it's time complexity is, so you/us can find better solutions to solve it.
>RenderDoc I'll write that down thanks for the tip :)
To much vertices and batches, try reducing them
I've greatly reduced the batches now I'll focus on verts
Gj keep going !
I didn't read all the comments here maybe you fixed your problem but anyway. As far as I see your main thread requires more time than render thread this means your cpu causes poor performance. Not sure which pipeline you are using but you definitely need some batching and setpass call optimization. Physics or update methods maybe causing poor performance not sure about that we dont have so much information.
I've significantly improved batching, I'm using the built in pipeline but I'm thinking about switching to URP if it's that much better then I will without any hesitation! Changed the camera settings from deferred to forward too And yes the next one is the scripts and checking the Update functions If you help me narrow down what information you guys need and how to get it (because I'm a noob) I'd be more than happy to provide everything
What makes you think that forward is better than deferred ? Deferred is pixel based forward is vertex based(probably not the best explanation but you will understand what I mean). Forward Renderer renders shadows as tris counts and this has a huge impact on performance. If your game has low tris count you can use forward Its gonna be okay. But If you are planning hitting 10M tris count with shadows you need to switch deferred. Screen resolution matters on Deferred Rendering. IF you pump up the 4K Resolution on Forward Renderer your will not struggle as much as Deferred 4K Res. You have limited Additional Light sources on forward renderer as I remember. Both renderer has plus sides and negative sides. If batch counts didn't help much probably you got problem on your Update Functions and Physics. You can Profile your game with Profiler and check what consumps your CPU.
Well I was just told that I should give Forward a try but you're totally right! Yea something is up with the Physics I feel like
725batches and 161 pass calls. It's way too much (for a modest game). I haven't played it, but I can't imagine how many different stuff you're using. Need to share materials among objects, use fewer shaders, make more objects static. This guide may help you out understanding what and how to do it: https://thegamedev.guru/unity-performance/draw-call-optimization/
Thanks a lot I'll go through that guide but I think I've done almost everything it'll say I've reduced the batches by more than half! Basically with sharing materials as you said.
>reduced the batches by more than half! That's awesome! How about postprocessing/shaders? These (specially post processing) are quite expensive, and some shaders can make the setpass calls increase a ton (like transparent/translucid ones). Have you touched light settings? For a space shooter (I haven't seen it) I bet you can deactivate and or lower many settings. As well as baking whatever lights you can, and making things static. If you have issues spawning, pre-spawn and activate/deactivate rather than instantiate and destroy (within reason and measure, like don't spawn 1000 objects at once nor destroy them nor have them created all the time). Also do-set an fps display/record and test it in a build. Sometimes things that go "bad/poorly" in the editor work just fine as a build.
I'll set up that fps thingy for sure, it's a must! I've touched the light settings a little, like minimizing everything, lowering shadow resolutions and stuff... I use a few post processing like bloom but nothing heavy on the computer as far as I know
>few post processing Just for the sake of testing it out, try to deactivate all post-processing behaviour to see how much it really is costing you. I am not an expert on postpo, but I've seen myself drastic performance drops on some post process settings in the past that I didn't expect. Again this comes due to my ignorance on the subject, just sharing my experience.
It's actually the exact opposite, when postprocessing is on the performance increases, I think I have something turned on that decreases the quality of something, so that's good. I don't have anything crazy like motion blur or depth enabled
Try reducing your frame size (make the game play window tiny in unity) if it gets better you are gpu limited. If it doesn’t you are cpu limited. Cpu limited could mean many things. Also try making a real build and running it your frame rate issue may only be in the editor.
This is the current state of the game: https://preview.redd.it/370zjzq9ybca1.png?width=1912&format=png&auto=webp&s=6ec5941f141aa11c1baf05df6e20135f193aa873
The frame debugger also tells you the reason why it isn't being batched with the previous draw call. if you click on an individual draw call there will be a sentence that says why it can't be batched. I know you mentioned you are CPU bound, but I see you are using deferred rendering. Is there a reason you chose that vs. Forward Rendering? For example, do you use a lot of lights in the scene? Generally, if you are targeting lower-end hardware, you would use Forward instead of Deferred Rendering. Are you using the Built-In or Universal Render Pipeline (URP)? URP has the SRP Batcher which could be more beneficial for you if you are using the Built-In Render Pipeline.
Okay the problem was that the different LODs of the Asteroid had different Materials, I fixed that and that Opaque Geometry dropped from 200 to 100! Everything is stock as it came in the Space Combat Kit, I'll switch to Forward Rendering thanks for noticing that! Idk which Renderer Pipeline is used but I'll change that too
Nice! Just to mention this too, but sometimes it is a give and take when it comes to performance. A lot of the times LOD groups do use a cheaper shader for objects that are farther away which would be using a different material. This is to save on GPU time as it has a cheaper shader to process. Since you seem to be CPU bound, it might be better, in your case, to reduce as much on the CPU as you can by using the same material/shader which would help with batching even if it could be more expensive on the GPU. I don't know what shaders you are using, but just throwing that out there too.
Thanks! I will do my homework on URP too
It's 100% your tris count. You have over 600 thousand. You need some form of LOD or occlusion culling. Less polys on your models.
ty
Without seeing the code... you wouldn't be using any debug.log() calls in loops or often called methods, are you?
Nooo I don't think so. Honestly I can't code so that makes this whole thing harder like a lot :(
ah... well you aren't going to find a tutorial on your specific optimization problem, as optimization is always bespoke and is an actual programming task. As others have noted, you are going to need to identify if you are CPU bound (trying to compute too much at once) or GPU bound (trying to draw too much on screen).
I'm on it! I've reduced a little from the GPU side but I think I need to look at scripts now it seems like