Jump to content
  • entries
    941
  • comments
    5,894
  • views
    867,913

Common Bottlenecks


Josh

11,442 views

 Share

blog-0485802001484282644.jpg

Leadwerks 4.3 brings a big performance boost to your games. In this blog I am going to talk about some of the common problems you can eliminate to make your games run faster.

When slow performance is encountered, it is typically one really bad mistake that is slowing everything down. Here's a few common bottlenecks for performance you can create in your games, how to identify them, and how to fix them.

Shadow Updates

Shadow rendering is cheaper than regular renders because no textures have to be used, but extra rendering passes to update shadows can add up.

How to identify: The game stats will display the number of shadows updated. If this is more than a few, you might have a problem. Remember that point lights require six extra passes, and directional lights three, but both only count as one shadow. You also want your rendered shadow polys to be as low as possible.

How to fix: Figure out what objects are triggering the redraw and whether it is necessary. Non-moving high-polygon models should use the static shadow mode so they don't have to be redrawn during a render. In version 4.3, low and medium light quality settings will also stagger shadow updates so that fewer are rendered each frame. (This can also make it harder to detect a problem, so maybe test on high quality settings when you are examining this.)

GPU Pixel Pipeline

The GPU has a limited number of stream processors it can split up the task of rendering an image with. When you overload the GPU pixel pipeline it slows down your program.

How to identify: If you have a much higher framerate at a lower screen resolution, this is probably the cause.

How to fix: Lower light quality settings, remove post-processing effects, or run at a lower screen resolution.

GPU Vertex Pipeline

This is pretty rare because the number of vertices the GPU has to process are tiny compared to the number of pixels, but it is possible.

How to identify: Slow speed regardless of screen resolution, slow even when rendering the scene with no gameplay, extremely high-polygon counts in the game stats (like 2,000,000+). There are some applications where extremely high polygon counts are acceptable, but unless you are specifically making such an application and are aware of this, it probably means you should use models designed for real-time games.

How to fix: Use lower-resolution models or lighten up on the vegetation.

Too Many Objects

The renderer itself has a cost of computation on the CPU. The more separate objects there are, the more the CPU has to work to determine what objects are visible. On the other hand, discarding large numbers of objects can give a big speed boost, so it's always a balance.

How to identify: The render time shown in your game stats will be more than a few milliseconds, and the number of batches, displayed in the game stats, will be very high. It's all relative but if you have a simple scene and 500 batches are being drawn, there is probably a problem. Large spread out maps with dense distribution of objects can often have this problem. This will happen on all machines, regardless of how good the GPU is. The most complex maps I've ever made had about 700 batches rendered. There is no need to go above that no matter how big the map is, because objects in the distance will be culled. The vegetation system does not cost much on a per object basis, so it is an extremely efficient way to lay down a lot of dense objects.

How to fix: Use the model editor Collapse feature to collapse models into a single object and resave them. Also set the view range of smaller objects to a closer distance so there are fewer of them visible in the distance.

Slow Collision

If your game slows down when you get close to an object, you might have a high-poly collision mesh.

How to identify: The physics update time in the game stats will be more than a few milliseconds. Enable "View Physics" in the editor and check to make sure all physics shapes are low-poly.

How to fix: Use the model editor to generate a low-poly physics shape with the best available option.

Code Errors

Is your game constantly reloading files from the hard drive? Are you performing lots of pick operations each frame? Did you create a runaway loop of new objects to process?

How to identify: Comment out sections of your code and test the framerate.

How to fix: Figure out the main section that is causing the slowdown, then keep commenting out smaller and smaller parts until you narrow down the problem. Post on the forum if you don't know why something is causing a performance drop.

  • Sad 1
  • Upvote 17
 Share

66 Comments


Recommended Comments



On ‎7‎/‎3‎/‎2017 at 11:55 AM, Newton Dynamics said:

Hi,

 I found this thread in Google and I read it. I have a few questions.

1-was the performance problem ever solved?

2-if it was not I believe I do have an idea why is slow when you have 25 player try to get to a single location. 

This is a common problem in AI is many many game, that I have solved over and over over the years.  for the record if the player controller are single bodies, as I believe the are there is no way that 25 objects will cause such slow down in the physics system, 25 bodies should be running at over 500 fps, even 250  players should be running ate over 500 fps.

if this is the case I would like to know an see why is happening.

My guess this is related to the  the logic that try to resolve the order in which each player try to move toward the goal. basically the crowd control solver. 

I can provide some hints as to how to solve in a elegant way is linear time, if you have no solve yet. 

We're using a custom character controller that behaves exactly the way I want.  This was the advice given to me by the guys at Frictional Games and it worked well.  I am interested in building a more advanced controller into Newton with you, but there are other things to be done first.

I think it was pretty well established here that the number of bones was the limiting step, which makes sense to me.

Link to comment

 

I am here because of bottlenecks in my project.  I'm not very optimistic, but in my case I only have one character running on a vast map and I have a deterioration of fps at 30. 

In the tests I do I have this.



image.thumb.png.ec4f92b05ecb85fe1512b8efeac9d5f5.png

 

 

Link to comment

 This is the same scene, only I have removed the character collider from all these elements and the performance goes up a bit more.

image.thumb.png.bd647165dd49d67c91b42265588dc0ad.png

Link to comment

In this case my approach could be the following, The enemy character controller should be activated exclusively when in a range very close to the player.  In my case I have removed two rows of meshes one on each side of the scene. And only the closest ones have the character controller activated.

image.thumb.png.bad17fbf256eb312c6fcd1ec76019018.png

 

image.png.2a8ce6d9c4b533a7f7594ca6f47c7f94.png

 

This is bringing me to a point of restarting my project based on these aspects of checking performance.  And trying to have the best approach so that it doesn't hurt me in terms of FPS.

Link to comment

I noticed your performance was quite slow in your demo, but I'm sure it can be improved.

I would look at post-processing effects, and check to see how much the minimap is slowing your framerate down.

Also, how many particles is that smoke emitter using?

Link to comment

Eventually something points to the particle system, I've turned up the particle max and I get this.  The weird thing about it is that the emitter hasn't started, and apparently they are taking up system resources and lowering performance.  I use an average of 1000 particles in the storm emitter. 

image.thumb.png.6b1d7890364ac98d481c45b9e02e2ad9.png

Link to comment

 

There are many factors that influence the drop in performance.  The first one identified is the particle system, in the game I use about 1,000 particles that the emitter activates under certain circumstances, but apparently even if the emitter does not start, those particles affect the performance, just by putting 1000 particles in the emitter without it starting. 

In this image the emitter is at 250 particles, and I have removed the rocks.  

Translated with www.DeepL.com/Translator (free version)



image.thumb.png.7b01abf2295d8454efc2bb631d08cf0e.png

Link to comment

sdf At this point I am going to restart the project, I think it is the best thing to do and gradually check the performance. I note that I am with the effects of shadow and terrain defects in Leadwers and I have the concern that if I do this in C++ is much more stable, is it possible?

image.thumb.png.e63c4aceebc66e0b62a9d238ad51c4b7.png

 

CPU : I7 2600
Ram : 24 Gigas.
GPU : GTX 1050 2 Gigas.
 

Link to comment
21 hours ago, Yue said:

 This is the same scene, only I have removed the character collider from all these elements and the performance goes up a bit more.

image.thumb.png.bd647165dd49d67c91b42265588dc0ad.png

If character controller boosted your FPS 2 times, then you probably have a CPU, not GPU bottleneck. Check your task manager.

Also, GTX 1050 is weak, but it is the second most popular GPU on Steam, so you should definitely optimize for it.

Link to comment

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...