My game is mostly consisting of cubes. I already simplified the cubes to only have 2 faces on all sides. I do not have real time reflections, as well as using Forward+ rendering. All of my lighting on my optimization view shows dark blue. I decreased the resolution of the textures in my game. My shader complexity is all green. I am not using Nanite. I am using Lumen, however I do need it because I have realtime shadows for the player and physics objects. Despite all of these optimizations, my game is still taking up an average of 90% of people’s GPU. What am I doing wrong and how can I fix this?
Hi - if your cubes are actors - they’ll each have their own set of draw calls - one per material.
Best thing you can do is convert them to ISMs so they’re all drawn in 1 set of drawcalls.
Another thing is your shadow rendering - are you using VSMs? If so, make sure “Hardware Shadows” is ticked in your project settings - and set the RayTracing option in the Directional light to “Disabled” - that speeds up shadow rendering by a large amount.
This is the shadow settings I have for my game.
In terms of the cubes, they are actors. I have them set up that way for a level editor I have made for the game. Example of what I am talking about.
It looks like you don’t have Hardware Raytracing enabled - with Lumen, that will provide you with a big speed up.
Regarding your actors, you could use an “Auto-Instancing” plugin to convert them to ISMs - I have a tool on the marketplace (rdInst) that does it at runtime, or there’s MeshPack (on Fab also) that does it at packaging time.
I will look into those. How so I enable Hardware Raytrace? It is greyed out for me.
You may need to tick “Support Hardware Raytracing” as well - if you don’t have a compatible card both will be ghosted though.
I activated those as well as taking a look at the other settings and trying different things out to decrease the GPU usage.
So after enabling those settings, using forward reflections instead of Lumen Reflections, disabling virtual textures, using surface cache ray lighting, disabling Nanite, enabling forward shading, and using CPU for computing morph targets, the GPU usage has dropped by 50%. I would love it if I can lower it even more though. I know someone is gonna complain about my game taking 50% of their GPU lol.
I’d move the morphs back to graphics unless you have a reason for it (like needing collisions).
1 Like
If you’re not using Nanite - switching over to cascaded shadows instead of VSMs could well give you another speedup
Would you explain this to me in more detail?
I might be looking at the wrong spot, but it is greyed out for me.
I see it mentions that it automatically uses shadow maps when forward shading is enabled.
1 Like
Gpu processes much faster than CPU, so having your morph targets run on the CPU is a major performance blockade which is not normally done unless you need it to be on the CPU for some specific reason.
One of those reason would be forcing the collision detection to work because collisions are generally calculated on the CPU.
Also, I’m not even sure the engine will allow the morph collision to return a hit while morphed even if on CPU in a “stock" engine (maybe it is something they recently finally did, but used to be you needed to re-write half the collision stuff to get it working).
Right. I’d say the next thing to look into for good optimization would be the number of draw calls then.
The game uses a lot of collision and physics. That being said, would I still not want to use the CPU?
Not unless you are specifically trying to collide meshes with active morph targets… if you have no morphs at all this doesn’t really matter I don’t think.
1 Like
Okay, I will go ahead and revert that then. Thank you for teaching me this.
1 Like
I am not sure if this is what you are talking about, but here are some screenshots of 1 level in the overdraw view.
The only reason that some sections are green is because of the glass. There are reddish spheres, but they are not even visible in-game, and only visible in the level editor. All of my levels in my game are like this as well.
It’s not so much overdraw but the number of “Draw Calls” - with non-Nanite, each Mesh is rendered as one set of drawcalls (1 per material) - that comes with the cost of setting up those drawcalls which isn’t exactly free.
With ISMs, all the Meshes of the same type are rendered as 1 set of drawcalls.
For example, if you have 10 Meshes in your level (non physics ones) that have 2 materials - as Actors, there will be 20 drawcalls - as ISMs, there will be only 2 drawcalls.
If you’re wanting to convert Meshes that have physics it’s a bit more complicated - you need to swap from the ISM to an Actor when you get close to them.
You can see the number of draw calls by using the console command “stat.unit” or “stat.unitmax”
