I work for a company that does tractor simulators. These are pretty physics intensive so that already takes a lot of the processing power. For one simulator in particular we have a lot of crops that have to be rendered. These crops are in the detail layer of the terrain. Because we have such a large number of these in the scene, we are finding that our fps is dropping to around 40-50 when we are going through the middle of the fields (where we get the most crops on screen). it should be noted that we have multiple cameras because we have to render the mirrors accurately and everything. We have tried using a gpu instancer plugin to offload some of the workload, but surprisingly it actually decreased performance. We have tried several different ways of doing this and nothing has improved the performance. It's not a serious problem but it is something we would like to improve if at all possible. I'm wondering if anyone with experience in something like this has any suggestions we could look into on how we could increase our performance. Thank you.
Optimization suggestions
Are we talking full 3D models for the crops are sprites ? If so you may want to try some LOD scheme wherein only closest crops within a certain range are 3D models and outside the range they are billboards. If they crops are rendered as billboard, you can probably do some for of sorting ( if this is not being done already ) or make a more efficient billboard representation. In any case this is just shooting in the dark as without accurate profiling we'll all be guessing where the issue lies.
What is your average frame time? FPS is NOT frame time...we need clock time .
Don't know what hardware( GPU ) you are supporting, but have you run the application through a graphics profiler to see where the bottleneck is ? Vertex transform/Fill/Memory Access ? could be anything, but this has to be done up front before any accurate corrective approach can be given.
I think your first step should be to figure out whether you're currently bottlenecked by your CPU or GPU. These guys run in parallel, so your frame time is ultimately going to be limited by which of the two is taking longer. This also means that if you're bottlenecked by one of these, improving the other won't change your frame time.
CPU time is relatively easier to measure. Every OS provides some sort of high-precision timer that you can access, and hopefully your engine already has functions to access that. You can start out by just measuring the full frame time, but to get as good idea of your CPU overhead you'll want to make sure that you exclude any points where the CPU might be waiting for the GPU to catch up. On D3D9/11/OpenGL this is generally going to happen where you submit your buffer to the swap chain, unless you're doing some kind of GPU->CPU readback that causes a stall to happen elsewhere. For D3D12 or Vulkan you'll know exactly where your waits are happen since you're doing those manually using fences.
For GPU timing things are trickier, since you have to do it with GPU timing queries. Nathan Reed has an article that you can look at for some guidance.
Once you have that data, you can start to narrow things down to figure out where you should focus your efforts. If you're GPU-bound then you know to try things like simplifying your shaders, reducing your polycounts, or reducing your rendering resolution. If you're CPU-bound then you know you need to try things like reducing your draw calls, mapping/updating fewer buffers, or improving your multicore utilization. You can also add more detailed timings to your engine to further narrow things down, and/or use dedicated CPU/GPU profiling tools to gather more information.
