Re: [Algorithms] portal engines in outdoor environments

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

Better would be a pipeline that allows you to specify some sort of simple
bounding volume for each primative (ie, each index array, display list,
whatever). You could build these volumes with no overhead in most games, and
providing hardware with the hint would allow it to estimate if the entire
primative is obscured, in which case it simply skips the entire primative.

This would require finer grained primatives.. which I guess is sort of on
the out in these geforce days... but I do imagine that for arrays of
moderate size, in the 100's of trys, that the driver buffers and is already
looking at the next set. So, it's not exactly a perfect solution, but it
seems a relatively simple feature, and avoids the necessity of a readback to
application level.


I spent a while trying to dream up a good occlusion cull for this sort of
environment... if you know fo the Bath model, that's pretty much my desired
environement situation. View would mostly be on ground or on top of
buildings.. on top of a building looking accross the cityscape is a
pathlogical case that breaks nearly every scheme. Polygon level analytic
solutions aren't even worth thinking about. Some raster based method like
HOM works well in all but the on top of the building situation.. how can you
pick a good set of potencial occluders in that case?

My last thoughts were of using a hash based on a linear regular octree
enumeration, storing a key for each primative. A skip list would be used to
store an index on the keys (if you don't want to support dynamic changes to
the environment, a simpler structure would work). For each frame, cull to
view fustrum, then walk the skiplist in the view in order from near to far,
using a coverage test similar to HOM.. the keys would allow for a fairly
simple seperation test to be built, but I'm not really sure if that would be
faster than just using the key to find screen bounds and check the coverage
buffer.. In my case, each primative was going to be a scalable higher order
surface of some sort, be it SS, bezier patch or VIPM, so the lowest level of
detail would be used to quickly rasterize into the coverage buffer. The
coverage buffer would probibly be somewhere around 1/4th the display
resolution. Allthough it would be possible for improper rejections to happen
in this case due to the resolution and geometric error, I can live with some
visability errors on the order of 4 pixels.

Thinking back on it now, I think for my situation moving to a geomtry rep
that has some explicit idea of what's solid in the environement, like
mathews sloppy internal occtree. I've been thinking more about image based
geometry representations as well, and have a fuzzy feeling there's some nice
structure out there that lends itself to both.