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

> Christopher James Huff wrote:
> >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.
> 
> Complexity (and so cost) of the card. And the primitives that the 3D API
> gives you are not necessarily the same as the primitives that get passed to
> the card (for instance, DirectX now deals in pixel-sized triangles instead
> of points, and seems to have done away with the 2D DirectDraw stuff).


> >And utilities to make disks, cylinders, spheres,
> >other quadrics, NURBSs, etc...though those are tessellated. GLUT even
> >includes a *teapot* primitive!)
> 
> The card isn't going to see any of these.

True, as I said, they were reduced to triangles. The API could probably 
hook up to built-in primitives if they were available, though.


> Nobody will use the raytracing card for games if the quality gain is
> insufficient given the speed drop. I (emph.) assume that there will be a
> speed drop because I have seen many real-time scanline-based engines that
> didn't use a 3D card. I have seen one real-time raytracer, and that was one
> of the highly hand-optimised demos that used to be popular in the '90s. The
> resolution was very low, the framerate was very low, and the reflection at
> that resolution was indistinguishable from a reflection map. I would be
> very happy for someone to prove me wrong with a realtime raytracer that can
> compete on equal terms with a good realtime scanline renderer (in software,
> of course - no 3D accelerator).

Real-time involves several simplifications in computation and geometry, 
which does push the advantage to scanline. But do you need 200FPS? If 
the raytracing card is *fast enough*, its advantages could outweigh 
those of a scanline card.
(There was some RTRT...Real Time Ray-Tracing...demo called something 
like Heaven 7, you may want to look at it. It was quite impressive on my 
PC.)


> I don't see a single box convincing anyone nowadays. You must use groups of
> them, just as you must use groups of triangles to resemble anything useful.
> And triangles certainly have their uses - what about terrain?

I didn't say they were useless. Triangles are definitely useful for 
things like terrain, though I wonder if a hardware isosurface solver 
could compete...
And the advantage of a box is memory: one box takes up less memory than 
one triangle. You *can* use groups of them, nobody has said you would be 
limited to single primitives.


> I think the ability to deform/split up objects in realtime using a triangle
> mesh has quite a few advantages in games. Can you explode a box? Not as
> easily as you can explode a few triangles. If you model an object using
> more and more complex primitives, you necessarily have problems if at some
> point you want to treat the object as a collection of smaller items.

There was a POV-Ray include that used CSG to "explode" objects. If that 
method wasn't suitable, an animated mesh would probably be the best way 
to go. Again, I'm not saying meshes are useless, just that there are 
often better things to use.


> >Both can, and there are have been ways to do so for quite some time.
> 
> In a game, an object may be removed at almost any time, either due to player
> action directly or to something else. Surely unpredictable, especially
> given trends towards destroyable/interacting scenery.

This is pretty much irrelevant. I just said you can add and remove 
geometry. What you are talking about would be more switching between 
different models for different frames of the animation.


> But who's going to construct a game with thousands of sphere or box
> primitives but no triangles? Room games maybe, but games in the open or set
> in space? Surely you're not proposing the isosurface as a practical
> realtime primitive shape? :-)

Who said no triangles? "More primitives" != "Ban triangles"!


> Yes, the game I mentioned also predated 3D cards (part of the reason they
> were impelled to try ellipsoids, perhaps). For things like energy bolts, a
> player will usually insufficient time to see the difference between a
> sphere and a couple of crossed texture-mapped polygons (or a more
> complicated model).

With a raytracing engine, the sphere would likely be faster than the 
crossed polygons.


> For blast effects, I have seen textures mapped to a
> sphere used as a kind of blast, and it generally looks terrible IMO. The
> edge is too sharp, too uniform (same problem as in Quake 2-style blasts,
> which were done with a sort of simple polygonal explosion model). I think
> some sort of volumetric method would be far better here. With polygons, you
> can have the procedural shader and a flexible type that doesn't have to
> enforce spherical or elliptical symmetry, or be a closed surface.

I was not talking about texture-mapped spheres. I was specifically 
talking about using procedural shaders: something volumetric or based on 
angle of incidence to the surface, or something more like the glow patch.


> Why? The procedural must be calculated using a (probably) user-specified
> formula for every pixel that uses it. The image map must certainly be
> projected every pixel (a single unchanging operation), but the
> time-consuming step of actually acquiring the bitmap from system memory
> hopefully occurs only once for a scene.

You're assuming all the texture maps and models fit in the card memory. 
Yes, when the image map is already local, using it would be faster than 
all but the simplest shaders. That doesn't mean procedural shaders are 
too slow. If a specific shader is too slow, you use a faster one, maybe 
resorting to an image map if it will do the job and there is memory for 
it.

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