Thread: [Algorithms] Portals
Brought to you by:
vexxed72
From: oles <ol...@gs...> - 2001-02-28 10:59:41
|
Hi. Does anyone know where I can find good tutorial/paper/analysis of subject? I doesn't need the ones which explains such basic things as what is portals, when to use them, what is view frustum and how to clip polygon to it. Especially unusefull ones which works on per-poly basis :) The one I need - how efficiently use them in our T&L world, how to deal with 'subdivision multiple times visible' problem, deep analysis of spatial hierrarhies inside each portal, analyse the way volumetric queries may be speeded up, how to automate the portal generation itself, how efficiently combine areas of open visibility(terrain) with closed ones, etc. Thanx a lot. Oles V. Shishkovtsov GSC GameWorld ol...@gs... |
From: Josiah M. <jm...@ma...> - 2002-09-08 03:45:37
|
I am planning on writing an impure portal renderer, and I have been wondering about a couple of things. I have been considering a method of rendering the level, but would like some feedback since it's unconventional, and possibly never done for a good reason that I am not aware of. I would render each sector in back to front order, but right before the sector is rendered I would draw an invisible polygon where the portal between the sectors is. The Idea is that the poly would change the depth buffer so that the wall would not show in the area of the portal. Doing this would save me the hassle of actually making the right geometry for a hole in the wall. I have basically 2 concerns about the approach. First, I am worried that numerical inaccuracy would cause Z-fighting in the portal. I hope that using integers for the level vertices would reduce that problem though. The other obvious concern is that it would bite into my fillrate. Perhaps if there is an option in GL to just render to depth, that would help. I also bet that z-test provides the card with an early out. My second question is perhaps simpler. I was considering using a seperate light map for each sector, as opposed to one global one. It seems that this may be a good idea for large levels that don't fit into a maximum 2048x2048 lightmap. However I think that it may cause wastage of space, and extraneous texture switches. I appreciate any feedback. -------------------------------- Josiah Manson http://www.computer-john.com/hosted/jpc/ |
From: Josiah M. <jm...@ma...> - 2002-09-08 19:44:35
|
That is why the sectors are rendered sorted by depth. Anything that is behind the portal would already have been drawn. If rendering the portal polygon only changes the depth buffer, what was behind would still be visible. It would just make it seem that it is all as close as the portal polygon is at that point. When rendering the actual wall attached to the portal, if the z-test only accepts fragments that are closer, the wall would be occluded by the portal (which still looks like the stuff behind it). ----- Original Message ----- From: "Daniel Renkel" <re...@ce...> To: "Josiah Manson" <jm...@ma...> Sent: Sunday, September 08, 2002 10:35 AM Subject: Re: [Algorithms] Portals > Err Josiah, > > probably i didn't get your point, but rendering a polygon, where your > portal-door is, to the z-buffer would cause any other polygons behind that > portal to be not drawn, wouldn't it ? > so all you would get is rendering all your rooms/sectors back to front but > only seeing the one in the front. > why should you want to do that ? or did i got something completey wrong here > ? > > kind regards, > > daniel 'sirleto' renkel > > re...@ma... > > ----- Original Message ----- > From: "Josiah Manson" <jm...@ma...> > To: "[list] GDAlgorithms" <GDA...@li...> > Sent: Sunday, September 08, 2002 7:45 AM > Subject: [Algorithms] Portals > > > > I am planning on writing an impure portal renderer, and I have been > > wondering about a couple of things. > > > > I have been considering a method of rendering the level, but would like > some > > feedback since it's unconventional, and possibly never done for a good > > reason that I am not aware of. I would render each sector in back to front > > order, but right before the sector is rendered I would draw an invisible > > polygon where the portal between the sectors is. The Idea is that the poly > > would change the depth buffer so that the wall would not show in the area > of > > the portal. Doing this would save me the hassle of actually making the > right > > geometry for a hole in the wall. > > > > I have basically 2 concerns about the approach. First, I am worried that > > numerical inaccuracy would cause Z-fighting in the portal. I hope that > using > > integers for the level vertices would reduce that problem though. > > > > The other obvious concern is that it would bite into my fillrate. Perhaps > if > > there is an option in GL to just render to depth, that would help. I also > > bet that z-test provides the card with an early out. > > > > > > My second question is perhaps simpler. I was considering using a seperate > > light map for each sector, as opposed to one global one. It seems that > this > > may be a good idea for large levels that don't fit into a maximum > 2048x2048 > > lightmap. However I think that it may cause wastage of space, and > > extraneous texture switches. > > > > I appreciate any feedback. > > > > -------------------------------- > > Josiah Manson > > http://www.computer-john.com/hosted/jpc/ > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Jon W. <hp...@mi...> - 2002-09-08 23:21:55
|
If you do this, think carefully about how to render a mesh of an entity that's standing in the doorway, with the center in one of the cells, but extending into the other cell. Cheers, / h+ > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...]On Behalf Of > Josiah Manson > Sent: Sunday, September 08, 2002 2:44 PM > To: [list] GDAlgorithms > Subject: Re: [Algorithms] Portals > > > That is why the sectors are rendered sorted by depth. Anything that is > behind the portal would already have been drawn. If rendering the portal > polygon only changes the depth buffer, what was behind would still be > visible. It would just make it seem that it is all as close as the portal > polygon is at that point. > > When rendering the actual wall attached to the portal, if the z-test only > accepts fragments that are closer, the wall would be occluded by > the portal > (which still looks like the stuff behind it). > > ----- Original Message ----- > From: "Daniel Renkel" <re...@ce...> > To: "Josiah Manson" <jm...@ma...> > Sent: Sunday, September 08, 2002 10:35 AM > Subject: Re: [Algorithms] Portals > > > > Err Josiah, > > > > probably i didn't get your point, but rendering a polygon, where your > > portal-door is, to the z-buffer would cause any other polygons > behind that > > portal to be not drawn, wouldn't it ? > > so all you would get is rendering all your rooms/sectors back > to front but > > only seeing the one in the front. > > why should you want to do that ? or did i got something completey wrong > here > > ? > > > > kind regards, > > > > daniel 'sirleto' renkel > > > > re...@ma... > > > > ----- Original Message ----- > > From: "Josiah Manson" <jm...@ma...> > > To: "[list] GDAlgorithms" <GDA...@li...> > > Sent: Sunday, September 08, 2002 7:45 AM > > Subject: [Algorithms] Portals > > > > > > > I am planning on writing an impure portal renderer, and I have been > > > wondering about a couple of things. > > > > > > I have been considering a method of rendering the level, but > would like > > some > > > feedback since it's unconventional, and possibly never done for a good > > > reason that I am not aware of. I would render each sector in back to > front > > > order, but right before the sector is rendered I would draw > an invisible > > > polygon where the portal between the sectors is. The Idea is that the > poly > > > would change the depth buffer so that the wall would not show in the > area > > of > > > the portal. Doing this would save me the hassle of actually making the > > right > > > geometry for a hole in the wall. > > > > > > I have basically 2 concerns about the approach. First, I am > worried that > > > numerical inaccuracy would cause Z-fighting in the portal. I hope that > > using > > > integers for the level vertices would reduce that problem though. > > > > > > The other obvious concern is that it would bite into my fillrate. > Perhaps > > if > > > there is an option in GL to just render to depth, that would help. I > also > > > bet that z-test provides the card with an early out. > > > > > > > > > My second question is perhaps simpler. I was considering using a > seperate > > > light map for each sector, as opposed to one global one. It seems that > > this > > > may be a good idea for large levels that don't fit into a maximum > > 2048x2048 > > > lightmap. However I think that it may cause wastage of space, and > > > extraneous texture switches. > > > > > > I appreciate any feedback. > > > > > > -------------------------------- > > > Josiah Manson > > > http://www.computer-john.com/hosted/jpc/ > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > cell phone? Get a new here for FREE! > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > _______________________________________________ > > > GDAlgorithms-list mailing list > > > GDA...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Josiah M. <jm...@ma...> - 2002-09-09 01:37:15
|
Correct me if I am wrong, but wouldn't any such object be drawn correctly if you render it before the portal polygon? Now that you bring that up, I bet there is a cool demo or 2 that could use this effect to do cool clipping into an object. You would have to depth sort the tris, but could use any irregular shape you wanted to clip against by doing a GL_GREATER depth test. The critique that I have recieved so far is appreciated, but I am still uneasy about the issues that I originally posted. [Sorry for the extra message Jon] ----- Original Message ----- From: "Jon Watte" <hp...@mi...> To: "Josiah Manson" <jm...@ma...>; "[list] GDAlgorithms" <GDA...@li...> Sent: Sunday, September 08, 2002 4:20 PM Subject: RE: [Algorithms] Portals > > If you do this, think carefully about how to render a mesh of an > entity that's standing in the doorway, with the center in one of > the cells, but extending into the other cell. > > Cheers, > > / h+ > > > -----Original Message----- > > From: gda...@li... > > [mailto:gda...@li...]On Behalf Of > > Josiah Manson > > Sent: Sunday, September 08, 2002 2:44 PM > > To: [list] GDAlgorithms > > Subject: Re: [Algorithms] Portals > > > > > > That is why the sectors are rendered sorted by depth. Anything that is > > behind the portal would already have been drawn. If rendering the portal > > polygon only changes the depth buffer, what was behind would still be > > visible. It would just make it seem that it is all as close as the portal > > polygon is at that point. > > > > When rendering the actual wall attached to the portal, if the z-test only > > accepts fragments that are closer, the wall would be occluded by > > the portal > > (which still looks like the stuff behind it). > > > > ----- Original Message ----- > > From: "Daniel Renkel" <re...@ce...> > > To: "Josiah Manson" <jm...@ma...> > > Sent: Sunday, September 08, 2002 10:35 AM > > Subject: Re: [Algorithms] Portals > > > > > > > Err Josiah, > > > > > > probably i didn't get your point, but rendering a polygon, where your > > > portal-door is, to the z-buffer would cause any other polygons > > behind that > > > portal to be not drawn, wouldn't it ? > > > so all you would get is rendering all your rooms/sectors back > > to front but > > > only seeing the one in the front. > > > why should you want to do that ? or did i got something completey wrong > > here > > > ? > > > > > > kind regards, > > > > > > daniel 'sirleto' renkel > > > > > > re...@ma... > > > > > > ----- Original Message ----- > > > From: "Josiah Manson" <jm...@ma...> > > > To: "[list] GDAlgorithms" <GDA...@li...> > > > Sent: Sunday, September 08, 2002 7:45 AM > > > Subject: [Algorithms] Portals > > > > > > > > > > I am planning on writing an impure portal renderer, and I have been > > > > wondering about a couple of things. > > > > > > > > I have been considering a method of rendering the level, but > > would like > > > some > > > > feedback since it's unconventional, and possibly never done for a good > > > > reason that I am not aware of. I would render each sector in back to > > front > > > > order, but right before the sector is rendered I would draw > > an invisible > > > > polygon where the portal between the sectors is. The Idea is that the > > poly > > > > would change the depth buffer so that the wall would not show in the > > area > > > of > > > > the portal. Doing this would save me the hassle of actually making the > > > right > > > > geometry for a hole in the wall. > > > > > > > > I have basically 2 concerns about the approach. First, I am > > worried that > > > > numerical inaccuracy would cause Z-fighting in the portal. I hope that > > > using > > > > integers for the level vertices would reduce that problem though. > > > > > > > > The other obvious concern is that it would bite into my fillrate. > > Perhaps > > > if > > > > there is an option in GL to just render to depth, that would help. I > > also > > > > bet that z-test provides the card with an early out. > > > > > > > > > > > > My second question is perhaps simpler. I was considering using a > > seperate > > > > light map for each sector, as opposed to one global one. It seems that > > > this > > > > may be a good idea for large levels that don't fit into a maximum > > > 2048x2048 > > > > lightmap. However I think that it may cause wastage of space, and > > > > extraneous texture switches. > > > > > > > > I appreciate any feedback. > > > > > > > > -------------------------------- > > > > Josiah Manson > > > > http://www.computer-john.com/hosted/jpc/ > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > cell phone? Get a new here for FREE! > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > _______________________________________________ > > > > GDAlgorithms-list mailing list > > > > GDA...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > > Archives: > > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > |
From: Josiah M. <jm...@ma...> - 2002-09-09 00:58:09
|
Is that common practice? Is depth buffer inprecision that bad of a problem really? It seems that rendering each sector would require a bunch more overhead to clear the buffer, and to clip every triangle to make sure that it doesn't draw over something that has already been drawn. ----- Original Message ----- From: "Daniel Renkel" <re...@ce...> To: "Josiah Manson" <jm...@ma...> Sent: Sunday, September 08, 2002 2:31 PM Subject: Re: [Algorithms] Portals > ah, > > sorry ... my fault :-) now i got it ... for sure, that would be the exact > thing i would to, too ... having in mind to try some freaking geometry > tricks with this, clearing z every sector-render to spend the precision in a > better range and to have nice things like "portals" that are floating in the > middle of room ... > > why do you think your way is unconventional ? what do you think to be the > conventional way ? > > daniel / sirleto > > re...@ma... > > > ----- Original Message ----- > From: "Josiah Manson" <jm...@ma...> > To: "[list] GDAlgorithms" <GDA...@li...> > Sent: Sunday, September 08, 2002 11:44 PM > Subject: Re: [Algorithms] Portals > > > > That is why the sectors are rendered sorted by depth. Anything that is > > behind the portal would already have been drawn. If rendering the portal > > polygon only changes the depth buffer, what was behind would still be > > visible. It would just make it seem that it is all as close as the portal > > polygon is at that point. > > > > When rendering the actual wall attached to the portal, if the z-test only > > accepts fragments that are closer, the wall would be occluded by the > portal > > (which still looks like the stuff behind it). > > > > ----- Original Message ----- > > From: "Daniel Renkel" <re...@ce...> > > To: "Josiah Manson" <jm...@ma...> > > Sent: Sunday, September 08, 2002 10:35 AM > > Subject: Re: [Algorithms] Portals > > > > > > > Err Josiah, > > > > > > probably i didn't get your point, but rendering a polygon, where your > > > portal-door is, to the z-buffer would cause any other polygons behind > that > > > portal to be not drawn, wouldn't it ? > > > so all you would get is rendering all your rooms/sectors back to front > but > > > only seeing the one in the front. > > > why should you want to do that ? or did i got something completey wrong > > here > > > ? > > > > > > kind regards, > > > > > > daniel 'sirleto' renkel > > > > > > re...@ma... > > > > > > ----- Original Message ----- > > > From: "Josiah Manson" <jm...@ma...> > > > To: "[list] GDAlgorithms" <GDA...@li...> > > > Sent: Sunday, September 08, 2002 7:45 AM > > > Subject: [Algorithms] Portals > > > > > > > > > > I am planning on writing an impure portal renderer, and I have been > > > > wondering about a couple of things. > > > > > > > > I have been considering a method of rendering the level, but would > like > > > some > > > > feedback since it's unconventional, and possibly never done for a good > > > > reason that I am not aware of. I would render each sector in back to > > front > > > > order, but right before the sector is rendered I would draw an > invisible > > > > polygon where the portal between the sectors is. The Idea is that the > > poly > > > > would change the depth buffer so that the wall would not show in the > > area > > > of > > > > the portal. Doing this would save me the hassle of actually making the > > > right > > > > geometry for a hole in the wall. > > > > > > > > I have basically 2 concerns about the approach. First, I am worried > that > > > > numerical inaccuracy would cause Z-fighting in the portal. I hope that > > > using > > > > integers for the level vertices would reduce that problem though. > > > > > > > > The other obvious concern is that it would bite into my fillrate. > > Perhaps > > > if > > > > there is an option in GL to just render to depth, that would help. I > > also > > > > bet that z-test provides the card with an early out. > > > > > > > > > > > > My second question is perhaps simpler. I was considering using a > > seperate > > > > light map for each sector, as opposed to one global one. It seems that > > > this > > > > may be a good idea for large levels that don't fit into a maximum > > > 2048x2048 > > > > lightmap. However I think that it may cause wastage of space, and > > > > extraneous texture switches. > > > > > > > > I appreciate any feedback. > > > > > > > > -------------------------------- > > > > Josiah Manson > > > > http://www.computer-john.com/hosted/jpc/ > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > cell phone? Get a new here for FREE! > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > _______________________________________________ > > > > GDAlgorithms-list mailing list > > > > GDA...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > > Archives: > > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Josiah M. <jm...@ma...> - 2002-09-09 01:19:31
|
You have a point. I don't think that the idea of portals is completely lost though. To get around the problem that you have pointed out, I thought that I would create a sort of "dependency" tree, where the root node contains the sector the camera is in and the initial viewing frustum. I would then add any connected sectors that had a visible portal. When the actual drawing gets done, I would first render any of the other sectors required by the currently rendering sector, and so on. Each sector could tell what is visible inside of it by comparing against the stored frustum. I don't really think that this would add too much processing overhead, but I may be wrong. I am not really sure how this would work for funky portals, like mirrors, but I wasn't planning on supporting anything like that anyhow. ----- Original Message ----- From: "Tobias Karlsson" <tob...@te...> To: "Josiah Manson" <jm...@ma...> Sent: Sunday, September 08, 2002 4:05 PM Subject: Re: [Algorithms] Portals > If you're drawing back-to-front, the whole idea of portals > is gone. Portals are usually used for getting 0 overdraw, > using front-to-back drawing, and frustum-culling. > Ofcourse, you might be thinking of some other use > for portals, but i can't come up with one where you > benefit from back to front drawing... > > ----- Original Message ----- > From: "Josiah Manson" <jm...@ma...> > To: "[list] GDAlgorithms" <GDA...@li...> > Sent: Sunday, September 08, 2002 11:44 PM > Subject: Re: [Algorithms] Portals > > > > That is why the sectors are rendered sorted by depth. Anything that is > > behind the portal would already have been drawn. If rendering the portal > > polygon only changes the depth buffer, what was behind would still be > > visible. It would just make it seem that it is all as close as the portal > > polygon is at that point. > > > > When rendering the actual wall attached to the portal, if the z-test only > > accepts fragments that are closer, the wall would be occluded by the > portal > > (which still looks like the stuff behind it). > > > > ----- Original Message ----- > > From: "Daniel Renkel" <re...@ce...> > > To: "Josiah Manson" <jm...@ma...> > > Sent: Sunday, September 08, 2002 10:35 AM > > Subject: Re: [Algorithms] Portals > > > > > > > Err Josiah, > > > > > > probably i didn't get your point, but rendering a polygon, where your > > > portal-door is, to the z-buffer would cause any other polygons behind > that > > > portal to be not drawn, wouldn't it ? > > > so all you would get is rendering all your rooms/sectors back to front > but > > > only seeing the one in the front. > > > why should you want to do that ? or did i got something completey wrong > > here > > > ? > > > > > > kind regards, > > > > > > daniel 'sirleto' renkel > > > > > > re...@ma... > > > > > > ----- Original Message ----- > > > From: "Josiah Manson" <jm...@ma...> > > > To: "[list] GDAlgorithms" <GDA...@li...> > > > Sent: Sunday, September 08, 2002 7:45 AM > > > Subject: [Algorithms] Portals > > > > > > > > > > I am planning on writing an impure portal renderer, and I have been > > > > wondering about a couple of things. > > > > > > > > I have been considering a method of rendering the level, but would > like > > > some > > > > feedback since it's unconventional, and possibly never done for a good > > > > reason that I am not aware of. I would render each sector in back to > > front > > > > order, but right before the sector is rendered I would draw an > invisible > > > > polygon where the portal between the sectors is. The Idea is that the > > poly > > > > would change the depth buffer so that the wall would not show in the > > area > > > of > > > > the portal. Doing this would save me the hassle of actually making the > > > right > > > > geometry for a hole in the wall. > > > > > > > > I have basically 2 concerns about the approach. First, I am worried > that > > > > numerical inaccuracy would cause Z-fighting in the portal. I hope that > > > using > > > > integers for the level vertices would reduce that problem though. > > > > > > > > The other obvious concern is that it would bite into my fillrate. > > Perhaps > > > if > > > > there is an option in GL to just render to depth, that would help. I > > also > > > > bet that z-test provides the card with an early out. > > > > > > > > > > > > My second question is perhaps simpler. I was considering using a > > seperate > > > > light map for each sector, as opposed to one global one. It seems that > > > this > > > > may be a good idea for large levels that don't fit into a maximum > > > 2048x2048 > > > > lightmap. However I think that it may cause wastage of space, and > > > > extraneous texture switches. > > > > > > > > I appreciate any feedback. > > > > > > > > -------------------------------- > > > > Josiah Manson > > > > http://www.computer-john.com/hosted/jpc/ > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by: OSDN - Tired of that same old > > > > cell phone? Get a new here for FREE! > > > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > > > _______________________________________________ > > > > GDAlgorithms-list mailing list > > > > GDA...@li... > > > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > > > Archives: > > > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |
From: Stephen J B. <sj...@li...> - 2002-09-09 14:03:02
|
On Sat, 7 Sep 2002, Josiah Manson wrote: > I have been considering a method of rendering the level, but would like some > feedback since it's unconventional, and possibly never done for a good > reason that I am not aware of. I would render each sector in back to front > order, but right before the sector is rendered I would draw an invisible > polygon where the portal between the sectors is. The Idea is that the poly > would change the depth buffer so that the wall would not show in the area of > the portal. Doing this would save me the hassle of actually making the right > geometry for a hole in the wall. Will moving objects ever have to move through the doorway? When the Ravenous BugBlatter Beast of Traal is halfway through the door, when would you render him? It would have to be BEFORE you render the portal. You'd better hope he doesn't have any translucent parts that would need to be rendered AFTER the polygon that the portal is cutting a hole in. > The other obvious concern is that it would bite into my fillrate. Perhaps if > there is an option in GL to just render to depth, that would help. I also > bet that z-test provides the card with an early out. You can disable rendering to the colour buffer (glColorMask) and turn off as much OpenGL rendering state as possible...it shouldn't be *too* costly. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Juhana S. <ko...@ni...> - 2005-08-22 13:00:04
|
Hello, and quite shortly now: who invented the portal technique? Seth J. Teller has been mentioned in a tutorial (perhaps at gamasutra). Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software |
From: Ville M. <wi...@hy...> - 2005-08-22 13:06:31
|
Depends on what you mean by the "portal technique". Seth Teller did quite a bit of research on portals in the early 90's. However, the "modern" (real-time) portal approach used in gaming is usually accredited to Luebke and Georges and their paper "Portals & Mirrors: Simple, Fast Evaluation of Potentially Visible Sets". However, I am reasonably sure that similar techniques were already in use in the gaming community at the time that paper came out. -- Ville Miettinen, CTO Hybrid Graphics, Ltd. http://www.hybrid.fi Skype: wili_hybrid, MSN: wilihybrid On 8/22/05 3:59 PM, "Juhana Sadeharju" <ko...@ni...> wrote: > > Hello, and quite shortly now: who invented the portal technique? > Seth J. Teller has been mentioned in a tutorial (perhaps at gamasutra). > > Juhana |
From: Jamie F. <ja...@qu...> - 2005-08-22 13:19:09
|
The quickest of quick googles finds that paper which refers back to Jones in 1971. Jamie Ville Miettinen wrote: > Depends on what you mean by the "portal technique". Seth Teller did quite a > bit of research on portals in the early 90's. However, the "modern" > (real-time) portal approach used in gaming is usually accredited to Luebke > and Georges and their paper "Portals & Mirrors: Simple, Fast Evaluation of > Potentially Visible Sets". However, I am reasonably sure that similar > techniques were already in use in the gaming community at the time that > paper came out. > |