I have been experimenting with the PortalNode object provided by Panda, and have put together an example showing how to use it. Its purpose is to optimise when you have large levels with limited visibility from one area to the next - think of being inside a building.
Whilst the example is running you can switch between two kinds of portal geometry by pressing ‘p’ - the default allows you to see the culling effect, the alternate hides the culling effect so you can see that it would in fact look fine in a game.
There is a problem when using this with the current version of Panda - it displays hard coded debug information in the form of a square where the portal is, with lines to the screen corners, and it can’t be switched off. This has already been fixed in cvs and will be picked up with the next release of Panda - thanks go to pro-rsoft for that. This demo should continue to work when that happens, just without the silly lines.
A more detailed explanation of what is going on can be found in the header of the linked to code, but I’ve c&p’ed it below for those who want to know if this is of value to them:
The first thing to realise is that these are not portals in the walk in at one location, walk out at another location sense - they only exist to optimise rendering speed by culling large amounts of geometry. Nothing changes location, or is perceived to have changed location. The idea is that you divide the level into cells, where each cell has limited visibility of the other cells. Each cell is represented by a PandaNode, with everything in that cell a child of the node. You then have portals within each cell - a portal is a single polygon with 4 vertices through which you can see into another cell. For instance two cells might be a room and a corridor, so you would have a portal in the doorway. Portals are one way, going from the cell they are in to another cell; this means they will often come in pairs, one for each way. What they do is when you can see a portal it checks and renders only stuff that can be seen from the cameras viewpoint, that is in the ‘out’ cell. This works recursively, so if you can see a portal through a portal then that portal will also go through its children and check visibility, and so on recursively. Whilst this is not much use in outdoor environments in indoor environments this method could easily save rendering the vast majority of a level. The below code demonstrates usage but a key issue is that all cells must be hidden except the one that the camera is in. The currentCellTask task achieves this below. Additionally, if an object were to move from one cell to the next its parent cell would need to be updated - the PortalNode only provides basic clipping functionality, the rest has to be done in code. There is also a potential visibility glitch in that a portal could be not visible but an object inside its ‘out’ cell could be poking through and visible, but because of the portal code not rendered - this can be ignored or has to be solved by the user. (Its usually rare that a user will see it, and only happens with very particular level geometry/object combos.) As a further point you need to enable portal culling in the settings file - this is done by the settings file provided with this example.
This is fantastic, thanks for the demo! I just noticed the PortalNode stuff yesterday and was planning to look into how to do occlusion culling with that. Is this a new feature?
Also, are portals supported by exporters for Blender and/or Maya?
Its been around since '04 according to the C++ files. However, due to the debug info I find it hard to believe that anyone has ever actually used it in all that time! But then panda is kinda enormous - I bet there are entire lost systems, forgotten many moons ago…
I know the Blender exporter does not support portals (Well, you could always tag some geometry and pick it up in code.), don’t know about the Maya one though, but I doubt it. However, I’m not sure how much sense it makes for them to support it - you can export portals (The egg syntax exists.), but you need lots of setup code to get them to work, and in a real game will need extra information - i.e. bounding regions to define these areas, info to define the cells, etc. My intention is to export AABB’s from Blender as part of the level editing process and detect where they intersect, which will be where I construct portals. That makes working out which region an object is in very easy and whilst limited is good enough for most buildings.
I’m not entirely sure what you’re describing here so I’d love to see a demo when you do this. If you’d be willing to share it, seeing the scene in Blender is worth a thousand words.
Well, I haven’t coded it yet, and its part of a top secret project (Well, not entirely public at any rate.) being worked on by several forum members… But it is going to be released… just not yet as we want to reach a certain level of completeness before doing so. Sorry, but surprises work best when not drip fed!
I’m not sure that you fully tested this. If you change the colorscale to blue for cell2, you’ll notice your portal is actually just showing the cell that you’re in… not the next cell over.
I didn’t write the portal system - I just put together an example of using it. And as issues go, that is minor - it has some real serious bugs when taking a camera through a portal, which I intend to fix, I just need to find a weekend to figure out how the system works first! As for changes applied directly to the portal node, I’m not surprised they don’t work, as the node is effectively ‘ignored’ - when rendered the state is derived from the currently visible node instead, so the cells should not have state changes applied to them if you want consistent behaviour - try applying the colourscale directly to the objects instead.
I merely color scaled the cell so that I could tell celles 1&2 apart. I’m not sure exactly what went wrong (I thought I did, but thinking back I’m not so sure…) But somehow the portal was looking back into the cell it was in.
I have discovered an interesting use for portals. I figured out that you can attach the portal to the camera, with enough room to not show the debug bounds. I’m using it in an FPS to transition from area to area which are set on separate NodePaths that aren’t in turn reparented to the same top node. So you can in a sense, create buffer zones that load the next area, and transition you when you cross a boundary.
The only major drawback is, the portal system seems to draw the portal relative to the global position of the mesh or cell or zone or whatever you’re using, so your levels hafto line up as if they were parented to the same nodePath. If you were careful in your construction in Blender or Maya, this shouldn’t be too much of a problem.
The other potential use is for a skybox, though again, that’s problematic if your character travels very far.