Some performance questions...
Blitz3D Forums/Blitz3D Programming/Some performance questions...
| ||
| Ok, I'm moving into actual construction phase on my game, and I need some tips on certain performance issues... Currently I use sphere to polygon collision 'hulls' that are parented to the bones of characters. This gives them virtually polygon accurate collision detection, as well as easy location specific damage, but I'm worried about it's impact on performance. After trying multiple single surface particle systems, and deciding they are all over-complicated and that none of them gave reasonable performance in my engine, I switched to using limited single animated sprites, much like the original Unreal did for most of their effects. The results are currently satisfactory, and seem to be much more effective without causing an overload of surfaces. Anyway, once I get everything in game, a few problems become apparent. First, more than two characters, with very little AI, set up to continue shooting in a direction (for testing purposes), will rapidly cause a massive framerate drop. There are no memory leaks, and generally less than 50 particle effects on screen at once (each one being a simple animated sprite), even with massive amounts of gunfire going on. So, my main concern is that the collision hulls are at least mostly responsible. Would this be likely to create such a slowdown, and would using reduced quality hulls improve performance? |
| ||
| would you be cheacking 50 things againt 49 things, or 49 things againt 1. ie) are you looking to see if the bullets hit each other? |
| ||
| Um, not quite sure I get your meaning. I don't have projectile-projectile collision, just projectile to collision hull and map. At least not for most projectiles (will have it for rockets, but they aren't in yet). The actual collision checking is done by the projectiles themselves each frame, if they register a collision it checks to see what kind of entity it collided with, and then executes appropriate code based on that. The collision hulls of characters are treated just like any other sphere-to-polygon collision surface, except they are parented to the bones of the model they belong too. I seem to get a lot more slowdown when characters are animating, which leads me to believe this may be the main source of my problems. Could it be possible that moving the collision hulls each frame could cause the slowdown? |
| ||
| Orc I dont really use B3D, I only asked because from your first post I thought that you just had two AI fireing guns, and that you thought that it was the projectile colition that was slowing it down. And I was just checking that you were not checking to see if the (First say), bullet had hit another (The second) bullet. As you say this is not so, then I dont know. |
| ||
| When you say 'There are no memory leaks', what do you mean? How are you sure it's your collisions? Have you disabled collisions (just kill off the sprite after it hits a certain distance, or even time active) and proved that the collisions are the slow down? Just a few ideas. |
| ||
| Hmmm, well, let me see. I tried it with and without collision enabled (with character collision hulls) and regardless, it seems that when I have more than one character in view, I always get slowdown. Generally up to half the framerate dies (30 FPS). However, it goes back up when not viewing the characters. By no memory leaks, I mean video memory usage stays at 16 megs. Nothing is dragging the system down in that area. |
| ||
| Ok, it just got more unusual. I tested it with them idle, rather than shooting, and they don't cause slowdown. However, when I start shooting (while looking at them) it slows down to half the proper framerate. Note that for this test collision was OFF. When not looking at them, I can shoot all I want with no frame hit. |
| ||
| My new guess ;) is that is a particles thing. |
| ||
| By no memory leaks, I mean video memory usage stays at 16 megs. Nothing is dragging the system down in that area. K, with a memory leak, in your code that is, usually it's you creating and object, and not properly destroying it. For example, if you create a mesh, create a surface, then create a few particles on that surface. When the particles are destroyed (your done with them), are you just freeing the type instance, or are you freeing the surface of those newly created verticies and triangles.. That would be a good example of a memory leak most encounter. Another is creating a type that has types nested inside them. Some people will delete the type instance but not free up the nested types, thus creating a memory leak there. I merely asked for curiousity on what you defined a memory leak as :-) I tested it with them idle, rather than shooting, and they don't cause slowdown. However, when I start shooting (while looking at them) it slows down to half the proper framerate. Note that for this test collision was OFF. k, put a counter on there to show how many of your particles are active when the frame rate drops (each time a particle is made, add one to the counter, each time one is destroyed, minus one, and display that count on the screen). Also, how big is the texture your using for the particles? Is it alphaed or masked? Most people use specialized sprite systems (particle) because blitz sprites are very slow to use. This might be half your issue, using the blitz sprite system. |
| ||
| Ok, first I'm very careful about deleting types, so that's not a problem. There are however some issues going on here that are beyond my control to predict... First off, I tested it and can have about 50 particles on screen without a slowdown. However, if I add a character to the scene (standing with a simple idle animation, not shooting or anything) and look at it, the framerate halves. If I'm not shooting, I can look at him just fine, but if I add a couple more characters, and they are all animating, the performance starts to degrade. |
| ||
| Ok, I think I figured it out. I loaded 10 copies of my player mesh as normal non animated meshes and they don't cause a hit at all. I then loaded them as AnimMeshes and didn't even bother to animate them...30 FPS hit. So, here's the raw facts: 2 characters on screen, with short idle animation: No hit. 2 characters on screen firing weapons: About 20 FPS hit. 4+ characters on screen, with short idle animation: About 30 FPS hit. 4 characters on screen, with short idle animation, and me shooting my weapon: 30+ FPS hit. Just for the record, the player models are 1500 polies and have 23 bones. Anyone got any suggestions? I'd like to be able to have up to 10 characters on screen at a time. Currently this does not look good. |
| ||
| hmmm, are you loading all the characters as seperate commands? Or just loading one and copying it? As for the poly count, having 10 1500 poly characters on screen x10 is about 15,000 polys, each animating! 23 bones, is 2,300 bones. 15,000 polys is 45,000 verticies.... Perhaps you should rethink your characters there :-( Yeah, there are engines out there where 1,500 a character is a good number, but thats not engines that use the same animation technique that blitz uses. Unfortunatly you need some fast access to the vertex pipeline to update 45k verticies a scan. some suggestions: 1. Switch to segmented models and parenting with rotating parents for animation. 2. Split up the single mesh up into different sections like the Quake engines do. IE having a lower torso, upper torso, right arm, left arm, head and neck. Just parent them in game, and down the over all poly count to around 1000. Just some thoughts to give you a bit of a boost in performance! |
| ||
| Skeletal animation in Blitz3d is quite slow given that its DirectX7 based.Vertex positions are calcualted by the CPU not the GPU as in later versions of DirectX. You can increase performance greatly by reducing the number of bones in each model. Simplify your skeletons and you'll see a big difference in performance. 23 bones is quite high if you plan on 10 characters on screen at once. |
| ||
| (for the record, I preload everything and copy as needed) Well, at least I see what the problem is now. I thought 1500 was a very low polycount, but I guess my artist took too much liberty with the bone use. I guess I'll have to talk to him about rerigging things a bit...and perhaps splitting the models into two halves would be a good idea. Would simplify some of the animation issues, at least. Thanks for the info guys, even if it is disheartening... |
| ||
| yeah, sorry to have to give you bad news :-( Personally, I wish Bone and vertex calculations were done GPU side as well! 1500 a model isnt much these days, but its beyond blitz for efficiency |
| ||
| My artist said he can split the model up into three parts (like in Q3), which will be helpful in other ways as well (specificly: animation and skinning). Ok, for a 2100 poly model, how many bones do you think I could get away with to have up to 5 characters in view at a time? I'd like more, but since this CPU bone issue came up I think I'll settle with the old "less is more" concept. |
| ||
| Like I said above, down the poly count to 800-1000 polys a model (over all). around 20 bones isn't bad (keep it as minimal as possible). Menaing dont have a bone for each finger, each toe. Dont have 15 vertebrae bones :-) keep it reasonable and efficient. The more bones, the more recursive itterations that have to be done to modify something in blitz's under belly. Figure 1,000 polys x 5 models, thats 5,000 polys being updated each scan, which isn't bad. Much better than 15,000 polys :-) So 5,000 polys is about 15,000 verticies (yeah, I know its going to be less, speaking in worse case here) updated in animation routines every scan. That's actually a good round number, 1k polys x 5 characters.. Or you could go with 700 polys x 10 models and get about the same. |
| ||
| ok, well we're going to try sticking with 1k characters...so my artist will have to redo our current model. I'm glad we found this out before he finished rigging the new one... |
| ||
| One more thing, my FPS arms (we share the same mesh with all weapons, just have different sets of animations) are 1490 triangles, and have 34 bones. However, there is only one set of them ever used (since it's first person, obviously), so am I likely to have a problem with this, even after downsizing the characters to 1k each? |
| ||
| I wouldnt think that would impact performance too badly as it's only one instance of that type of animation grunt work. |
| ||
| Cool...by the way, weapon usually have some bones as well, but little or no animation (moving slide on the pistol, moving the magazine during reloading, stuff like that). They are fairly high polycount, but since they aren't actually being animated by most of their bones (two at most, with two more being used just for location info), can I assume they won't be a problem? This of course only applies to first person weapons, third person ones are very low poly. |
| ||
| lol, my suggestion would be to give it all a trial run together (create up a quick rought draft of each model you plant to have displayed). For example: I (you) plan on having 5 characters, each of 1000 polys, with 20 bones. I also plan on having one 1500 poly model with 30 bones for arms. Lastly I want a 500 poly model with 10 bones for a weapon. Model some very basic drafts to fit each category (1 character, 1 set of arms, 1 weapon), and give it a test run all together! See how the frames act, if you get a huge performance hit, take out elements. When you find a slowdown on a certain element, come up with a cheaper solution. We can speculate how things will react all day my friend, but we never really know for sure until we test out the theory. Think of FPS engines in Blitz3d being similar to HL1 (specs). And model your engine and art needs around that :-) |
| ||
| Just seeing if anyone had an idea how it would impact performance...I can't actually model at all so I'm letting my artist handle all that, but yeah, I think we'll just run a stress test once the basic content is finished, and see how it all works out. However, there are two little things I would like to find out. First, someone said blitz sprites are very slow. Would it be faster, however, to use them, or to simply use a handmade quad and manually make it face the camera each frame? Second, using my collision hull system, is all the sphere to polygon checking going to be really rough on the system? |
| ||
| 1st: Yes, sprites are really slow, there are better solutions such as single sufrace sprites (handmade). Once you get 75 or more sprites (alphaed) on screen, you might see a performance drop. Even when a sprite is out of view, it still needs to face the camera before it can be determined if it is out of view, which is calculations made on it. 2nd: Well, that depends how you are checking. I assume you assign the world as one type, the player as anotther type, and the projectile as a 3rd type. Do collision checks with projectile and world, and with projectile and player. If one is made, you find which player or world and do the necessary updates to said player or world? Sound about right? If so, that all depends on the poly count I guess, as collisions of sphere vs poly are of that nature. Usually you can get away with a good amount of polys in the collision checks and be ok. |
| ||
| Ok, cool, sounds good. I was hoping I wouldn't have a problem with my collision hulls, since they give very accurate hit detection... As for sprites, I've tried single surface systems and they always seem really slow when I try to use them, not to mention very over-complicated. So really, my question is would blitz sprites be faster or just quads with manual rotation? |
| ||
| @Orc, Sorry to joinin after being no help ;) But 34 Bones on two arms, implies to me that you have 3 Bones per finger. Now I cannot remember a situation in a FPS whereby I could actualy see the last bone of each finger actualy bending, (Ie the bit with the nail). That bone is always hidden by the weapon or the rest of the hand If you think the number of bones is too high in the game, I think you could loose 8 bones right there. (Im accepting That I have seen a thumb bend) |
| ||
| Yeah, I was worried about that. If we have trouble, I'll ask my artist about ways we can reduce the bone count. |
   |