   Major Portal Rendering Problem
  Hey everyone.  I'm having a big problem with portal rendering.  I understand how portal rendering works, however my major problem is that I do not know how to determine what sectors belong to what portals so that when a portal is visible I know what portal to render based on the cameras position.  I have tried two techiques, one was I used a Solid Node BSP tree to organize a map's geometry then I used bounding boxes to determine what geometry belongs to what portals.  That didn't really work out to well.  The other technique was I took the map's geometry , found the midpoint of each polygon (the polygon's are all quads so I used a customized algorithm for finding the middle), sent a ray from the current polygon to the current portal checking to see if any other polygon is colliding with the ray and I also checked to see if the ray collides with any of the other portals in the map's geometry.  All portals are manually placed into the map/level's geometry and flagged as such using a portal texture.  The second algorithm I believe is messy and was considering optimizing it once it was working reasonably.  Since I have gotten basically no where with these algorithms I was hoping if I could get so help either with correcting the algorithms I have explained or help me with another algorithm.  Any and all help will be extremely helpful. Thank you very much.   
Quote:Original post by darrenc182I do not know how to determine what sectors belong to what portals......All portals are manually placed into the map/level's geometry and flagged as such using a portal texture.In a portal engine, all of space is partitioned into sectors, and when Any sectors meet each other is Always a portal.This basically puts a restriction on the reltationship between portal and sector placement. When you manually place your portals, you need to be careful and not violate this.This implies, that for every manually placed portal, you had better be also manually defining the sector's on each side of it.Your second suggestion with the Ray test, should work. But actually having sectors and portals be created Together is best of all.My solution, was to edit my levels in terms of sectors as the base object, not polyons and portals. ( think the current Industry term for this is 'brush based' editing )so..edit by creating sectors, each sector consists of a default of 6 4sided polys.(their vertices can then be dragged around to get other shapes)To expand the level, a wall of a current sector is selected, and a new sector is extruded from it. This shared wall automatically is flagged as a portal.Polygons are never created directly, they always come as part of a sector.New sectors are always created by growing out of the wall of an older sector, thus portals are always explicitly linked to the two sectors they join.The act of level editing itself, thus automatically defines the portal and sector relationships. With this method no processing step is required (that ray test you need to do)   ;  OK thank you very much for your input.  It has shed tremendous light on this subject.  I will rework the level construction to try and implement this. Thanks again.   ;  in the example i stated above, i was using basically 'cube-like' sector shapesI was hoping that a future version of my project would be more generalized and efficient, allowing for as many polys as you want per sector, so long as they remain convex in shape (convex sectors makes portal-to-portal visiblity checks easy as ... ray test)limiting sectors to only 6 polys each also means lots and lots of sectors, and thus many portals, are needed to get any map complexity... so yeah, freeform sectors are cheaper in that regardjust keep that in mind if you decide to go that route....while i was only using 'cube-ish' sector default shapes (with vertices draggable to get other stuff) that can still be limiting. more developed games using this type of system usually have other primitive sector shapes to work with, box, cylinder, sphere, prism, etc...   ;  If you have Half Life 2 download the Source SDK have a play around with Hammer. It uses brushes etc. if you want to have a look. [smile]   ;  I'm using artist-placed sectors and portals (our levels are polysoup-based). Both are AABBs for now (axis-aligned boxes), but I'll move to OBBs soon. Each sector contains a list of the portals which intersect it, and each portal contains a list of sectors that intersect it. It's a very simple way to build a connectivity graph.   ;  One approach that's slightly labor intensive (and potentially error-prone for non-detail-oriented folks) is to have each sector have a list of portals, each of which specifies a target portal in the target sector.This lets you do poly soup sectors, and doesn't rely on any geometric relations at all.   