[Algorithms] Re: Portal VS BSP

[Alen L. <ale...@cr...>]

ROTFL! Now we can start over with correct terminology. But looks like we 
have already reached a conclusion. :) 

> I would classify portals as a static visibility
> solution if they are calculated from a static scene (and not some
> component-based thing).

This is like I said in my reply to the original post (Ryan's IIRC): there is 
no clear categorisation defined. Anyway, now that we know what we all 
mean.... 

Things like hierarchical occlusion maps etc are very similar to what we did. 
The distinction is very blurred and it is very hard to tell which algo is 
feasible and which not. They all operate in image space, what is a good 
idea, IMO, as that allows you to get close to the "ideal algorithm" - the 
one based on z-buffer with feedback; I described it a few posts ago. 

For a side note, z-buffer with feedback has some great potentials on newer 
hardware that supports occlusion queries. In some later versions of our 
renderer, we used occlusion queries in hardware where available and it 
allows you to additionally cull all dynamic models in the scene with almost 
perfect precision, and for free. (A colleague of mine is working on a paper 
about that, I think.) 

The only drawback of current occlusion-query-capable hardware is the fact 
that its pipes are too deep. This makes it impractical for portal walking, 
because you have to wait at least till next frame to get feedback (unless 
you want to stall the GPU). The delay is ok for models, which don't have to 
be perfectly temporaly conservative, but would be too noticeable for 
portals. 

<utopia mode (or maybe not)>
If this limitation is overcome, it will be The Visibility Algorithm - silver 
bullet for all VSD problems. We will be able to be only as conservative as 
needed (i.e. per object culling), and achieve perfect visibility detection, 
while spending almost no CPU time (apart for keeping track of the query 
data).
</utopia mode> 

Perhaps we get lucky some day.... ;) 

Cheers,
Alen 


Neil Stewart writes: 

>> Wait a minute... portals vs. PVS vs. dynamic visibility. When 
>> did they multiply? I believe there were only two of those. :) 
>> By dynamic visibility I ment using portals in runtime. I 
>> don't know of any useable zone-based system with runtime 
>> visibility where you don't use portals.
>> What exactly are we talking about here?
> 
> LOL. I thought I knew. ;) 
> 
> By dynamic visibility I was talking about something like dPVS, hierarchical
> occlusion maps and so on, i.e. there is no scene preprocessing. This is what
> I thought you were doing. I would classify portals as a static visibility
> solution if they are calculated from a static scene (and not some
> component-based thing). 
> 
>> What we were using was dynamic visibility based on portals 
>> and with occluders put in the whole soup. So you get occluder 
>> fusion at run time, with little extra costs. What you are 
> 
> Ah, so we were advocating the same kind of thing: portals with occluder
> fusion. Which I think is a pretty good idea. ;) 
> 
> I was only talking about PVS because the original question was "portal vs
> BSP" (actually "portal vs PVS"). Sorry for any confusion. 
> 
> - Neil. 
> 
>  
> 
>  
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188