i WISH d3 had proper lightmap support. :\
if only to bake on ambient occlusion, ffs.

i'd be more impressed with realtime ambient occlusion, actually....... 

texturing slower in raytracing? why? at first glance, i'd guess you just need a texture lookup for each ray.

The nice thing about raytracing is that there's basically no hacks involved, much unlike rasterizing where everything is one giant hack ;)

global illumination raytracing isn't really realtime yet, i think. 

... and thinking "when will this be real time?"

Though I guess original-Myst-level stuff has probably been possible in real time for a while now (though obv. I'm talking about ray tracing, not realMyst :) 

is at least one damn good reason to look forward to the development of raytracing, scalability:

http://www.flipcode.com/archives/Raytracing_Topics_Techniques-Part_1_Introduction.shtml

One document especially grabbed my attention. It's titled: "State-of-the-Art in Interactive Ray Tracing", and was written by Wald & Slusallek. I highly recommend this paper. Basically, it summarizes recent efforts to improve the speed of raytracing, and adds a couple of tricks too. But it starts with a list of benefits of raytracing over rasterization-based algorithms. And one of those benefits is that when you go to extremes, raytracing is actually faster than rasterizing. And they prove it: Imagine a huge scene, consisting of, say, 50 million triangles. Toss it at a recent GeForce with enough memory to store all those triangles, and write down the frame rate. It will be in the vicinity of 2-5. If it isn't, double the triangle count. Now, raytrace the same scene. These guys report 8 frames per second on a dual PIII/800. Make that a quad PIII/800 and the speed doubles. Raytracing scales linearly with processing power, but only logarithmically with scene complexity. 

that... doesn't make sense. that means that with enough processing power, you could make a scene infinitely complex without any difference in performance... 

sentence to mean that the ray tracing algorithms will yield a stable product where the problem of rendering is only proportional to the size of the data set that it is handling. 

One of the latter articles features an easy to fallow explanation of kd-trees. 

in monkey phonetics I trust 

everyone knows raytracing performance is much less dependant on polycount, much more on resolution

so throw 1600x1200 at it and cry 

build ray tracers: Way to embarrass yourself, speeds:

http://www.flipcode.com/archives/Raytracing_Topics_Techniques-Part_4_Spatial_Subdivisions.shtml

The last scene from the previous article (the one with the sphere grid to show off the new refraction code) took almost 9 seconds to render on my pimpy 1.7Ghz Toshiba laptop with 1600x1200 screen (I know resolution has nothing to do with it, but I thought I would mention it anyway). And that's just for simple stuff. Later on we will add area lights, and to test the visibility of those, we will need lots of rays � for each pixel, that is.  

Because AFAIK, speeds is right: Every pixel adds one ray to be traced, so raytracing complexity is very much dependent on resolution. Can someone explain this? 

logarithmic means the time grows slower. It still goes to infinity when the polycount goes to infinity. 

of the advantage in size and speed you obtain when you use vector graphics as opposed to bit map graphics in web apps. The advantage comes from the fact the image is a sheer calculation that scales perfectly with the resolution whereas the bit map is a an indexed means of storage.

The advantage of ray tracing is similar:

http://www.iss.rwth-aachen.de/Projekte/grace/raytracing.html

The results are based upon sheer calculation whereas rasterization relies on spans of texturized pixels. The advantages will be more apparent when mega units of polygons are rendered with surfaces represented by polies instead of textures.

Rather old, but still relevant:

http://graphics.cs.uiuc.edu/~jch/papers/rtqjs.pdf 

are wrong, hence the first site I linked. It does have something to do with it, but that becomes less relevant with larger data streams. 

before I crawl into bed, this is what Bikker has been up to of late:

http://igad.nhtv.nl/~bikker/ 

smooth lighting with raytracing.
I mean if you trace from the eyes and not from the light sources, once you hit the first surface, your beam splits to a million different directions. And then again for the next bounce and then for the next. How much until the ray dies or goes to the sky?
It's a very hard problem and results in ugly and unphysical hacks that produce very stupid looking images. 

Rasterisers texture very quickly because the inner loop is a good match for hardware. Triangles go through the pipeline and wind up on the screen as scanlines, basically two endpoints with some associated attributes (texcoords, vertex colour, etc). Texturing the scanline is just a matter of interpolating those attributes between their two known values, which is very fast. Cache coherency is also good, since two adjacent pixels will be located close in the same texture (mipmapping ensures this).

In comparison when you fire off a ray, the hardware has no idea how that pixel will need to be shaded. 

http://code.google.com/p/quake-gamecube/ 

but that's a large part of raytracing optimisation, making things run in a way that you can use coherency between rays. And, yeah, as long as we don't have gpu like computing power for raytracing... 

Now I ain't much good at the internets, like some of you whizzkids, but does all this technologistic hocus-pocus mean that dem computering games goan be mighty purdy? 

Gameplay'll still suck some dem balls tho. 

"Gameplay'll still suck some dem balls tho."

Well, ray tracing doesn't really affect gameplay unless you're going to argue visibility of enemies in a unified lighting scheme or something. 

Thats cool Spirit!! The screenshot is too dark tho....

Totally ruins everything in my life.... 

but atm raytracing stands no chance for realtime rendering vs "raseterizing", cause the later been advanced by the whole software and hardware industy for the last 10+ years and its not stopping. I think Carmack ok Sweeney, said that, not my words really.

tere is a joke that goes "Ray tracing is the technology of the future and it always will be!"
and in the future we`ll have a nice blend both
but so far there is no reason to get any excited 

It's nice to see research into other areas, that's all. It's not time wasted if something of value is learned - even if that something is that ray tracing isn't currently viable or what-have-you.

Pushing more and more triangles through the pipeline will likely reach a point of diminishing returns.