LinePick - possible speedup?
Blitz3D Forums/Blitz3D Programming/LinePick - possible speedup?
| ||
| In fact this *may* apply to any Pick command on a polygon-enabled mesh. Will chopping a level into sections (different meshes) increase pick speed? It seems that Blitz has to loop through all polys in a picked mesh every time in order to find the relevant tri/normals etc. Therefore (in theory) having more meshes with smaller polycounts instead of 1 big one would give a boost??? Of course the balance is between more surfaces vs. pick speedup, and I don't know where the scale tips. If you've got a lot of picks going on it may be worth it though. Or am I talking nonsense? |
| ||
| I think sswifts shadow system works alot better if the levels are segmented, rather than the one chunk. But, that may have something to do with only visible meshes being checked, i'm not sure... |
| ||
| Yes. I actually store one merged copy of the map for rendering, and a separated copy for collision. |
| ||
| Oh yeah, that's a good idea Halo. 1 visible mesh and multiple segments with 0 alpha. Best of both worlds - same surface count + faster picks. Nice. |
| ||
| Assuming that when you do a line pick, Blitz first checks the bounding spheres to see if the line pikc intersects them, then yes, it would speed things up. That said, Blitz apparently does not do things in the most optimal way all the time. For example, hiding entities outside the view of the camera manually is faster than just leaving them visible, even when no collisions are enabled. This appears to indicate that Blitz doesn't even do basic sphere-frustrum tests before it tries to render the world. So it is entirely possible that linepick also does not do such a test. In which case, you could speed it up by writing a function to determine if a line intersects a sphere, and doing your own culling that way. I think someone put a function I wrote for them that does line-sphere or maybe it was ray-sphere intersection in the code archives. The only way to know unfortunately is to code a test program to see if checking manually is faster than letting bLitz just do it's thing. Also, spheres are not the only way to cull secitons of level. If your level is static it would be possible to build a BSP tree. A BSP tree might help you do linepicks much faster, though I don't know how. |
| ||
| For meshes, use a bounding box around the mesh and test each mesh one at a time. If an EntityVisible() command returns true when the bounding box is visible, you don't even have to test the mesh itself. This is how I can put lots of flares in a 15,000 poly room, with picking every render in like 0-1 msecs. It usually does about 60 box tests, and then maybe like 3 mesh tests out of that...so like 95% of the triangles you would normally have to test are eliminated. |
| ||
| Regarding the offscreen culling, yes, Blitz tests each surface on a per-triangle basis, which is frankly stupider than ****. You can do BSP and stuff, but the simplest thing to implement is what I described, and it will yield the same results. |
| ||
| Octrees are great for speeding up line picks. You just check which nodes the pick intersecets with, and check the tris in those. So even if you're checking against what was a single mesh of 200,000 polys, if you pick in the centre of the level where no tris are, it'll check nothing. If it passes 5,000 tris, it'll just check those. |
| ||
| I just tried updating my terrain system to hide all entities out of view, but if there is any speed improvement, it's minor at best. I was sure it was going to result in a big speed improvement, since I saw such an improvement when I made a starfield out of a grid of hundreds of copied entities. Now I'm not so sure what Blitz is doing as far as culling goes. It's quite odd that it would have a big effect on one, but not the other. Then again the terain system did already hide those entities with the most polygons when they were in the distance, whereas the star field did not attempt to hide any entities itself at all. I'm not convinced though that Halo is right that the system does culling by checking individual polygons. I think it simply isn't doing any culling at all and instead relies on the 3D card to avoid rendering those entities which are out of view. |
   |