Tips for rendering large number of actors?
Blitz3D Forums/Blitz3D Programming/Tips for rendering large number of actors?
| ||
| Does anyone here have experience rendering large numbers (30+) of boned, animated actors? There are a number of factors I can think of that might be possible to optimize. First, updating animations with UpdateWorld() is a bad idea, because you only need to do it before a render. I go from 60 to 30 fps just by animating 20 soldiers and not even rendering them. Second, since I have no idea how bones actually work internally, I think it's best to use your own bones, updated right before the RenderWorld(). Finally, you can gain some speed by rendering each actor in a separate pass. My guess is this bypasses an expensive z-ordering routine. |
| ||
| TFormpoint is too slow for this. 30000 calls per render just doesn't work, and that is probably the approximate amount you would need for 32 players at different LOD levels. Is Blitz's internal bone routine any faster than this? |
| ||
| So, rendering say 20 actors all together, is actually slower than say 20 passes? That's quite interesting... :o) |
| ||
| does using hideentity offscreen speed things up? the additional call to hideentity might make blitz skip processing bones. |
| ||
| "First, updating animations with UpdateWorld() is a bad idea, because you only need to do it before a render." Yes it is an awful idea to use updateworld for updating models so they will properly detect polygon collisions and mesh intersections. Because updateworld was clearly intended to only be run every time renderworld is called. That is why they are the same command. Oops, wait, they're not! You can call updateworld as many or as few times as you want before a renderworld. You just can't seperate the bone updates from the rest of the physics, because they're rather important in detecting collisions. If you don't want a solider to be animated and take part in collisions, then he is most likely off the screen and far from the camera, where you should manually cull him with hideentity, which will avoid the update during updateworld. |
| ||
| Didn't I just say that? |
| ||
| lol I'm beginning to be glad i'm not into FPS stuff... :) Blitz has its own internal engine for it all and writing/using your own stuff must be slow. Its just something that makes sence kinda, so maybe such FPS games are best made in VC++ itself. I made basic stuff with bones so far, just to test it, and I'd use the internal stuff. And I'm not sure i get this right, but maybe if you used preanimated meshes (where suitable) instead of bones to animate them, you wouldnt need soo much processing during the game. You could also use a trick and mix both perhaps? :) |
| ||
| " Didn't I just say that? " Clearly not, because I used seven sentances and you only used two; and without any capitalization I might add! |
| ||
| Ladies, please... |
| ||
| Yes, hideentity prevents the animations to be updated. But you should test if the animationTime is frozen or reset trough the hidden state. |
| ||
| I don't do a whole lot of mesh intersections tests during a game loop. I do 0. I was just wondering if anyone who was not talking out of their ass had experience with this kind of thing, and new what the real issues were. Yes, rendering 20 meshes in separate passes is slightly faster than rendering 20 meshes in one pass, presumably because they aren't z-ordered. (This only causes a problem with alpha surfaces, so I render all transparent objects in one final pass.) |
| ||
| Yeah, Blitz doesn't seem capable of producing more than 25 - 30 animated characters at once. My advice would be o use one entity and then for others off in the distance make a render of it's animation or make a render of all the ones in the same animation pose and make sprites if they are far away. You also might just want to use LOD so you're only transforming a few verts. As it stands now though you can't have many animated meshes especially using the Animate command. I think I found a big speed burst by manually updating the animation too. |
| ||
| I just used 200 Psionic ants and when they were all in view animating, I was getting 18 fps. When I closed in to view one ant animating at the end of the formation, I got 47 fps. Both times I had a particule emitter running, a "rogue" ant chasing me around the plane,and a 800 unit sky sphere rotating. I would say the key is if the entity's are in view. |
| ||
In my case, it is the render updates that kill speed. I get 20-30 FPS with 30 soldiers with bones on and animation disabled, but enabling animation kills the framerate: It looks like I can get the animation speed within an acceptable range. But if we can render 30 soldiers with an expensive routine, why not use vertex interpolation and double the number of soldiers we can use? After a few more test, the slowest step actually seems to be changing the vertex coords command. This takes more power than the TForm calculations. |
| ||
| This is the best I can do. 30 actors at 30 FPS. These are only 666 polygons each, or else I would think it acceptable. As you can see, the models are rendered in 5 msecs, but it takes 10 msecs to update them all. I still don't know if Blitz bones are inheritly any faster than Tforming and updating vertex coords. Can someone official comment on this?  |
| ||
| I tried Psionic's dwarf model, and was render 150,000 animated poys at 40 fps. I am going to look into the skeleton hierarchy and see why mine are so slow. |
| ||
| These are only 666 polygons each There is your problem... |
| ||
| ...anyone else notice the 666?! |
| ||
| Well, i can get away with adjusting around 2000 odd particles in a single surface system. Each particle has 4 vertices and there constantly being changed, so you might be faster just doing that. |
| ||
| Good for you. I am dealing with like 20,000 vertices, plus normals. It looks like bones actually use DX skin meshes, so it is inheritly faster to use a boned b3d than to update them yourself. My guess is they really do only get updated before the render. In my case, the excess entities in the skeletal hierarchy seem to be dragging down animation speed and rendering. I have about 3 times as many joints as I actually need. I am going to eliminate all hierarchy redundancies and see what happens. |
| ||
| I have about 3 times as many joints as I actually need. Weeeell... :) Bones are fast (DX ones at least, rendered with good HW), but we still try to keep the bone count to absolute minimum at work because they can be costly fast if you have too many bones - and this gets multiplied with the amount of characters on screen simultaneously. Reducing 5 bones from a rig is 100 bones less if you have 20 characters on screen. |
| ||
| Good for you. Yes, it is. |
| ||
| Which then begs the question, would single-surface particle systems run faster with a boned mesh? I know my particles start taking a hit once I get about 6000 updating. |
| ||
It was the skeleton redundancies that were slowing it down. Look: I also gain about 8 fps by eliminating the hand bones, even though no verts are attached to them. You should use a low-res skeleton as well as mesh, for distant objects! Fortunately, I can eliminate bones, even spine segments, and use the same animations. Your distant skeletons can consist of just a few bones, while your immediate skeletons have separate hand, feet, and full spine bones. |
   |