RE: [Algorithms] portal engines in outdoor environments

[Tom F. <to...@mu...>]

Though this is synchronous - you cannot queue results up, so you need to
wait for the pipe to empty before getting the result, and can't do anything
in the meantime. Which is the whole point of _delayed_ Z-visible - you can
draw a frame with hundreds of objects being vis-checked, and then a frame or
two later you read all those results (while the next frame, with more vis
checks, is being rendered).

Unless you can send multiple vis requests down the pipe and read them as
they come out, you'll be stalling the hardware and software waiting for your
results, which rather removes the point of using it for higher frame rates!

Apart from that, it's the same idea.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Bernd Kreimeier [mailto:bk...@lo...]
> Sent: 18 August 2000 20:31
> To: gda...@li...
> Subject: RE: [Algorithms] portal engines in outdoor environments
> 
> 
> John Ratcliff writes:
>  > If you had the ability to ask questions of the zbuffer 
> like "is this
>  > bounding volume visable?" (yes/no) in an extremely high 
> speed fashion then
>  > you could do gross culling on an object by object basis 
> using the zbuffer
>  > contents during the render stage.  Some of the old 
> spanbuffer software
>  > renderers could do this, because it was a fairly cheap 
> question to ask,
>  > especially relative to the time it took to software render 
> an entire 3d
>  > model.
>  > 
>  > But, since you can't ask zbuffers these kinds of questions 
> it's a moot
>  > point.
> 
> 
> http://oss.sgi.com/projects/ogl-sample/registry/HP/occlusion_test.txt
> 
> Brian Paul mentioned that he is going to add that to Mesa
> using the Glide GR_STATS counters. I have no idea which Win32
> drivers offer this extension.