How to keep acceptable performance without LOD?
BlitzMax Forums/MiniB3D Module/How to keep acceptable performance without LOD?
| ||
| Hi all, It is said that LOD is not implemented in minib3d. 1. How could we keep acceptable performance, when the no. of animated characters is large(say 50) and quality of 3d models is necessary ? 2. Are there any way to use LOD in minib3d? Thanks in advance |
| ||
| You can do LOD manually by swapping models depending on distance from the camera, but there's no automatic LOD where you simply tell the engine "these are the various levels of detail, now GO!" |
| ||
| There's no LOD, but theres HideEntity and ShowEntity, just like in Blitz3D - so, just get the distance from the model to the player, and if it isn't close enough (on the same area, same sector, or whatever) just hide it. And of course, LOD is pretty easy to implement, take a look at the code archives: there's a LOD example there on Blitz3D that should be fairly easy to port to miniB3D. |
| ||
| Taking from some Blitz3D Tips thread in the Blitz3D Tutorials section, it appears that even hidden meshes still have a small impact on the CPU, because of the vertex manipulation involved with animations. So it's alleged that you should free whatever mesh you would be hiding, and whenever you need it back, you copy it from a hidden, master one. Originally posted by Matty: Use a pivot for each 3d character model with a collision type as appropriate (ellipsoid to polygon). If a 3d animated entity has been 'not seen' for more than a few seconds then rather than hide it (which blitz3d does automatically when not in camera view), free it (ie freeentity) but keep the pivot. Then when the entity comes into view again copyentity the character model from a 'master' mesh that is simply used as a reference to copy entities from. I have found that while Blitz3D culls entities not in view they still have a decent performance hit on older PCs even when hidden, particularly if animated and so it is better to just remove the entity entirely and keep a pivot behind to 'act' while the entity is not in view. I haven't tested this, though. You'd need to know the cost of copying the meshes from the 'master' ones in real-time, to see if it's worth the implementation. |
| ||
| I would think that means simply stop the animation when hiding the model. |
| ||
| I don't know much about animated meshes so bear that in mind with my post. Hiding an entity is better than just putting it off screen. The render loop checks if something is hidden, or alpha = 0, then it checks the frustrum. So you can save the frustrum check if you hide it. If you don't stop the animation it should still animate weather hidden or off screen, so jhocking should be spot on with that, as updating the animation will take time. the post you reference by matty effectively stops the animation by deleting the mesh, however this is going to have overhead to delete, cleanup the memory, and then copy and re-allocate the memory (allbeit quite small) every time you go through the process. However since the entity is being removed entirely it doesn't have an entry in the render list to check at all, thus saving an infinitely tiny amount of time... If you have the time to do the coding one possibly overly sophisticated method would be to use a bunch of methods. I would set up an object to control each one of your animated meshes and their LOD. copy the appropriate mesh (high/low/whatever) for it's current distance. if it goes off screen hide and stop it. if it gets too far or too close then copy the new mesh and hide/stop the old one. if a mesh is hidden for a certain amount of time you could consider freeing it. That's probably overkill though, you likely have the memory to handle pre-copying all the levels and then just hide/stop everything you're not using, and start/show as needed to switch LoD. All depends on how often you think you'll be switching lod, how many levels you'll have, and most importantly how many characters you need to do this on... and also how many do you expect to have on screen at one time... basically how much time can you afford for management (both processor and programming) vs. is it just better to let the system handle more of the work on it's own. Just some thoughts, hope they help, gluck! |
| ||
| Hmm, about the stopping of animation, I just thought of something. Say if the character is throwing a punch and then gets off-screen. His animation would be stopped. Now let's say he stays outside the view for an entire minute - whenever he gets back, he'll quickly finish that animation which he should have finished while outside the screen (since we stopped it when he got away). With that in mind, I think we should always keep manually counting the frames (just a matter of counting an integer or float, if you will), and then use the SetAnimTime only when that mesh is inside the view frustrum. Problem is, you are actually going to have to rewrite a bit of the animation interface, since you'd need to check whether the frames have reached the end, if it's a ping-pong mode, etc (so your counter acts accordingly). It's not that difficult, at least. That way, characters can finish animations off-screen while sucking the least performance possible. |
   |