<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
>From Colin:
>> However it looks like hardware support for Z buffering will take
>> off, cos these days there are always millions of polys on screen
>> at once. Then the chances of obfuscation are pretty good, so
>> the
>> gamble pays off.
>
> Just like PowerVR's gfx chips with tile rendering, which process
> the z-buffering for the screen in small blocks and render only
> what is visible.
Where was I? Suggestions - a good old depth sort from overall
distance from the camera works quite well for space 3D. If you
store a table of square roots for the Pythagoras, it speeds up
nicely (big table, but hell, you'll already be storing perspective
correction tables and SINE tables, so you won't be bothered about
memory).
You could also try doing a view frustum cull beforehand to reduce
the list to just visible objects, or take the easy route and just
make sure the objects are forward of the camera. You count the
T-States and take your choice!
Right now I'm tinkering with adding 'building block' sector coords
to each object, like a vague grid reference. Then you could easily
apply a 'bitmapped' view frustum to search the main area for
potentially visible objects. I'm not convinced yet, but it may
work....
-Tob
