Re: [Algorithms] portal engines in outdoor environments

[jason w. <jas...@po...>]

> So what you are asking is for results at (2) to affect what is done at (1)
> on the very next triangle. the only way this can be done is to hold the

No.. I was very specific that 'primative' meant a set of triangles, as in a
indexed array, or a higher level surface like a patch (such as the
n-patches). Of course trying to make the ganularity at the triangle level
would fall apart.. there'd be no gain. However, on arrays of traingles, such
as my earlier example of a character behind a wall...

> OK, well there is only the Radeon that does this at the moment. It's cool,
> but it's nowhere near commonplace. And it still requires that the test
> triangles be rasterised - converted into pixel representation. The details
> of Z-testing are not important. The fact that you first have to rasterise
> them is the killer.

Right.. but I'm not talking about rasterizing test triangles, I'm talking
about using a bounding volume directly. There are *much* faster ways to
getting to a conservative test of "will everything within this bounding
region be behind everything already rendered to this screen area." Such a
conservative test need not know the actual z for the entire region, it
merely needs to know the range of z in the bounding primative's screen
region, as well as the range containted in the bounding primative (after
perspective). Although this seems perhaps overly conservative, I think most
games exhibit so much spatial locality that such a test will still have good
gains. You need not even render front->back, merely render world geometry
befor character geometry (a typical fps thing anyhow), and you'll get gains.
Maybe not worth the gates it would take to impliment the feature tho, I'll
grant you that.

> You: draw & test bounding object. Draw real object.
> Me: test previous frame's object results. Draw this frame's low-rez
object.

nope.. What I'm proposing is a hint that can be used to early out or reject
the current triangle array. The hint could even be checked in parellel with
processing the first few verticies of the array to avoid any gaps in the
pipe for when the hint doesn't cull the array.

> Plus, you also had to send down the polygon data for your bounding object,
> while I didn't. It's usually small for a bounding object, but it's not
zero.
>
> [snip stuff that also isn't right, but...]
>
> > You misunderstood.. I never said anything about drawing
> > anything. Just a
> > bounding volume hint, which is a very different thing.
> > There's plenty of
> > existing work for converting a OBB to exact screen regions
> > *very* quickly
> > without resorting to scan conversion/rasterization. We're
> > only interested in
> > conservative values as well, since it's common for a
> > character model to be
> > completely seperate from a set of wall polygons.
>
> OK, if you did this sort of incredibly conservative (i.e. add hardware to
> T&L OBB in some quick but conservative way, find enclosing screen BB, test
> all Z values using some sort of quickie rectangle rasteriser, somehow
> dodging the bullet of concurrent Z-buffer access with polys that are
> currently being rasterised), maybe it would work sometimes. But remember
> that you're finding the screen BB of an OBB. So the area being tested is
> quite big compared to your original shape. And that's still a decent chunk
> of hardware.

Yes, a very large chunk of hardware.. but hey, so far 3dfx and nvidia have
shown no fear of going to some of the largest gate counts ever attempted. I
never said I was sure it was a good tradeoff to impliment, but that I think
that early rejection in rasterization *is* a good thing in the interests of
increased scalability.

> I _still_ don't see what is so bad about adding zero hardware to existing
> chips and using some frame-to-frame coherency.

I never said anything was bad about it.. as an application level scheme
where you know about, plan around it's limits, it should work fine. But it's
not a general purpose extension, like adding early rejection to the hardware
would be. Now, the rejection would have little effect on large classes of
scenes, but on the other hand, 90 of all triangles rendered in the universe
are from quake or a similar game... in other words, the relevant class,
which has lots of spatial coherency, is definately dominate.

> latency is terrible. What you are relying on is a short latency. And in
the

no.. I'm relying on a latency of the delayed z bounds being somewhere on the
scale of a couple 'primatives'.

> This is highly app-specific though - the app can happily modify its
> interpretation of the results based on the above. Whereas if you leave it
> all up to the hardware, it can get very had to get consistent framerates.

true.

> Your method actually _removes_ control from the app. That is not going to
> help to get consistent, smooth framerates - if anything, it will give you
> the opposite.

no.. it can always choose not to give the hints :). However, because the
granularity is finer on hardware rejection, moments when you could get close
to a dropped frame are not frame specific so much as action specific: like a
1000 poly character walks around a corner and becomes visable. But on a
camera cut or teleportation, the hardware rejection can still work, and
still effectively shorten the rendering time of that specific frame.. the
frame2frame cohearency is powerless to do anything until the next frame.

> > Ouch.. hadn't thought much about the driver related issues.
> > However, *if*
> > state was constant accross a primative, it's not a problem.
> > That would be a
> > big issue, but I don't think it's insurmountable.
>
> Except that was one of your supposed "plus" points - that state wouldn't
> have to be changed if the object was rejected!

True.. so it probibly wouldn't help you reduce texture downloads. But then
again, reducing bus traffic isn't the primary goal of this sort of
rejection: it's reducing invisable fill/primative consumption.

> (1) There _is_ early rejection in rasterisation pipes. Hierarchial Z is
> massively cool, but relatively conventional.

Right... I need to go read up on that (one of those things on the list).

And the truely wicked implimentation: use both the app level frame2 frame
coherancy and the hardware rejection :).