Polys Rendered
Blitz3D Forums/Blitz3D Programming/Polys Rendered
| ||
| Is there a way to keep Blitz3D from rendering polys that are obviously blocked from view. In my scene I walk up to a high hill that blocks out everything behind it, and I still have the same frame rate as when I am fare away from it with the scene behind it in view. The tris count also stays the same. I thought z-buffering is supposed to cut out everything that is hidden by something else. Do I need to set something to get z-buffering to work? |
| ||
| No, that's not what z-buffering is for. In a sense, z-buffering is in fact just the opposite; it allows things to draw in the correct order, so that things hidden behind other things aren't drawn on top. What you want is occlusion culling. BIG topic that. The idea is to chunk up your scene in some way, determine which chunks are visible, and hide the other chunks. |
| ||
| So Blitz doesn't have a command for this then? Or a way to set a meshes attributes so if it is behind something it's not rendered? So I have to use EntityInView, and check every mesh in my scene to see if it is visible then? |
| ||
| Actually, I don't know if EntityInView will work. I don't remember exactly but I think that command simply checks if an entity is within the viewing frustrum, regardless of whether or not it is occluded. And you generally don't want to check every mesh in your scene (unless your scene is comprised of very few meshes.) Instead, chunk up you scene into zones, with meshes grouped inside of zones. Determine visibility on entire zones (there's LineOfSight code in the code archives; that's still not an ideal approach, but it's a start,) hiding/showing meshes in groups. It'll be faster than attempting to nitpick about what is and isn't visible. |
| ||
| AbbaRue, Heres a very useful system for developing your own Occlusion, Hidden Surface Removal, or VIS System: CSP Compiler. I developed a similar system myself and requires level maps that contain child meshes. It works by coloring each child mesh with a unique color starting from 1. The child mesh id = unique color value. A camera is incremented through the level taking snapshots. A set of snapshots from 6 or more angles are usually required. The set of snapshots are scaned for the colors. The camera position and colors found are written to a data file. Once saved, there are many ways to load this VIS data for use. One way is to load camera position into a 3 element Array Table and child mesh ids into a bank. VIS(x,y,z)=ChildMeshIDBankOnce the data is loaded you could easily display visible Child meshes corresponding camera x,y,z position. Assuming you handle your child mesh geometry with the Array childmesh(n). For loop = 0 To BankSize(VIS(camera\x,camera\x,camera\z)) Step 4 ShowEntity childmesh(PeekInteger(VIS(camera\x,camera\x,camera\z),loop) Next Overall the system is fairly simple and works well. |
| ||
| I finally know what Occlusion is, and have some idea now of what it involves. I can remember the old Ultima2 game. When you explored the world everything stayed black until you explored it. I can remember the way the viewing area lit up as you approached it. I always thought a simular approach would work in 3D. Only thing is height is a major factor here. I think some kind of ray casting would work, only thing is the time for the raycasting is probably the same time needed for Blitz to render the scene itself. So I think that LOD preproccessing is the best way to do things. I just thought Blitz had some function to do this, that I didn't know about. Because when I spin around in a 3D scene I noticed different frame rates at different angles. I thought that had something to do with items blocking the view. I now think hidden surfaces actually slow things down, because they are harder to display. |
   |