Jump to content
  • entries
    943
  • comments
    5,899
  • views
    922,577

Common Bottlenecks


Josh

12,953 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



You do? Why is it when I have mutilple ai go to the player they all lump up and slide all over each other? They seems more like they are all trying to move to the same spot and they are colliding with the character controller and because it round they slide off each other.

Link to comment

The default monster AI script makes the character run directly towards the player below a certain distance. That might not be the best approach.

Link to comment

 

I don't want to spend time evaluating theoretical setups because that will never end. These are both within the realm of acceptable performance. If you have a project you want me to look at, feel free to send it my way. The further you are along in the publishing process, the higher a priority I give it.

 

 

I'm really surprised with your response.

Link to comment

I'm really surprised with your response.

I can already tell you what we will find; that there is a perfectly good reason for the difference in performance between the two, perhaps the number of bones, or perhaps you used the Lua animation manager script which is slower than the new built-in PlayAnimation command, which would magnify any difference. In any case, we will find a small bit of information that is only related to this one specific case, and then we will say "Oh, so that makes sense". Having one model alone perform faster than another does not convince me that there is a problem that I should immediately focus on and stop working on other things.

  • Sad 1
Link to comment

 

I can already tell you what we will find; that there is a perfectly good reason for the difference in performance between the two, perhaps the number of bones, or perhaps you used the Lua animation manager script which is slower than the new built-in PlayAnimation command, which would magnify any difference. In any case, we will find a small bit of information that is only related to this one specific case, and then we will say "Oh, so that makes sense".

 

Or i just do what you said i should do. But in 6-8 months later when i encounter a problem, you might be on holidays or you just said that is how it is in leadwerks.

 

Link to comment

If your game is running slow I am always happy to examine your project, I've made many optimizations based on how I saw people using the engine for their games. I can either tell you what's wrong with it and how to fix it, or sometimes I discover things on my end that can be improved.

Link to comment

snippet for setting viewrange based on AABB radii

 

  --optimize scene place objects in viewrange based on their aabb radius.
for i=0,world:CountEntities()-1 do
 if world:GetEntity(i):GetClass()==Object.ModelClass then
   local aabb=world:GetEntity(i):GetAABB(Entity.GlobalAABB)
   if						 aabb and aabb.radius < .1 then world:GetEntity(i):SetViewRange(0)
 elseif   aabb and aabb.radius < 1 then world:GetEntity(i):SetViewRange(1)
 elseif   aabb and aabb.radius < 10 then world:GetEntity(i):SetViewRange(2)
 elseif   aabb and aabb.radius < 20 then world:GetEntity(i):SetViewRange(3)
 else	 world:GetEntity(i):SetViewRange(4) end
 end
end

  • Confused 1
  • Upvote 1
Link to comment

Disable the shadows on the crawler and see what the difference is when it moves. I have mentioned this year's ago. But shadows do not need updated every frame. Josh not to long ago you mentioned that physics did not need updated as much as it was because people could not notice the difference. Same as shadows. They only need to be updated 3 to 5 times per second. Not every frame.

Link to comment
Disable the shadows on the crawler and see what the difference is when it moves. I have mentioned this year's ago. But shadows do not need updated every frame. Josh not to long ago you mentioned that physics did not need updated as much as it was because people could not notice the difference. Same as shadows. They only need to be updated 3 to 5 times per second. Not every frame.

 

For the zombies, It increases the performance from 45 to 55 if I turn off the shadows. But it still odd that the crawlers even with dynamic shadows can have 30 entity chasing you and it still above 60fps while the zombies is only 45fps. Both are sharing the same script.

Link to comment

I believe the zombies have a lot more articulation than the crawler, so that sounds pretty reasonable. Not trying to be rude, but I just recently did some work on the animation system and I am pretty certain it is as fast as possible.

 

Does your Ai script use the animation manager script or the newer PlayAnimation command?

Link to comment

The zombies have 54 bones - the crawler has 24.

 

That is more than twice as many bones that have to be cycled through for the animation cycles. Not really surprising that it costs more to run than the crawler.

 

Other than the run animation where the hands/fingers change position as compared to the other animations, there really wasn't a reason to have separate bones for each finger joint. If I had the fbx version of these models, I would remove those bones to get the skeleton hierarchy down to a reasonable number if I was going to put a lot of them in a scene.

  • Upvote 2
Link to comment

The zombies have 54 bones - the crawler has 24.

 

That is more than twice as many bones that have to be cycled through for the animation cycles. Not really surprising that it costs more to run than the crawler.

 

Other than the run animation where the hands/fingers change position as compared to the other animations, there really wasn't a reason to have separate bones for each finger joint. If I had the fbx version of these models, I would remove those bones to get the skeleton hierarchy down to a reasonable number if I expect tons of them in a scene.

Yes and this is where a LOD system would work great.

Link to comment

I have talked about this idea in the past. I don't think expecting people to remodel different versions of a model would provide much utility. It should be a system built into the model editor, and you would probably save more performance with bones than with reducing polygons, although I would do both. You could disable the skeleton at the wrist and ankles at lower resolutions, and the mesh would just be weighted to the 100% to the parent bones.

 

Of course this would do nothing for performance when a lot of characters were immediately surrounding you. I don't recommend trying to make Left 4 Dead with Leadwerks, but if someone develops a commercial game that heavily uses a lot of characters onscreen at once it is something I will try my best to support.

  • Upvote 4
Link to comment

It should be a system built into the model editor, and you would probably save more performance with bones than with reducing polygons, although I would do both.

Yes, I would say the number of bones definitely has more to do with performance than the polygons - at least comparing the crawler to the zombie models. The crawler has almost twice as many polygons as the zombies.

Link to comment

Sure but it's customizable. You can add more or less bones. For example, if your character is always wearing shoes, you can turn the foot bones down to 1. You can specify the number of torso bones. Etc. That's why I said default Biped. You can optimize it a bit for game characters.

Link to comment

By the way, about "shadows". I will recommend to use Ambient Occlusion. It saves many FPS. Dying Light uses it everywhere and character ( and zombie too ) don't cast shadows in some areas at all.

Link to comment

The armature doesn't look optimized for game development use I don't think. There are bones that aren't necessary for rigging a game character - there are bones for the toes, bones for the joints, bones for the torso area and bones for the pelvis section. Those aren't really needed for game character animations but would be useful for something like 3D film animations instead.

 

If you download MakeHuman, you'll find a selection of armatures and one on the list is for game animation rigs which has far less bones than the one you've shown here.

 

Download MakeHuman here: http://www.makehuman.org/

You never need more then 22 bones/joints for your game character. Simple rule:

4 bones in each hand (3 + 1 in clavicle)

4 bones in each leg (2 + 1 in calcaneus + 1 phalanx bone)

6 bones for spine (5 + 1 in cervical curve)

'

' ' ' ' '

' ' '

' ' '

' ' '

' '

' ' ' '

Link to comment

what does the caulk material do?

It removes faces but in reality it will probably make zero difference in most maps.

Link to comment

I only use it because I'm used to applying nodraw in Source which was also something you didn't need to do since 2006 or so.

Link to comment

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. 

  • Confused 1
  • Upvote 1
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...