More rendering info
Blitz3D Forums/Blitz3D Programming/More rendering info
| ||
| This is getting interesting. If you render things in multiple passes, it is crucial that you keep the fewest number of top-level entities possible. Each time you render, Blitz goes through and performs DX transformation operations until a hidden entity in the hierarchy is found. If you have just a few top-level entities, you can hide them and cruise through with no problem. If all your entities are top-level, you will have severe additive slowdown with each rendering pass. Merging all meshes into one is faster than even instanced meshes. However, the fastest of all methods if to divide your map up into a grid of about 16 meshes, and merge meshes according to their position in this grid. You can also do a render box test to check visibility of each if these portal zones. When doing box tests, it is important to keep the rules from the prior paragraph in mind, since this can involve up to 16 extra renders. You can use the visibility info to cull offscreen or out-of-range terrain pieces and static meshes.  |
| ||
| I've been thinking about some ideas with mutipass rendering as well. One thing I'd like to do is break up my renders into close, medium, and far renders and copy these renders to textures. Then check for camera movement, if it moved then render the scene normal. If the camera has not moved then check each of my render layers for movement. If nothing has moved then of course you can just render a sprite attached with the textures (which don't change until somethings been updated) on it like another buffer. The cool thing is that you could then just render each range only if something in that range has moved. This way much of the time you'd only be rendering short distances etc or a sprite... Well maybe. It's just an idea I had. |
| ||
| I think you should assume the camera will move every frame. Otherwise, you will just get jerky movement when camera moves, with smooth movement when it stops. Polygon count for staticmeshes doesn't really matter. You could do low-poly LOD versions, but in the shot above, it takes less than 1 msec to render a forest. Then I add 20 bots in, at 600 polys each, and my framerate drops to 18. I've got to find a way to render actors more efficiently. |
| ||
| Have you tried converting your actors to MD2 format so they do not have any bones in them? |
| ||
| For extreme speed you could sample all your animation cycles to independent (static) meshes and parent them all to a pivot which hides / shows the current frame. Pretty expensive on vertex memory with 250 keyframes of a 500 vert model taking I would guess something like 4 megabytes per model but would be very fast if you are prepared to drop tweening. Also, the idea of timing rendering is possibly not as simplistic as you assume. Unless you are locking the back buffer in some way before sampling the time, the time after a call to RenderWorld is meaningless in relation to how far the GPU is along it's buffered draw list. |
| ||
| skidracer, wouldn't that kill the surface count? |
| ||
| I would imagine a LoadKeyFramedMesh system would have a comparable rendering speed to that you get if you load your models with LoadMesh instead of LoadAnimMesh. Surface count is up to the artist. MD2 is more versatile and I would assume as fast as you can get for runtime vertex manipulation in Blitz3D especially the normal calculations. A utility that created normal mapped skins for MD2 models would be kindof cool. |
| ||
| Skidracer, that's probably the most efficient method. It's funny how the tools have all these high-level concepts like bones and staticmeshes, but in the end, you collapse them into simple vertex arrays. Here are two possible methods I am considering: Bones Using a custom animation system that is only updated before the scene is rendered, I animate the skeletons. Each vertex in the mesh has to be transformed from bone space to world space and updated. Advantages: -Dynamic -Easy to add hit boxes Disadvantages: -Potentially thousands of TFormPoint() operations per frame -Animation hierarchy overhead Vertex animation Like Skidracer said, pre-compile a set of frames. Interpolation between two points ((Ax#+Bx#)/2.0) would be much faster than a transformation operation. Interpolation could be disabled fo faraway entities. Advantages -Fast Disadvantages -Hard to use with dynamic animations, like ragdoll physics or combination animations -Lots of memory usage |
| ||
| If you want vertex animation interpolation you are talking medium speed (medium bus usage) but very low memory usage be it MD2 or your own routines. Static Mesh Animation - large video memory usage - no interpolation - no agp bus usage (high speed) |
| ||
| Would you care to comment on how serious sam manages 100 deforming meshes rushing at you at once with seriously high framerates? They obviously solved the surface issue. But in terms of bones, I believe they use bone lod as well. Small bones are lodded out with the triangles. Very efficient stuff... |
| ||
| They probably perform one bone update for the animation and apply it to all enemies that are running, etc. My guess is all the "running" enemies are playing on the same frame, etc. |
   |