Need opinions: Best occlusion method.
Blitz3D Forums/Blitz3D Programming/Need opinions: Best occlusion method.
| ||
| Ok, I've started using a new method for building levels for our game, which gives us a bit more flexibility. However, I can see surface count (and possibly polycount) getting quickly out of hand. Basically, a level is created out of tiles...there will be floor tiles, wall tiles, ceiling tiles, even secenery tiles. The level will be created using a grid of sorts, where every tile is fit for a 10x10x10 cube. Tiles can be rotated as well, in 90 degree increments (mainly useful for the walls, obviosuly). Doors will be implemented much like those in the old Descent game, except instead of animated textures they will be animated meshes, which will work like this: Blocks characters unless fully open. Blocks line of sight only when fully closed. Anyway, this will quickly end up being a seriously big drain as far as surface count and polycount goes. I think I have a few options: Single surface - Turn the whole map into a single surface mesh, sharing a single huge texture with all our tile skins on it. I can see the polycount getting high really fast here, and other possible rendering issues. Visual Culling - If the cam can't see it, don't render it. I get the feeling this could get really slow, since it would need to check every entity within visual range and manually hide/unhide based on the result. Even with a short view range, that could get nasty because of how many tiles can be used in that small of an area. Plus the result STILL might have too many surfaces... Modified Single Surface - Make groups of single surface meshes out of the level, seperated by key elements like doors and such. If the camera can't see a group, hide it. I don't really know of any other methods...and I'm not quite sure how to implement some that I do (single surface). Can anyone give me some advice on what the best method would be for this kind of environment? |
| ||
| I think this is good enough http://www.blitzbasic.com/codearcs/codearcs.php?code=1244 |
| ||
| So basically you're saying turning the whole map into a single surface mesh, and then splitting it up into managable pieces, would be the best way to go? |
| ||
| For make shadowreceiving map is not good solution. I was try to make but is no good |
| ||
| Ok, here's an idea...say I assemble my map tiles in gile[s] instead, so I can lightmap them and export each map as a whole unit. I assume there will only be as many surfaces as their are unique textures, correct? |
| ||
| If your level is an indoor dungeon-like environment portals would work perfectly. But how to implement portals efficiently in Blitz3D I don't know. Sometimes you could implement an occlusion culling system that spends more time calculating what's visible than it would take to just render the whole level by brute force. Here is a good explanation of how portals work... http://www.3dkingdoms.com/weekly/weekly.php?a=26 |
| ||
| I'd suggest to load the level as one huge mesh, then "clusterize" it. finally let direct X do the occusion job, based on camera range and view angle. I've done some tests and as Sweenie said, hiding/showing things may be even slower than brute force rendering. The Level design should however support this philosophy and spread the map in a way that allows to skp parts due to their distance. (aka "long ziczac corridors" between places) |
| ||
| Portals did sound like a good idea from what I know, perhaps I'll do more research on them. However, this is my problem...I want to be able to dynamically create the levels from the base tiles (thus making map files very small, and able to contain all the data I need in a simple, easy to work with format). I suppose if I can merge large parts of the mesh into a single surface system (perhaps set up zones in my editor, which dictates which tiles are merged into a group), I could still "chunk it up" and let direct X handle the rendering based on view angle alone...brute force. Still, I have the problem of making single surface work. Has anyone ever done a simple single surface system that can combine multiple static meshes using the same texture into a single, single surface static mesh which still maintains it's ability to do collision detection? How complicated would such a task be? |
| ||
| "Single Surface" is not really what you need, it means "only one texture file for everything". But you surely could optimize the surface count! You only have to ADDMESH all objects to a new Mesh, then delete the originals (works atleast with static meshes, the animated ones may have to be handled seperately). After ADDMESH everthing to one mesh, the surface count will be optimized automaticly. For this purpose you should store each Entities position, rotation and scaling, then reset them to the creation states (position, rotation =0, scale=1.0) then use the PositionMesh, RotateMesh and ScaleMesh commands with the stored values, then add the meshes together. You also need to use PainMesh or PaintSurface on the basic object to make them work with AddMEsh (don't use EntityTexture). If you once have a single mesh, you still may clusterize it, as described before. Collision detection still can be done, altough you won't be able to seperate the basic objects the map is made of. |
| ||
| what I did it make whole level, do lightmapping properly and then slice out smaller chunks of level, and then load them separately, and let blitz do his own occlusion stuff...result? faster than any method i apply for occlusion... |
| ||
| Ok JFK, I think I see what you mean (did some poking around in the Mesh section of the manual). So by optimizing surface counts, do you mean it will combine all surfaces that use the same texture? If so, this may be a good deal easier than I thought. Naughty Alien makes a good point about lightmapping, however because of the method I want to use I suppose I'll have to use a different technique to create lightmaps... EDIT: Just tested the addmesh thing out, and it seems it does combine all surfaces using the same texture. And indeed it maintains collision ability. So, in effect, if my artist uses the same texture on all the tile meshes in a particular tileset (a huge texture with all of them, made possible with DDS thankfully), this would actually become a single surface system automatically then? Of course characters, doors, and such are another story, but I'm much less concerned with that at the moment. The tests I've done show that with a little optimizing, this should work out great as long as the levels don't bring me down. |
| ||
| Yes, as long as the brushes use the same texture flags etc. then it should optimize it this way. Don't forget to split the mesh is clusters after the union, this will give you a high speed based on a good relation between surface count and Tris rendered. Clusterisation will double some surfaces, but don't worry too much about Single surface. The card can easly handle some dozens of sufaces, if the number of triangles is not too high. You should not reduce the surface count at ALL costs. Because, what ever is part of a mesh that lies within the camera viewrange, it will be rendered, even if most of it is behind the camera, or out of its range. That's why clusterisation makes sense. |
| ||
| Good point...and I actually think I have it figured out perfectly. In my editor I'll give each tile a group value...and when the map is assembled all tiles that share the same group are merged into a single, low surface count mesh. That way DirectX can handle the rendering "brute force" without having to do the whole freaking map...only the groups that can readily be seen. |
| ||
| Ok, I have another question. Since I've figured out that this method does in fact work and is exactly what I'm after...there's one thing remaining. Lightmapping. So basically I'm thinking of this: Create map in editor. Export file telling engine which tiles go where, and which ones need to be merged into groups. Render and export level lightmap. Load map info into game engine, build level out of base tiles according to saved info and merge into pre-defined groups. Load and apply level lightmap. I've pretty much figured out how to do everything but the lightmap. I'm concerned it might become quite difficult to render and apply a lightmap to a level that is made of several meshes that are created out of merged groups of smaller meshes. I'm not looking for ultra-fine detail lightmaps by the way, just simple ones. |
| ||
| Depends what editor you are using but I do this, Build level as chunks in 3DWS, Import chunks into Gile[s] then position and lightmap them, Export to .b3d. Engine just loads in the lightmapped chunks with no need to separately position them or apply a lightmap. |
| ||
| Well, problem is I'm creating my own editor. So far it's working great, maps are stored as simple data files that are very, very tiny. The engine builds the map by arranging tiles in a grid of 10x10x10 "cubes." |
| ||
| The problem will be: lightmapping takes a lot of time, several minutes, up to hours, probably. This is why people render them once, and then load the finished level map, with the lightmap applied on texturelayer 2. Personally I have to say, tiny files are nice, but not neccessary. These days people download 20 megabytes even if it's only a stupid movie that they will watch once and then delete it. So I wouldn0t care too much about the level file size. Anyway, it's the textures that are "eating" the megabytes. BTW there are several lightmapping sourcecodes in the archives. |
   |