Development Blog

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.

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

Ah ok that makes sense then.

 

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.

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.

 

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.

 

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.

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

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.

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.

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?

Its the same default monsterai script. I didnt change anything.

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.

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.

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.

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.

For what it's worth, the default Biped in 3DS Max has 82 bones (with 5 fingers and 3 finger links).

 

Maybe. It's been a few years since I first learned it from videos like these:

But I'm curious what makes you say that.

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.

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.

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)

'

' ' ' ' '

' ' '

' ' '

' ' '

' '

' ' ' '

What about using the caulk material? I never heard it get talked about but I thought it was a pretty good optimization.

what does the caulk material do?

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

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.

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.