Portals, simplified
Blitz3D Forums/Blitz3D Programming/Portals, simplified
| ||
| 1. Create boxes surrounding different areas of your map. 2. Boxes that touch each other are considered adjacent. 3. If the camera is in one box, all adjacent box areas are drawn. Areas that are two degrees away are hidden. Simple, effective, easy to set up, easy to implement. |
| ||
| That's a good idea actually... :) |
| ||
| it's also not going to work very well. |
| ||
| Ayup. |
| ||
| Areas that are two degrees away are hidden. halo, Please elaborate. I assume each box stores a list of potentially visible polygons (meshes|areas|etc)? If so, will this not require preprocessing? If this data is preprocessed, why would it require areas that are two degrees away be hidden? I've dubbed the technique above Cubic Space Partitions (CSP). With CSP each box (cube) contains a list of potentially visible polygons. When the player moves from one cube to another, the previous cube's polygon are hidden and the next cube's polygons are shown. The cool thing about CSP is that it works on any type of geometry and is very flexible at a high level. The trick is acquiring the list of potentially visible polygons and myself and few others have developed a algorithm/process to automatically acquire this data. ;frankie t's identify color by uniqueness (icu) algorithm
array vis(n,n,n)
global worldscale#=.1
loadanimmesh levelmap.b3d
for each childmesh within mesh
apply unique color equal to childmesh index
set childmesh attributes to fullbright, flat shading, disable fog, disable backface culling, no texture
next
repeat
increment camera through level map geometry on x,y,z planes
cameraPosition camera,{camera.increment * worldscale#}
vis(camera.increment.x%,camera.increment.y%,camera.increment.z%)=create bank
for cameraAngles% = 1 to 6;(up,down,left,right,front,behind)
cameraAngle camera
snapshot=cameraSnapshot(camera)
for each snapshot
for x = 0 to snapshotWidth
for y = 0 to snapshotHeight
color%=readpixel(snapshot,x,y)
if color>0 and not on vis(camera.increment.x%,camera.increment.y%,camera.increment.z%)
poke(vis(camera.increment.x%,camera.increment.y%,camera.increment.z%),++,color)
endif
next
next
next
next
until camera completes level
|
| ||
| Sorry, I left out that if an object is within that box, it is hidden and shown with the portal section. I would actually merge the meshes within one area into a single mesh, for walls and stuff that doesn't move. So if a portal area gets hidden, that part of the map is hidden, and any entity within its bounds can skip updating. Obviously, you would set the portals up so that they meet as they go around corners. You have to plan how they are aligned, but if you just lay them out, the system takes care of the rest. Look at the UT2003 map "Training Day" for an example of this. As for the two naysayers lacking explanations, you're just contradictary idiots that will argue with anything I say, because you know I am a million times better than you at everything. You are useless and have accomplished nothing, so just shut up already. |
| ||
| "As for the two naysayers lacking explanations, you're just contradictary idiots that will argue with anything I say, because you know I am a million times better than you at everything. You are useless and have accomplished nothing, so just shut up already." Et tu, Brute? He jests at scars that never felt a wound! |
| ||
| Lordy lord. Will you two just stop it and kiss and make friends. The irony here is that in real life, you'd probably be good buddys cause you share a lot in common. |
| ||
| I hardly think the fact that we are both caucassian and we both program in Blitz basic counds as "a lot in common". Besides, you're mistaking witty barbs for attacks. :-) |
| ||
| sswift (Posted 2004-06-13 03:30:39) I hardly think the fact that we are bouth caucassian and we both program in Blitz basic counds as "a lot in common". Besides, you're mistaking witty barbs for attacks. :-) Good to hear :) |
| ||
| i believe this is how the terrain in morrowind works - it's not a great system though, because if your "boxes" are small you'll potentially have a poor view distance and if they're fairly large you won't get much benefit (or you'll have agonising pauses for loading like in morrowind) |
| ||
| I wanna be a idiot too. (Mission accomplised. Procede to Level 2.) That was quick... as for the idea, I already posted this idea a while back, but insted of manually creating the boxes that 'touch', it genereates them it's self, then creates bounding boxes for each sub-group, and then come run-time it displays the one you're in and the surrounding ones. I believe any feature that can't be 'integrated' code-wise is never going to have the same popularity as one that can. Mostly because I and million coders like me have no talent when it comes to setting up portals and messing about with 3d apps. for example, normal mapping. Great feature when used right, but really needs to be set up in a 3d app for world space due to the lack of tangant 'conversation' in blitz(Why mark, why!?) Result? Not a single game or proper demo that uses it made in blitz. Still, good to have in a 3d app too, for those of us lucky enough to have artist doing all our dirty work ;) |
| ||
| @Octagon: couldnt agree more -- I want a fully integrated turnkey solution -- create extreme (terrain+(building with complicated interiors)), run it through a compiler and have it run like the wind when loaded in Blitz :) And I frankly dont care how long it takes to compile -- I got a dual 2.8 xeon for doing grunt work like that. Now to learn enough about the issues and the techniques to contribute to making the integrated solution we want !! @Frank Taylor: how well do you think CSP/ICU could handle a situation like I'm trying to work with -- say a terrain with a dozen 2 story buildings loaded from .X files, each bulding with 2-10 rooms, and lots of static furniture/props in each room. For example, using an ALE terrain and the props file it generates as the source. Each X file represents an entire building. Say >2.5 million polys total. Perhaps 2 levels of CSP data ? One for outside, one for inside, possibly seperate interior data for each building ? |
| ||
| Terrains are easier, because you can just segment it and use regular dynamic lod on each segment. I don't believe any solution which involves dynamic mesh rebuilding is ever going to be worth bothering with, at least not until pci... It takes *ages* to resend mesh data over to agp space, which you have to do once the mesh is rebuilt. Or you could use vertex arrays to render from system memory but again the speed hit will be so 'massive' it 'renders' the whole excersise pointless. Unless perhaps maybe you're using a real-time lod/dynamic mesh method that only resends a tri indice list over... which is possible...might be fast enough. So segmented terrains with lod, and ideally for buildings you'll use lod too for the outter surface, and make the 'innerds' a seperate surface that is activated once it's parent mesh lod level raises above a certain 'trigger'. Also for props as you mentioned, single surface them. If they're static that is, if not, copy entity them. Never use multiple versions of the same mesh, it eats up too much agp memory for a decent level and will cripple bandwidth/surface changes. It's all about minimizing overheads and bandwidth. Pure poly count is only a small factor in the overall speed of a engine. |
| ||
| What if you're looking out of a window that sees an area more than 2 degrees away? Oops. There's a reason professional games haven't picked up this brilliant idea yet. |
| ||
| ZombieWoof, CSP/ICU could be used as long as you can divide the mesh into smaller sets. You will have a large VIS data set. I would also recommend using some form of LOD. |
| ||
| @octagon: tri-index-list possible in blitz or possible if I do my own engine ?? Lets assume for the moment that solution must work with the current blitz3d :) For the props, I get them as a X or 3DS file that defines the entire building -- would take some work walking the graph of sub-meshes to detect duplicates. @frank: thats the whole point of the compiler :) I think you just defined part of the process flow chart :) I'll take the hickey on vis dataset size if it can work reasonably fast. @all: Have we had enough theory yet ? are we ready to try an implementation ? modular enough that we can replace pieces with better code as it comes along ? like this: 1. process terrain into chunks. assign props to chunks. props with bounding boxes that span chunks belong to both chunks. 2. build terrain lod info. 3. perform CSP on each chunk considering only the mesh, not any props that have been dropped on the terrain. Can be fairly coarse here to avoid frequent mesh updates to gpu during movement. 4. seperate interior/exterior mesh of eash prop and create lod data for exterior (in the process detecting props for which exterior extraction doesnt signifigantly reduce the number of polys, just create lod data for those.) 5. on props for which it was possible to create seperate interior / exterior mesh, perform internal CSP or other PVS operation at the entity level, no point in dealing with tri visibility here. (could go all out here, divide the mesh into rooms and regroup the meshes to make each room an entity, then do an auto-portal setup) outputs to this point: 1. segmented terrain, and lod'd versions of same 2. prop/exterior meshes, and lod'd versions of same 3. terrain csp data + prop placement 4. rebuilt interior meshes/mesh sections with vis data 5. control file to tie the whole mess together, and tell the BB lib code what to load :) Most of this can be done as small apps that handle a single step independent of other steps. Can y'all help me out with existing code that does any portion of the process, or demonstrates useful techniques ?? Especially the mesh chopping stuff :) All this makes me want do a project management system that will control the build process and only update the portions that need updating when parts change. If an auto-portal system is used, will also need a mesh/portal viewer/editor so the portals can be fine tuned, or created manually (option to not auto-portal a mesh after seperating it into entity meshes for the masochists that want to manually setup portals) |
| ||
| This isn't for distance, this is for indoor culling. If you are in the red area, everything is shown. If you are in the green area, the red and green areas are show. In the blue area, the red and blue areas are shown. Before anyone points this out, you would obviously need to adjust the areas so that your line of site was blocked between the blue and green areas, by the corners of the walls. I'm not posting this for your approval, but just because it is a cool easy way to do this.  |
| ||
| halo, Looks promising. I would like to see the concept in action to get a real for it. I'm very interested in how it will handle non-orthogonal geometry. ZombieWoof, I'm currently working on a new VIS/CSP/ICU Processor for Open Source Project PLASMA 2004. You are more then welcome to use it when complete. No Estimate Time of Completion, but I'm shooting for next week. |
| ||
| perfect == should have the code for seperating hi poly meshes into internal and external by then -- I think I got it working but its not displaying right -- very brute force approach: from each vertex, linepick along the vertex normal -- if any mesh is picked, mark the vertex as culled. scan all tris, if the tri has a vertex in the cull list, skip it, else copy the tri to a new mesh. I've blown something copying the triangles tho, cause newmesh is showing up only every other render as I add verts/tris and rerender after processing each surface. When its done, it only shows the original mesh, though the poly count has increased for the new mesh. doesnt do too badly though -- 40K face mesh down to 14K - and could probably do a lot better with a better external face detect algorithm. http://www.camelot-software.com/files/exterior.zip if someone wants to look over the code and tell me where murphy tossed in the monkey wrench :) |
| ||
| The drawing is square because that was easy to draw. The angles of the walls are totally irrelevant. |
| ||
| @halo -- trying to understand what you are getting at -- are the colored boxes generated automatically, or are you drawing them on a bitmap and then using that bitmap like a CSP dataset to determine whats visbile ?? (i.e. the current color and any adjacent colors ?) |
| ||
| updated www.camelot-software.com/files/exterior.zip I fixed a coupla bugs, but its still not showing the new mesh. I thought I had it right, copying verts, creating tris, copying normals and brushes. RenderWorld is processing more tris, but nothing new is showing up. help !! Edit: ok.. forget that method -- these meshes I'm testing with have to many overlaping surfaces that cause mesh hits when part of the surface is obscured On to Method #2 -- UCI and pan around the building with flat perspective camera settings |
   |