Benefits of a Portal Engine ???
Blitz3D Forums/Blitz3D Programming/Benefits of a Portal Engine ???
| ||
| What are the benefits of a Portal Engine? I've read about game engines that facilitate 'continuous level of detail' - allowing the creation of large outdoor environments. Is this the same thing as a portal system? Thanks in advance, RV |
| ||
| RV, Okay, I hope this makes some sense. A portal engine only draws those sections of a level which can be seen by the camera. Imagine a model of a house broken into rooms, with doorways between each room. Each room is a place you can see by being in it or looking into it through a doorway. Each doorway is set up as a 'portal' into those places or rooms. Room One, perhaps, has a portal into room two, so the camera can see room 2 when you look through the portal. The engine only ever draws room 2 when you can see through the portal. The benefits can be huge in terms of level design because you are only drawing small portions of those levels, this keeps the frame rate bouncing along very nicely, rarely putting a strain on the machine. This means you can do more in each smaller section of the level. However, the negeative side may be that if you want a large expansive outdoor section, you may find it difficult to design with portals in mind. The frame rate may show some strain if similar detail is required. Think of games such a Metroid Prime and Jak and Daxter (if you know them at all), think of where the scenery changes are and how many times in Prime for example there is a short delay at a doorway. I think this is a complex portal system with lots of detail, loading each section very quickly. Jak and Daxter has some large exterior scenes and often rockfaces, trees, houses will obscure views around corners, where presumably there is some portal magic working its stuff. Quill 3D has a portal demo for B3D which shows the fps benefits quite nicely. Hope that explains a bit of it anyways... Ipete2. |
| ||
| the delay at the doorways in metroid prime is not a complex portal system, it's just a delay to load the next section. the portal stuff (or deciding what part has to be rendered) happens in real time. but that's a tad off topic. a good way to see how portals work is to run quake or half life or any quake engine based games and turn the wireframe view on (in quake3 it something like "/r_showtris 1" in the command line after you enabled the cheats with "/sv_cheats 1"). hope that helps. |
| ||
| doesn't loading a level as loadanimmesh() which has be chopped into segments do this automatically? only the parts which are visible get rendered, the rest are hidden. |
| ||
| That isn't true (entirely.) Objects which are outside the viewing frustrum (ie. off to the sides or behind the camera) are culled but everything in the viewing frustrum, whether or not it is occluded, is rendered. Think of a house for example. You could be looking at a wall and thus cannot see anything else but without any sort of occlusion culling system like a portals engine the game will render everything on the other side of the wall, ending by drawing the wall last on top of everything else. |
| ||
| i understand now, thx. |
| ||
| What's this continuous LOD stuff then? I've read a lot of game engine write-ups that brag about 'the ability to manage large outdoor terrains and the transitions between indoor and outdoor scenes...etc...etc' Regards, RV |
| ||
| That refers to games that reduce the amount of polygons in an object the further away it is from the camera; allowing lots of detail for close-up stuff, without wasting a lot of processing power rendering things in great detail when they're far away. It means you can have great big outdoor areas where you can see for miles, without having to render millions of polygons for all those far away objects. |
| ||
| Continuous LOD is kind of a step backward really. For a variety of reasons (too numerous to get into right now and anyway definitely debateable) continuous LOD is actually not as good as static LOD. Not that Blitz supports the latter natively but it is really easy to write code to do that. Basically CLOD (continuous level of detail) modifies the geometry of objects every frame depending on screensize (hence the "continuous" part of the name) which is pretty inefficient. Static LOD is based on simply swapping between pre-created level of detail versions of an object as the camera moves. CLOD is nice because it is automatic and in theory reduces the visual popping on objects as the level of detail changes. In practice however it is usually so inefficient that the slight reduction of visual popping is not worth it. Plus there are a number of techniques to cover up the visual artifacts of static LOD. |
| ||
| Joe, Hmm, I don't think that's how the portal system works in Virtools, perhaps it's different? I have two cameras set up to view a level with portals. Camera one is inside showing what the player sees. Camera two is outside viewing the whole level. Most of the level is not rendered because camera one cannot see it. Camera two shows only what can be seen by camera one, the walls beyond are not rendered because they are part of a place which cannot be seen by camera one, and so are not drawn to begin with. The rest of the level is not visible until you move the camera through that section. I'm not sure if Virtools culls or just doesn't draw the other parts of the level. Okay, here it is... reading the manual... Places and Portals are used to optimise the rendering phase. The decision of what to display is done relative to the active camera. Once Portal Management is active, these rules apply: 1. Before rendering the list of Places spatially containing the active camera (including the view frustrum) is composed using the Places bounding box. These Places are considered to be potentially visible and processed by the renderer. 2. If an element is not a member of one of these Places the element is not rendered. The element is considered "out of view". It goes on to say without Portal Manangement system being active only hierarchical culling of the scene will determine the potentially visible set of entities. What I can say is that it is a very efficient and worthwhile system to implement and levels designed with it in place will allow more processing time overall, which is a good thing. Regards, IPete2. |
| ||
| I was responding to sinu's post just above mine. He was misunderstanding portals/occlusion culling; you understand it correctly. |
   |