Polysoup portalizing.
by Andrea Barolo · in Torque Game Engine Advanced · 04/29/2008 (5:57 am) · 9 replies
Hi, for what I've understood polysoup DTSs doesn't support portalizing. I've duplicated the polysoup tower that comes with 1.7.0 about 20 times to make a small city and I've found that the engine start suffering when you look toward a consistent group of buildings. I was wondering if is it planned to enble portalization also to polysoup models (so we can definitively drop DIFs)?
If this is not planned, is a suitable road to make a trasparent portalized DIF map and to fill the room (not real rooms but portalized volumes) with polysoup DTSs? Would then also DTS take advantage of the portals? And what about exteriors? Which is the road you would follow if you wanted a map like the ones seen in the last Unreal Tournament?
Thank you for your time.
If this is not planned, is a suitable road to make a trasparent portalized DIF map and to fill the room (not real rooms but portalized volumes) with polysoup DTSs? Would then also DTS take advantage of the portals? And what about exteriors? Which is the road you would follow if you wanted a map like the ones seen in the last Unreal Tournament?
Thank you for your time.
About the author
#3
I'm not a programmer so take this as it comes: I don't think it should be so difficult to implement such a system, you can maintain the bsp visibility system and connect it to a system where every dts is made visible or invisible if the containing zone is visible or not.
And it's really speedy and comfortable from the artist point of view also if you think the time you spare not to have to use bsp building programs. Also from the map design point of view would permit a lot more creativity: let's be honest bsp only maps could be complex and pretty with time spent on them but they will always be blocky.
By the way another question comes to mind: Do you remember Jax and Dexter? It's an old game but it did have transition from outside to inside buildings without the need of loading zones (it had background loading). How do you think it was accomplished?
04/30/2008 (12:46 am)
The way I think is good to go is to construct a convex "map" made of boxes, where every box contains a dts room, and are all connected through portals. As in the editor for dts you define a convex collision mesh around your object you could define a visibility zone around you room or your building. It's the way it's done by Terathon's C4 engine.I'm not a programmer so take this as it comes: I don't think it should be so difficult to implement such a system, you can maintain the bsp visibility system and connect it to a system where every dts is made visible or invisible if the containing zone is visible or not.
And it's really speedy and comfortable from the artist point of view also if you think the time you spare not to have to use bsp building programs. Also from the map design point of view would permit a lot more creativity: let's be honest bsp only maps could be complex and pretty with time spent on them but they will always be blocky.
By the way another question comes to mind: Do you remember Jax and Dexter? It's an old game but it did have transition from outside to inside buildings without the need of loading zones (it had background loading). How do you think it was accomplished?
#4
That looks like a good plan. But instead of each mesh being a seperate zone, how about having a zone identifier being part of the original mesh name (like "hallway zone-1" or something). That way, you could have multiple meshes being part of a single zone, and wouldn't need to define extra collision meshes to encapsulate the zone. All Unzoned meshes would by default be part of the outside zone.
04/30/2008 (6:38 am)
@Joseph:That looks like a good plan. But instead of each mesh being a seperate zone, how about having a zone identifier being part of the original mesh name (like "hallway zone-1" or something). That way, you could have multiple meshes being part of a single zone, and wouldn't need to define extra collision meshes to encapsulate the zone. All Unzoned meshes would by default be part of the outside zone.
#6
Visibility could be handled by the artist hand editing the portals, and saying what zone they pointed to. Then doing an occlusion test on the portal before deciding to render any other connecting zones (and then of course recursively adding the pointed zone to the scene and repeating ad infinitum)
The other idea sounds good too, but it looks like more work for the artist. Still, not a bad tradeoff.
04/30/2008 (7:27 am)
If the zones were completely enclosed (with portal and non-portal polygons), and there were no intersections (there shouldn't be anyway), then you could find your zone by finding the closest polygon along any line, and finding the zone that it was in.Visibility could be handled by the artist hand editing the portals, and saying what zone they pointed to. Then doing an occlusion test on the portal before deciding to render any other connecting zones (and then of course recursively adding the pointed zone to the scene and repeating ad infinitum)
The other idea sounds good too, but it looks like more work for the artist. Still, not a bad tradeoff.
#8
What if we handled it based on entering portals defined for each zone. You would set it up so each mesh had a zone identifier as Jaimi suggests. Something like "hallway zoneArea-1". Than you would have portal meshes defined with a portal and zone identifier. Like "hallway zonePortal-1" where the "zonePortal-1" ties it in with a list of portals for zone-1. Portals should be one sided, with the face normals pointing in the direction the player will be entering from, to register collisions when entering but not leaving. This means that you will need 2 meshes for each portalled area; 1 for when you are entering the area, to be collided with and then register you as "inside" the zone. And another with the normals facing inside of the zone, to generate collisions when leaving to register you as entering a new zone (either a new zone of that large polysoup area, or outside. This means you would need a portal set up to register you are leaving portals altogether, maybe given an identifier such as "worldPortal" after the name.)
If I understand how interior portalling is done semi-correctly (and I probably don't :P ) than it should be done similarily. When renderring, check if a portal mesh for each zone is visible, if a portal for the zone is visible, render the objects inside the zone. If not do not render the zone. If we are inside a zone, check if there are any visible portals of other zones (occlusion by other portals wouldn't count, so we can see out our portals and into another) and if so, render them. If the world portal is visible, render stuff outside.
This could also mean you can use any shape for a portal, not just a convex brush. And portals also would not be limited to how many other faces they need to touch, as they don't really register zones spacially, just on exit/enter. You can have a large arch-shapes portal mesh, just a single triangle, a detailed curving door, etc... No idea how hard this would be to implement however.
08/15/2008 (10:42 am)
Bit of an old thread, but I'd really like to see some polysoup portaling.What if we handled it based on entering portals defined for each zone. You would set it up so each mesh had a zone identifier as Jaimi suggests. Something like "hallway zoneArea-1". Than you would have portal meshes defined with a portal and zone identifier. Like "hallway zonePortal-1" where the "zonePortal-1" ties it in with a list of portals for zone-1. Portals should be one sided, with the face normals pointing in the direction the player will be entering from, to register collisions when entering but not leaving. This means that you will need 2 meshes for each portalled area; 1 for when you are entering the area, to be collided with and then register you as "inside" the zone. And another with the normals facing inside of the zone, to generate collisions when leaving to register you as entering a new zone (either a new zone of that large polysoup area, or outside. This means you would need a portal set up to register you are leaving portals altogether, maybe given an identifier such as "worldPortal" after the name.)
If I understand how interior portalling is done semi-correctly (and I probably don't :P ) than it should be done similarily. When renderring, check if a portal mesh for each zone is visible, if a portal for the zone is visible, render the objects inside the zone. If not do not render the zone. If we are inside a zone, check if there are any visible portals of other zones (occlusion by other portals wouldn't count, so we can see out our portals and into another) and if so, render them. If the world portal is visible, render stuff outside.
This could also mean you can use any shape for a portal, not just a convex brush. And portals also would not be limited to how many other faces they need to touch, as they don't really register zones spacially, just on exit/enter. You can have a large arch-shapes portal mesh, just a single triangle, a detailed curving door, etc... No idea how hard this would be to implement however.
#9
I think that portalizing is generally a great idea. But.. it should not be used for interiors only, but throughout the entire engine. Also, it should not impose any requirements for artists, like the current portal placement for difs. Artists already have to work with lots of predefined stuff that alone make my head dizzy - it's not convenient, so why make it even more unfriendly? The predefined naming of objects idea would also go along the same path, and sounds really hacky to me anyway. I like to set up my own naming convention, as I'm sure many other coders do.
What I thought about was that I'd have a grid in the game world, much like the one used in A* algorithms. For these, LOS information would be pre-generated - just like a lightmap, and then used throughout the game for checking visibility. For each grid node, objects that can be seen from that given node would be marked in a grid node matrix. The objects that can be seen from the camera's point of view would be the objects that can be seen from the closest adjacent nodes. For open areas, the grid could be less dense. For places with more objects, it should be more dense.
A problem I see is that the grid should be 3d at least from the deepest point up to the flight ceiling, but density could be tweaked to make it play well.
This LOS map would have it's advantages on the AI side as well. You could generate the LOS matrix at first run, or ship with your game. At first try, I'd include only static objects, and handle moving objects separately, so the matrix does not have to be updated at run time.
I think it's not a bad idea. If all you want is speed, I believe this would be a good solution to step in place of the current system.
08/15/2008 (11:26 am)
Here's my idea. It might be utter nonsense, but I decided to say it anyway.I think that portalizing is generally a great idea. But.. it should not be used for interiors only, but throughout the entire engine. Also, it should not impose any requirements for artists, like the current portal placement for difs. Artists already have to work with lots of predefined stuff that alone make my head dizzy - it's not convenient, so why make it even more unfriendly? The predefined naming of objects idea would also go along the same path, and sounds really hacky to me anyway. I like to set up my own naming convention, as I'm sure many other coders do.
What I thought about was that I'd have a grid in the game world, much like the one used in A* algorithms. For these, LOS information would be pre-generated - just like a lightmap, and then used throughout the game for checking visibility. For each grid node, objects that can be seen from that given node would be marked in a grid node matrix. The objects that can be seen from the camera's point of view would be the objects that can be seen from the closest adjacent nodes. For open areas, the grid could be less dense. For places with more objects, it should be more dense.
A problem I see is that the grid should be 3d at least from the deepest point up to the flight ceiling, but density could be tweaked to make it play well.
This LOS map would have it's advantages on the AI side as well. You could generate the LOS matrix at first run, or ship with your game. At first try, I'd include only static objects, and handle moving objects separately, so the matrix does not have to be updated at run time.
I think it's not a bad idea. If all you want is speed, I believe this would be a good solution to step in place of the current system.
Associate Matt Fairfax
PopCap
We are still way on the research side of things when it comes to "portalizing" an arbitrary polysoup model. One of the main reasons DIF type geometry is still in use (even in UT3) is that it makes zoning sections of geometry a mostly automatic process (having to hand place a handful of portals and anti-portals) because it defines mathematically sealed geometric nodes (via BSP).
With an arbitrary set of polygons it is a *lot* harder to figure out what belongs in what zone automatically (a single tiny "hole" in the geometry can "flood" all of the geometry and make it all part of the same zone). This means that the burden is then pushed over onto the artist who then has to hand "tag" all of the polygons that exist in each zone or to wrap geometry in "zone brushes" or the like. Definitely not fun or sexy.
This doesn't even touch on the challenge of figuring out what zone can see what zone and which zone the Player is in. This is another thing that the convex nature of DIF geometry makes fast and easy but doesn't translate well over into a pure polysoup environment.
There are other algorithms that we are exploring for better managing visibility occlusion (adaptive quadtrees, kd-trees, strict grids, etc) but we are still a ways off from those being a wholesale replacement for the DIF style zoning.
However, I am curious to get some feedback. If you as an artist had to hand define which polygons belong in which zone, how would you want to go about that? Select a group of polygons in Max or Maya and assign a zone property to them or apply a special texture to them (in something other than the diffuse map channel)? Wrap the geometry in large convex zone volumes? How would you define connectivity between the zones (portals)?