Any progress on the map occlusion thread?
Blitz3D Forums/Blitz3D Programming/Any progress on the map occlusion thread?
| ||
| What came of that thread? It is something we all need to think about, and I have time to dump some effort into it atm. |
| ||
| Yeah, i agree. But i'm getting more and more sure that there is no one solution to this, as all games will require different methods and ways of occluding. |
| ||
| True it is... I was thinking I might save myself a massive headache and just hand place occlusion checkpoints via editor... should be easy enough, just a bit time consuming. |
| ||
| Yeah, that would be an ideal solution, and probably the route i'd take if i was gonna do sometihng like that. That way you decide the best place to put them :) A nice map editor would be good. I think maplet 2 will have this :D |
| ||
| I won't be using maplet... probably ever :). I have artists to do that stuff, so long as I provide nice tools, they seem happy, heh. |
| ||
| lol, well, i didn't realy like maplet too much. I didn't like the way you couldn't move or edited stuff, it was pretty limited, but in saying that, i didn't give it a chance really :S Sounds like you got quite a team ;) |
| ||
| I think there is no generic occlusion solution. instead for every game design style and method an individual occlusion method is required. Outdoor requires LODing , probably even use sprites for distant Things I also used to read dot3 is also used for complex shapes of archithecture, mapped on simple quads. For indoor games it depends on the Geometry as well as on the Mesh Properties. Each brush a singe mesh, so they can be hidden quickly, based on some visibility lookup tables? or assemble the visible Parts of a mesh in realtime, each frame from scratch (like some single surface systems)? there can't be a good occlusion if the geometry is completely "wrong". There shouldn't be large rooms with lots of details and stuff inside. This simply cannot be hidden. There is a simple method to get very good results: make shure each room and gangway is never longer than say 50 units. you can make S-shaped corridors etc, but just make shure the viewrange is never greather than 50. This way you can set the CameraViewRange to 50, this will speed things up dramaticly. This mehtod is limiting the artistic freedom of the enviroment designer quiet a lot but it might be a good choice for beginners. |
| ||
| I disagree with a lot of what has been said here. I think that many games can benefit from a generic occlusion system. I agree that some games might require extra systems for complex outdoor scenes, but they may still benefit from a generic solution. I also don't agree that you can only have good occlusion with 'correct' geometry. There is no reason why geometry can't be organic, complex and detailed, and yet still be occluded. Take a look at the way Quill handles occlusion, it works fine and can handle complex scenes. The only problem with it is that it is tied to Quill itself, which isn't the best map maker. |
| ||
| Even without Quill3D, if you construct an indoor level by using a single mesh per room it is then simple to make your own occlusion system. I always use the method which is the simplest BUT one that also achieves the required performance. A simple 'occlusion' system can be achieved by keeping a list of which rooms are visible to each other can be effective enough. Sometimes all you need is a list of which rooms are possibly visible from the one the camera is in and just render those in near to far order, to take advantage of the z buffer. Other times this may not be enough and you may need to use portals to check which rooms are actually visible, it all depends on how many surfaces/meshes you are having to render. The two methods above I suppose could be called generic methods so I agree that a generic method may suffice for many games. |
| ||
| Occlusion and LOD has always been a priority for myself and I have pondered many indoor/outdoor implementation schemes as well. I would agree that there cannot be one generic implementation as it totally depends on how the game level is constructed and how the game engine deals with its geometry. Additionally, implementation can have many stages. For example, I construct my levels in 3DSMax exporting the level in 3DS format. In which the geometry is stored in a list of submeshes, each with a specific label. This is the first stage of implementation. My Automated visibility data generator (VIS) relies soley on entity labels to identify what submeshes must be hidden or not dependent on its label (ie: prop01, door03, item02). How the VIS generator gathers and stores this VIS data is second stage of implementation. My Game Engine design to specifically use VIS data produced by the VIS generator to show/hide and apply collision. This is the final stage of implementation. If a generic occlusion system is to be realized, it will have to cater to game level geometry. The game engine will have to cater to both the occlusion system and geometry. |
   |