In article <web.3eddb93bc1329458541c87100@news.povray.org>,
 "Tom York" <tom### [at] compsocmanacuk> wrote:

> 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.

And why is being able to manufacture things out of many shapes worse 
than only having one shape to use?
(Actually, more than one shape, at least in OpenGL: points, lines, 
line-loop, line-strip, triangles, triangle-strip, triangle-fan, quads, 
quad-strip, polygon. And utilities to make disks, cylinders, spheres, 
other quadrics, NURBSs, etc...though those are tessellated. GLUT even 
includes a *teapot* primitive!) 


> Nobody is going to bother with perfect spheres if conventional
> triangle-based characters slow to a comparative crawl.

Nobody will use the faster option if the slower option is slower? Or 
nobody will use the raytracing card if it is slower, even if it gives 
better quality?


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

Well, a triangle doesn't model anything in the real world, you need at 
least 4 of them to get a decent approximation of a real-world object, 
and you don't see many tetrahedrons lying around. There are many things 
that a box models quite closely, to a level that would be invisible on a 
typical camera image with comparable resolution.


> 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).

Both can, and there are have been ways to do so for quite some time. The 
difference is that a few thousand primitives can be stored in the space 
of a few thousand triangle mesh.


> 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.

Marathon 1, an old Mac first-person shooter, had some left-over bits and 
pieces for a sphere renderer in its code...wasn't ever used in the game, 
though, and this predated 3D accelerator cards for home computers. But 
why couldn't a game benefit from a sphere primitive? With procedural 
shaders, you could do a lot with a sphere, like virtually any kind of 
energy bolt or blast effect. With more complex CSG available, you could 
build a complex room with primitives and procedural shaders and still 
have space available on the card for character meshes and skins.


> 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.

That is the primary problem: R&D would cost money and resources that 
could be used on a better but more conventional card, and at release 
there would be nobody ready to make use of the card, and no guarantee 
that there ever would be. It requires a card supporting those features, 
software to use the new features of the card, and game designers to use 
the new features of the software.


> 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.

There is no limit on how long they can take, but that doesn't mean they 
are too slow to be useful. Dedicated hardware should be able to evaluate 
procedural textures extremely quickly, more quickly than an image map if 
it has to drag the image data back from main memory. Here you have that 
size issue again: image maps are big, and video card memory is limited, 
so things often have to be shuffled between video card memory and main 
system memory, which is surprisingly slow.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message