At the weekend, I downloaded and tried out every demo nVidia have ever 
made. (Well, except for the first one, which wouldn't download. And the 
last few, which require a GeForce 8 series.)

The first one was literally a crystal ball. In other words, they were 
showing off using environment mapping to simulate reflection. Hmm. Oh 
well, it does say "Requires GeForce 2 or better"...

Anyway, actually most of the demos were pretty unimpressive. I mean, I'm 
sure they're technically quite advanced. But not much fun to look at.

It wasn't until I reached "Dawn" that I was impressed. That's one pretty 
impressive fairy. (Um... and the reason she's wearing almost nothing 
is...? Hmm, I wonder who their target demographic is? *wink*) Her sister 
"Dusk" is impressive too.

And then we have "Nalu", the mermaid. Fairly technically-impressive, if 
a little uninteresting. (She doesn't really "do" much.) Being 
underwater, the skin tones don't seem quite so "wow!", if you see what I 
mean.

Well anyway, the thing that really blew me away was "Luna and the 
Occular Oracle". I mean... woah. 0_0 Watch it and you'll see what I 
mean. Graphically it's fairly impressive stuff. But scenematically... 
Seriously, WHAT THE HELL where these guys smoking when they came up with 
this stuff?? It's like a far-out acid trip or something... wow. Just 
wow. Oh, yeah, and the graphics are fairly impressive. But that's not 
what I was most looking at... heh.

Oh, and now half the demos won't uninstall cleanly. But then, a few of 
them wouldn't run properly in the first place. In general, all the demos 
seemed pretty buggy. Hmm... great advert!

Post a reply to this message

Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it 
manages to do that in realtime...

Post a reply to this message

Do these demos work in ATI cards, or do they have special code which
checks the type of card you have and refuses to run if you don't have
an nvidia one?-)

-- 
                                                          - Warp

Post a reply to this message

"Orchid XP v7" wrote:
> Seriously, WHAT THE HELL where these guys smoking when they came up with 
> this stuff?? It's like a far-out acid trip or something... wow. Just wow. 
> Oh, yeah, and the graphics are fairly impressive. But that's not what I 
> was most looking at... heh.

Nice, but you need to have a look at demos not made by companies.

For a real far-out acid trip (and the best demo I've ever seen) have a look 
at the Assembly 2007 winner "Lifeforce":
http://www.pouet.net/prod.php?which=31571

Rune

Post a reply to this message

Warp nous apporta ses lumieres en ce 2007/10/29 16:10:
>   Do these demos work in ATI cards, or do they have special code which
> checks the type of card you have and refuses to run if you don't have
> an nvidia one?-)
> 
They will probably install and run, but also, probably, with deliberately
cripled performances.
A dirty trick by those making the demos (independent from where they come from):
Let install on the concurent maker's card, but disable some features and replace
others with some DEoptimised versions that deliberately run slower.

To get the real results, you need to use demos and benchmarks by independant
devlopers, and hope that your drivers don't have special codes that lowers the
settings like resolution, polygon count and colour depth, to artificialy make
the benchmark run faster. nVidia DID use that dirty trick, and there is no proof
that ATI used it or not at this time.

-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may cause pregnancy.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> To get the real results, you need to use demos and benchmarks by independant
> devlopers, and hope that your drivers don't have special codes that lowers the
> settings like resolution, polygon count and colour depth, to artificialy make
> the benchmark run faster. nVidia DID use that dirty trick, and there is no proof
> that ATI used it or not at this time.

  You mean that nvidia deliberately put some code in their display driver
that detected that you are running, for example, 3DMark, and if so it has
a special code which converts the triangle meshes given by 3DMark to the
driver to ones with less polygons so that the graphics card will appear
to run faster than it really would?

  I suppose there's no way for a program to detect such trickery...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   You mean that nvidia deliberately put some code in their display driver
> that detected that you are running, for example, 3DMark, and if so it has
> a special code which converts the triangle meshes given by 3DMark to the
> driver to ones with less polygons so that the graphics card will appear
> to run faster than it really would?

Yep!  And you wonder why video drivers under Windows crash the system so 
often.

They also tend to do stuff like notice they're being tested by microsoft 
for approval and stop skipping steps they don't think they "really" 
need, but which they normally skip in order to get better performance at 
the expense of correct results.

I've seen it done with other programs, too, like C compilers noticing 
they're compiling SPECmark suites and such.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Yep!  And you wonder why video drivers under Windows crash the system so 
> often.

  And this isn't illegal? Doesn't it fall into something like
http://en.wikipedia.org/wiki/False_advertising

  I suppose the law will always be behind technology.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   And this isn't illegal? Doesn't it fall into something like
> http://en.wikipedia.org/wiki/False_advertising

Depends what you advertise, I suppose. "Passed the WHDL tests" is 
correct, after all. :-)

But yah, I guess if you really wanted to sue someone, you'd have a case. 
You might not win, but you'd have a case.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote

>   And this isn't illegal? Doesn't it fall into something like
> http://en.wikipedia.org/wiki/False_advertising

It's a complicated matter. Systems tailoring their behaviour to running
applications can have a perfectly valid reason. Sometimes, OS's and drivers
will do that to enable older applications that used, let's say,
unconventional or undocumented behaviour, to keep functioning. MS goes to
great lengths to accomodate badly written applications to maintain backwards
compatibility. Graphics card drivers work closely with major games and CAD
application vendors to maximize their performance, which benefits both
parties. So, a driver reconfiguring itself to maximize performance of CATIA
is not much different than a driver doing the same for 3DMark. Why should a
graphics driver optimized for many such applications let itself be
underspec'd through a synthetic benchmark, if it can help it?

Post a reply to this message

somebody <x### [at] ycom> wrote:
> So, a driver reconfiguring itself to maximize performance of CATIA
> is not much different than a driver doing the same for 3DMark. Why should a
> graphics driver optimized for many such applications let itself be
> underspec'd through a synthetic benchmark, if it can help it?

  Performing application-specific optimizations which result in the exact
same images being produced faster is completely different from producing
images of lower quality faster.

  You'd agree that if the driver detects that 3DMark is being run and
then just presents a black screen and gives a score of 10000 frames per
second, that's not an acceptable result. The speed is staggering, but
obviously unacceptable because the visual result is not acceptable.

  Why would the driver artificially reducing the number of polygons (thus
resulting in a poorer-quality image) just to get a higher benchmark score
be any more acceptable than the black-screen extreme example?

  Or think about it like this: Imagine that a benchmark tests how fast
the graphics card can render using 4x antialiasing. The driver detects
this and artificially turns on 2x antialiasing instead, in order to score
better. This is obviously unacceptable.

-- 
                                                          - Warp

Post a reply to this message

Warp nous apporta ses lumieres en ce 2007/10/29 19:16:
> Alain <ele### [at] netscapenet> wrote:
>> To get the real results, you need to use demos and benchmarks by independant
>> devlopers, and hope that your drivers don't have special codes that lowers the
>> settings like resolution, polygon count and colour depth, to artificialy make
>> the benchmark run faster. nVidia DID use that dirty trick, and there is no proof
>> that ATI used it or not at this time.
> 
>   You mean that nvidia deliberately put some code in their display driver
> that detected that you are running, for example, 3DMark, and if so it has
> a special code which converts the triangle meshes given by 3DMark to the
> driver to ones with less polygons so that the graphics card will appear
> to run faster than it really would?
> 
>   I suppose there's no way for a program to detect such trickery...
> 
What it does is reset the benchmark parameters to some lower ones when the 
actual benchmark starts, then set them back to the selected values on exit.
Result: you get a display that say that you used parameter set X, but the test 
was performed with parameters X/2.
Things that where done:
- changing the colour depth from 32 to 16 bits.
- changing the detail level from "High" to "Medium" or even "Low".
- turning fog off.
- reducing the Z-buffer depth.
- reducing the particles count.
- turning antialiasing off.
- reducing textures quality from "High" to "Medium", "Normal" or "Low".
- turning 3linear interpolation off.
- reduce the lights number.
...and some others...

You mention 3DMark, and it's exactly the first they targetted. They got caught. 
They got sued, and LOST. 3DMark coutered by using name randomization of the 
programm and all of it's components, folders and registry entries. Then every 
other benchmarks makers followed. Net result: nVidia's results droped, sometimes 
by an order of magnitude, around 10 to 30 times slower in some cases!
Think about boasting a 240+ FPS in a mark, then seeing that drop to around 12~17 
FPS after your hack got negated!

-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may make you think you are whispering when 
you are not.

Post a reply to this message

Alain wrote:

> They will probably install and run, but also, probably, with deliberately
> cripled performances.
> A dirty trick by those making the demos (independent from where they 
> come from):
> Let install on the concurent maker's card, but disable some features and 
> replace
> others with some DEoptimised versions that deliberately run slower.

Yeah, that wouldn't surprise me.

> To get the real results, you need to use demos and benchmarks by 
> independant
> devlopers, and hope that your drivers don't have special codes that 
> lowers the
> settings like resolution, polygon count and colour depth, to artificialy 
> make
> the benchmark run faster. nVidia DID use that dirty trick, and there is 
> no proof
> that ATI used it or not at this time.

Um... lower the polygon count? That sounds like a *highly* nontrivial 
task. Arguably more work than actually rendering all the polygons. :-P

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Um... lower the polygon count? That sounds like a *highly* nontrivial 
> task. Arguably more work than actually rendering all the polygons. :-P

  Not if the driver has code specifically designed for the specific
triangle mesh the benchmark program send it. It can simply have some
kind of lookup table or something which substitutes some of the triangles
with other (fewer) triangles.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Um... lower the polygon count? That sounds like a *highly* nontrivial 
>> task. Arguably more work than actually rendering all the polygons. :-P
> 
>   Not if the driver has code specifically designed for the specific
> triangle mesh the benchmark program send it. It can simply have some
> kind of lookup table or something which substitutes some of the triangles
> with other (fewer) triangles.

...hmm, so *that* is why the nVidia video driver is over 200 MB...

(Seriously, are you NUTS?! Most drivers are about 20 KB.)

Post a reply to this message

Darren New wrote:

> Yep!  And you wonder why video drivers under Windows crash the system so 
> often.

Uh... do they?

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> (Seriously, are you NUTS?! Most drivers are about 20 KB.)

  You can fit quite a lot of things into 20 kB. Just take a look at
some good 4 kB demos.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 wrote:
> Darren New wrote:
> 
>> Yep!  And you wonder why video drivers under Windows crash the system 
>> so often.
> 
> Uh... do they?

Well, relatively often, yes, compared to most other stuff.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New wrote:
> Orchid XP v7 wrote:
>> Darren New wrote:
>>
>>> Yep!  And you wonder why video drivers under Windows crash the system 
>>> so often.
>>
>> Uh... do they?
> 
> Well, relatively often, yes, compared to most other stuff.

Not a phenominon I've ever experienced, but anyway...

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
> 
>   You can fit quite a lot of things into 20 kB. Just take a look at
> some good 4 kB demos.

I'll bet you can. Games programmers used to do it back when computers 
only had that much RAM...

Although I'd think lower resolution polygon meshes for 27 different 
games and benchmarks does not belong to "the set of all things that can 
fit into 20 KB". ;-)

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Although I'd think lower resolution polygon meshes for 27 different 
> games and benchmarks does not belong to "the set of all things that can 
> fit into 20 KB". ;-)

  It doesn't need to store the lower resolution meshes. It just needs to
store the logic to do reverse-subdivision of the meshes.

-- 
                                                          - Warp

Post a reply to this message

On Wed, 31 Oct 2007 20:58:11 +0000, Orchid XP v7 wrote:

> Darren New wrote:
>> Orchid XP v7 wrote:
>>> Darren New wrote:
>>>
>>>> Yep!  And you wonder why video drivers under Windows crash the system
>>>> so often.
>>>
>>> Uh... do they?
>> 
>> Well, relatively often, yes, compared to most other stuff.
> 
> Not a phenominon I've ever experienced, but anyway...

In one set of equipment we used to deliver courses on, we had Dell C610 
laptops and Dell C640 laptops.  Video cards were identical in the 
systems, according to the specs (same chipset, same amount of memory, 
same everything).  For non-Windows OSes, they worked just great - you 
could use an image developed on a 610 on a 640 and vice version.

For Windows, you had to install a *different* video driver, even though 
the card was identical - even at the BIOS and firmware level (I checked 
everything I could to find out what was different).

Yet consistently, if you used the 610's driver on the 640 (or vice-
versa), the video came up 16-colour 640x480 VGA, refused to change, and 
left alone long enough, the driver would apparently eat itself and blow 
the machine up - to the point a reimage was often needed.

One of the more bizzare problems I ever saw.  A Dell IT technician in one 
of my classes couldn't even tell me why the driver was different or why 
it didn't do what it was supposed to do (ie, work).

Jim

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/10/30 16:41:
> Alain wrote:
> 
>> They will probably install and run, but also, probably, with deliberately
>> cripled performances.
>> A dirty trick by those making the demos (independent from where they 
>> come from):
>> Let install on the concurent maker's card, but disable some features 
>> and replace
>> others with some DEoptimised versions that deliberately run slower.
> 
> Yeah, that wouldn't surprise me.
> 
>> To get the real results, you need to use demos and benchmarks by 
>> independant
>> devlopers, and hope that your drivers don't have special codes that 
>> lowers the
>> settings like resolution, polygon count and colour depth, to 
>> artificialy make
>> the benchmark run faster. nVidia DID use that dirty trick, and there 
>> is no proof
>> that ATI used it or not at this time.
> 
> Um... lower the polygon count? That sounds like a *highly* nontrivial 
> task. Arguably more work than actually rendering all the polygons. :-P

Not at all! The benchmark programm already have several quality levels, 
including various mesh resolutions.
What you do, is to dynamicaly reset the relevant parameter of the benchmark to a 
lower setting after the user have set it and hit the StartBenchmark button, but 
before the benchmark have realy begun. Then, after the benchmark have finished, 
you set it back to the user selected value.
The net result: artificialy inflated FPS count!

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever brought your 
computer to its knees by mistakenly launching 64 simultaneous frames to be 
traced, while trying to maximizing the benefits of parallelizing them.
Carsten Whimster

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/10/30 17:58:
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> Um... lower the polygon count? That sounds like a *highly* nontrivial 
>>> task. Arguably more work than actually rendering all the polygons. :-P
>>
>>   Not if the driver has code specifically designed for the specific
>> triangle mesh the benchmark program send it. It can simply have some
>> kind of lookup table or something which substitutes some of the triangles
>> with other (fewer) triangles.
> 
> ...hmm, so *that* is why the nVidia video driver is over 200 MB...
> 
> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
ONLY 20Kb??? I only once had video drivers under 500Kb! This was under Win 3.1 
for an old PCI Trident VGA adaptor, the only and last drivers I ever got that 
fit on a single floppy. The Win 95 drivers for that same card needed 2 floppys. 
  My current ATI drivers installation package is about 14.5 Mb.
Just take a look on both nVidia and ATI web sites, drivers downloads section.

-- 
Alain
-------------------------------------------------
As the shepherd said: If in doubt get the flock out!

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/10/31 16:59:
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> (Seriously, are you NUTS?! Most drivers are about 20 KB.)
>>
>>   You can fit quite a lot of things into 20 kB. Just take a look at
>> some good 4 kB demos.
> 
> I'll bet you can. Games programmers used to do it back when computers 
> only had that much RAM...
> 
> Although I'd think lower resolution polygon meshes for 27 different 
> games and benchmarks does not belong to "the set of all things that can 
> fit into 20 KB". ;-)
WHO said that you need to store the alternate meshes? You don't need to do that 
when the benchmark already contain the lower resolution meshes.
Benchmarks, and several games, often offer several mesh quality. You only need 
to intercept or change the reference that is used to point to the lower 
resolution mesh that is already provided.
One of the ways that the cheats where discovered was by running the benchmarks 
at the two lowest settings available and realise that they return exactly the 
SAME results: The second lowest get degraded to the lowest setting, but the 
lowest settings CAN'T be lowered to anything lower! But, almost nobody ever try 
those low settings.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when someone shows you a photograph of 
their new rough-slate kitchen floor and you say "nice normals".
     -- Tom Melly

Post a reply to this message

Alain wrote:

> WHO said that you need to store the alternate meshes?

That would be Warp. ;-)

> You don't need to 
> do that when the benchmark already contain the lower resolution meshes.
> Benchmarks, and several games, often offer several mesh quality. You 
> only need to intercept or change the reference that is used to point to 
> the lower resolution mesh that is already provided.

Mmm. Devious...

> One of the ways that the cheats where discovered was by running the 
> benchmarks at the two lowest settings available and realise that they 
> return exactly the SAME results: The second lowest get degraded to the 
> lowest setting, but the lowest settings CAN'T be lowered to anything 
> lower! But, almost nobody ever try those low settings.

...or it could simply indicate that the bottleneck isn't the GPU?

(I've seen a huge number of SLI benchmarks where the SLI mode is 
*slower* than a single GPU, except at absurd resolution settings.)

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Although I'd think lower resolution polygon meshes for 27 different 
>> games and benchmarks does not belong to "the set of all things that can 
>> fit into 20 KB". ;-)
> 
>   It doesn't need to store the lower resolution meshes. It just needs to
> store the logic to do reverse-subdivision of the meshes.

...and as *I* said originally, "wouldn't that be drastically more work 
than just rendering the high resolution mesh?"

Mesh subdivision being an extremely hard problem, and all that...

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Alain wrote:

> > WHO said that you need to store the alternate meshes?

> That would be Warp. ;-)

  No, I only mentioned lookup tables as being a solution to reducing the
size of known meshes fast.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>>> WHO said that you need to store the alternate meshes?
> 
>> That would be Warp. ;-)
> 
>   No, I only mentioned lookup tables as being a solution to reducing the
> size of known meshes fast.

Ah, OK. I misunderstood then...

Post a reply to this message

> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it 
> manages to do that in realtime...

Using the GPU...  the GPU is good for doing that sort of thing.

Post a reply to this message

> I've seen it done with other programs, too, like C compilers noticing 
> they're compiling SPECmark suites and such.

Even car manufacturers get on this too.  The ECU detects when the car is 
being subject to the standard emissions and economy tests (to provide the 
official figures for fuel consumption and CO2 emmissions) and then 
deliberately runs in some special state to get better results.

Post a reply to this message

>>> Although I'd think lower resolution polygon meshes for 27 different 
>>> games and benchmarks does not belong to "the set of all things that can 
>>> fit into 20 KB". ;-)
>>
>>   It doesn't need to store the lower resolution meshes. It just needs to
>> store the logic to do reverse-subdivision of the meshes.
>
> ...and as *I* said originally, "wouldn't that be drastically more work 
> than just rendering the high resolution mesh?"

You only need to do it once though, not every frame.

> Mesh subdivision being an extremely hard problem, and all that...

Not hard at all (just creating new vertices with weighted proportions of 
neighbours), nor is un-subdividing (just checking pairs of triangles that 
are almost planar to be combined).

Post a reply to this message

scott wrote:
>> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it 
>> manages to do that in realtime...
> 
> Using the GPU...  the GPU is good for doing that sort of thing.

I'm still mystified (get it?) as to how it manages to render with 
absolutely no visible grain of any kind to it. Even POV-Ray struggles to 
do that given many *days* of rendering time...

Clearly some kind of trick must be involved.

Post a reply to this message

>>> Oh yeah, and "Smoke". Simple little demo, but I have *no clue* how it 
>>> manages to do that in realtime...
>>
>> Using the GPU...  the GPU is good for doing that sort of thing.
>
> I'm still mystified (get it?) as to how it manages to render with 
> absolutely no visible grain of any kind to it. Even POV-Ray struggles to 
> do that given many *days* of rendering time...
>
> Clearly some kind of trick must be involved.

Not really, just utilising the GPU's ability to handle 3D textures and 
smooth blending really efficiently.  Don't forget the GPU version is not 
scattering light like POV does...

This links shows some details about a DX10 smoke simulation, I expect a DX9 
version uses a similar method (probably just not as efficient).

http://developer.download.nvidia.com/presentations/2007/gdc/RealTimeFluids.pdf

Post a reply to this message

scott wrote:

>> I'm still mystified (get it?) as to how it manages to render with 
>> absolutely no visible grain of any kind to it. Even POV-Ray struggles 
>> to do that given many *days* of rendering time...
>>
>> Clearly some kind of trick must be involved.
> 
> Not really, just utilising the GPU's ability to handle 3D textures and 
> smooth blending really efficiently.  Don't forget the GPU version is not 
> scattering light like POV does...

...GPUs can do 3D texturing now?

Post a reply to this message

Orchid XP v7 nous apporta ses lumieres en ce 2007/11/04 12:49:
> scott wrote:
> 
>>> I'm still mystified (get it?) as to how it manages to render with 
>>> absolutely no visible grain of any kind to it. Even POV-Ray struggles 
>>> to do that given many *days* of rendering time...
>>>
>>> Clearly some kind of trick must be involved.
>>
>> Not really, just utilising the GPU's ability to handle 3D textures and 
>> smooth blending really efficiently.  Don't forget the GPU version is 
>> not scattering light like POV does...
> 
> ...GPUs can do 3D texturing now?
Yes, and it's not even a new possibility! My old, totaly obsolete, and presently 
unused, PCI Matrox Mystic was able to do some elementary 3D texturing, just not 
to the same extent as todays cards and at a much lower resolution. It could'nt 
do smooth blending or shading.

-- 
Alain
-------------------------------------------------
A modest man is usually admired; if people ever hear of him.

Post a reply to this message

Alain wrote:

>> ...GPUs can do 3D texturing now?
> Yes, and it's not even a new possibility! My old, totaly obsolete, and 
> presently unused, PCI Matrox Mystic was able to do some elementary 3D 
> texturing, just not to the same extent as todays cards and at a much 
> lower resolution. It could'nt do smooth blending or shading.

Oh, well... In that case, it's "merely" a matter of computing the gas 
physics [to sufficiently believable precision]. That's a much easier task...

Post a reply to this message

>>> I'm still mystified (get it?) as to how it manages to render with 
>>> absolutely no visible grain of any kind to it. Even POV-Ray struggles to 
>>> do that given many *days* of rendering time...
>>>
>>> Clearly some kind of trick must be involved.
>>
>> Not really, just utilising the GPU's ability to handle 3D textures and 
>> smooth blending really efficiently.  Don't forget the GPU version is not 
>> scattering light like POV does...
>
> ...GPUs can do 3D texturing now?

They're just a set of 2D textures, fairly simple to implement even if you 
card doesn't specifically support 3D textures.

The hard-ish bit is how to render them, but again you can just write some 
ray-casting code into a pixel-shader that runs in real-time (as I think that 
link I posted explains).

Post a reply to this message