RE: [Algorithms] portal engines in outdoor environments

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

We're talking two or three frames at most, and usually one to two I would
expect. If a device is buffering any more than this, then the display is
going to be lagging beind the input so much that the game becomes very hard
to play (for a good illustration, try running Half-Life in D3D mode on an
nVidia card - grrrrr).

And you always have to render _something_ - that's how you get your
visibility info back! True, you could possibly render using a ZERO:ONE blend
mode, but I don't think it will save you all that much fillrate, and it will
pop in a very grim way.

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

> -----Original Message-----
> From: gl [mailto:gl...@nt...]
> Sent: 18 August 2000 19:28
> To: gda...@li...
> Subject: Re: [Algorithms] portal engines in outdoor environments
> 
> 
> 
> As I understand it, the idea with delayed z-testing is that 
> whilst it's
> horribly slow to get 'did this primitive I just tried to 
> render get totally
> z-rejected?' feedback from the card instantly (due to deep 
> pipelining going
> on), it's reasonable to get that info back a few frames late without
> stalling anything.
> 
> The idea is to have that info determine your objects' LOD, 
> ie. you render
> your object with a low LOD by default, unless you find out 
> that thing is now
> visible, when you can bump up the tri count.  As the data is 
> delayed, there
> will be a change from low to hi LOD, but as we're only 
> talking a few frames
> (I believe), this shouldn't be all that noticable.  Note that 
> you can't
> simply avoid drawing the object, due to the delay - 
> otherwise, it would
> suddenly appear, a few frames later than it should.
> 
> In fact, my contention is that if it's only as little as two or three
> frames, the higher rates you run at, the less significant the 
> delay gets, to
> the point were you probably don't even see the LOD pop, or 
> you might not
> even need to render until you're told it's there.
> 
> Tom, how many frames exactly would we be talking about?
> --
> gl