Patrick Elliott wrote:

>True enough, but in this case I mean 'cheat' as in faking real geometry
>like boxes and spheres using triangles. I consider it a cheat because it
>takes advantage of the existing hardware capability to produce something
>that only looks real by using so many triangles that you can't place
>anything else in the scene with it. That is the nature of most cheats,
>something that looks good enough for you purpose, but doesn't really
>reproduce the result accurately.

You can exactly reproduce a mathematical box with 12 triangles. The sphere
is a better example, but where does this approach end? You end up with a
plethora of "fundamental" objects (including triangles!) to avoid
impersonating one geometry with another. This is great for many purposes
(see: POV), but I assert that it's not too good for games - being able to
manufacture anything out of a single shape (especially one with the
projection properties of a triangle) is valuable.
Nobody is going to bother with perfect spheres if conventional
triangle-based characters slow to a comparative crawl.

As for real geometry, I have yet to see a perfect triangle, sphere or box
in the real world :-)

>True, but some things don't need to be fed back into in continually and
>those bases on primitives would take less room to store, meaning you can
>leave more of them in memory than normal. This should cut in half the
>amount of stuff you have to cram into the card in each frame, possibly
>more.

I don't see why a raytracing card can retain an object but a scanline card
cannot, *if* both know in advance that an object will persist from frame to
frame (which they most likely won't).

Looking at typical objects that appear in games, a fast triangle is very
valuable. There once was a game that built characters from ellipsoids, but
they too are an approximation and the concept could not obviously benefit
from improving system speed. Objects in games are often not simple spheres.

>Think some new cards may use them, but the same issue existed for them as
>for a true card based engine, the methods used to produce them where
>simply too complex to 'fit' in the existing architecture.

I thought some modern cards implement things like pixel shaders, and even
small shading languages, which fit in nicely. I don't think that procedural
textures (or textures generated on the fly) are unique to raytracing, or
are intrinsically harder in scanline than raytracing (or vice versa). I've
seen some raytracers that rely entirely on image mapping.

>Kind of hard to say, since the option isn't exactly common or if it does
>exist is not used from what I have seen.

I think some games companies are still getting used to programmable shaders
on cards (and also have the problem that on some platforms, a lot of cards
are not modern enough to have them). Perhaps that's another point - a new
raytracing card for games would have to be compatible with already-released
games, or nobody would buy it. It would need to support the existing OpenGL
or DirectX interfaces.

Procedural textures (or programmable textures on these cards) are
increasingly useful, but they do take time to compute and hence seem mainly
restricted to special effects. When you need to output 800x600 pixel frames
at >24fps, almost every trick becomes useful.

Post a reply to this message