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

> >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...
> 
> It takes long enough on an Athlon to solve those things...

Primarily because an Athlon is not designed to solve them. I was 
specifically talking about a hardware solver...no function VM overhead, 
the functions would execute natively, and as much as possible hard-wired 
into the logic circuits. And remember that raytracing doesn't have the 
same kind of CPU constraints as scanlining, it can be made very parallel.


> >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.
> 
> Sure, but people tend to minimise geometry in favour of textures in games. I
> know it's often the other way round on non-PC graphics systems (hence
> OpenGL being caught behind the times when DirectX started supporting all
> these fancy texturing methods), so perhaps a primitive rich card would
> reverse this.

Geometry is minimized because it is expensive, most of it has to be sent 
to the card for each frame. Cheaper geometry == more geometry possible.


> I know, I've used it (and very useful it is too :-) However, isn't
> differencing famously slow?

No. It is slower than a plain primitive, that doesn't automatically mean 
"too slow to be useable".


> Also, wouldn't a differenced object be doing
> calculations for all the empty "subtracted" pixels as well?

No, that's what bounding is for.


> >With a raytracing engine, the sphere would likely be faster than the
> >crossed polygons.
> 
> I've no idea whether that's true, but I imagine it's unlikely to be true
> with a volumetrically shaded sphere.

Unless you're doing scattering media in the thing, it can be done very 
quickly. If you're doing a simple surface shader, even faster. You're 
picking the slowest possible way to do it with raytracing and comparing 
it to the fastest possible scanlining method, which is ridiculous.


> >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.
> 
> Aren't atmosphere/volumetric effects often faster with scanline methods (I
> don't know)?

You can fake them quickly using multiple layers of transparent surfaces, 
but getting anything realistic is nearly impossible and you can fake 
them exactly the same way with raytracing. Again, a hardware volume 
evaluator might speed things up greatly.


> They usually do, because the programmers know what sort of minimum memory
> requirements on the card they're prepared to tolerate. When they don't, you
> really notice. However, using predominantly procedural shaders you throw
> the bottleneck on the card's processor, and card memory is cheaper.

You can't keep all the data on the card, a lot of it has to be sent 
every frame. Bus bandwidth is considerably more expensive than card 
memory and more limited than processor power. You could reduce memory, 
use the extra space for some additional raytracer processors, and still 
have a card capable of far more geometry and more realistic rendering at 
perfectly reasonable frame rates.

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