LOD Calculations?
Blitz3D Forums/Blitz3D Beginners Area/LOD Calculations?
| ||
| Maybe calculations is the wrong word, but: I know the basics of how LOD works, the further a mesh is away from view, the less polygonal detail it should have. But how do you do this is blitz? Use an EntityDistance() check for the object to the camera entity and change the mesh based on that? But I wouldn't want to do that for every entity right, just the ones that are within the cameras view. So I'd loop through all the entities to check if they are EntityInView to the camera? I've used inview and entitydistance before and I know they aren't exactly fast. Surely doing all that would slow the game down much more than simply drawing all the meshes at full detail would? What's the most efficient method for checking for LOD changes in Blitz3d? |
| ||
| correct me if I'm wrong, but entitydistance if pretty fast, all it has to do is a calculation like d=sqr((a*a)+(b*b)+(c*c)) It's surely a lot faster than rendering several thousand triangles. What's tricky with a lod system if you once got the models in the required various LODs, is to sync them. While static models don't need to be synced, LOD is especially useful for animated models such as characters. Some engines use a VIS system for static content and LOD for the animated parts. I wouldn't worry too much about the speed of entitydistance, it's a simple calcualtion, compared to the millions of operations that need to be performed to render a scene. |
| ||
| Couldn't you optimize that furthur by performing a LOD check only every other frame or something like that? |
| ||
| I've seen some games do a LOD refresh every half a second but what you've got to bear in mind is that if you do do something like that, is that particular frame going to lag? A better but more difficult option is to check half the scene every frame, causing a full LOD refresh every other frame but spreading the load more evenly. Obviously this then extends to checking a tenth of the screen every frame for a full update in ten frames. You would have to have a very specific reason for going to all that trouble of course :) |
| ||
| There's no way you're going to have enough entities in your scene that you need to worry about optimizing a distance check to each one. Even if you had a thousand entities, that's only a thousand square roots each frame, which on today's PC's is nothing. But if you are that concerned about it, it's trivial to optimize out the square root simply by calculating the square of the distance and using that instead. Let's say the max distance your first LOD should be visible is 100 meters. You can easily calculate the LOD to use like so:
MinDist# = 100
Exyz = Entity xyz
Cxyz = Camera xyz
DistSquared# = (Ex#-Cx#)^2 + (Ey#-Cy#)^2 + (Ez#-Cz#)^2
LOD = 4
For Loop = 0 to 4
If DistSquared# < (MinDist# * 2^Loop)^2
LOD = Loop
Exit
EndIf
Next
|
| ||
| Umm, what's a LOD? (I'm a newbie at 3d). |
| ||
| Level Of Detail |
| ||
| Thanks. |
| ||
| Sir: Sometimes, when you have really detailed meshes, and a long view distance, you might want to use meshes with fewer polygons as the object moves into the distance. That's what LOD is all about. Switching between those meshes at the right time. |
| ||
| So, using a proper 3d program, you could create two version of a 3d model, and reduce the polygon count for the distant view, thereby reducing the workload on Blitz? |
| ||
| Yep |
| ||
| But, you should make sure you need to do it before you go to all that trouble. If your model only has say 1000 polygons to begin with, it's quite possible that making a bunch of lower detail versions isn't going to increase speed at all. Each model has a base cost for rendering it regardless of the number of polygons. Or more specifically, each surface in each model. The polygons contribute only a little time each, so you might have to have 1000 just to equal the cost of the one surface alone, and halving the number of polygons might only reduce the cost of rendering the model to 75%. These are all just guesses of course. I made a foliage system which got around this issue by combining meshes in the distance to reduce the surface count as well as reducing the polygons, but that resulted in the use of tons of video memory for storing the meshes, as every single tree on the terrain had to be a unique mesh, so it was only good for relatively small maps. |
   |