raytracing is cool and nice and all, and just needs hw support. 

BlackDog

That may be missing the point somewhat. Realtime ray tracing would lead to a very unified looking world where everything is lit in exactly the same way, every reacts properly to lights, etc. It would lead to more immersion which I think would be hard to argue against as a negative. 

There's nothing to stop rasterising hardware from using a unified lighting model. See Doom 3 and Stalker.

Intel is pushing raytracing because they'd really love to sell a bunch of expensive hardware, and they can't compete with GPU performance and quality on traditional rasterising tasks. That shows very clearly in these shots: there's flat shading on the models, crappy texture filtering, terrible performance, and pathetic resolution.

There's also shiny things. Well, colour me unimpressed. 

 

"There's nothing to stop rasterising hardware from using a unified lighting model. See Doom 3 and Stalker."

Ray tracing can bounce light. No current real time engine bounces light. And I will all but guarantee that Doom3 and STALKER are using lightmaps in many areas.

"That shows very clearly in these shots: there's flat shading on the models, crappy texture filtering, terrible performance, and pathetic resolution. "

Eh, that's art assets that were designed for a completely different lighting model. Once the technology is more solidified a killer art team would make it look great. 

I'm not getting into this discussion cause I have no clue, but having gone through most of the Doom3 source maps, no it does not use lightmaps. It actually takes some hacking about with the shaders to even get lightmaps in. 

Doom 3 was completely unified and realtime. Stalker used lightmaps on the world, but for occlusion and not lighting. It also implemented a limited form of bounced lighting, by the way. :)

As for the assets, I wonder if they aren't normalmapped in those shots because of issues getting the shading right or because of the extra performance hit (hgh quality texturing is expensive in a raytracer). 

It'd be awesome if doom3 had lightmap support of some sort. 

gaytracing is so far behind its not funny 

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.