Wolfenstein Gets Ray Traced

An anonymous reader writes "After showcasing Quake Wars: Ray Traced a few years ago, Intel is now showing their latest graphics research project using Wolfenstein game content. The new and cool special effects are actually displayed on a laptop using a cloud-based gaming approach with servers that have an Intel Knights Ferry card (many-core) inside. Their blog post has a video and screenshots."

Comments

I don't get it

[Yuioup]

Why build a ray tracer into a 4th game after doing it for Q3, Q4 and ET:QW. Why don't they focus on improving already existing raytracing code into the first 3 games.

I donnow but it seems like they're keeping themselves busy for the sake of looking busy.

Y

Re:I don't get it

[pieisgood]

Yeah, this project is simply here to validate itself.

I don't know if that's entirely true though. Carmack talks of slowly integrating raytracing technology into videogames. This research into raytracing in games could prove useful later in videogame development. As I understand most advancements in videogame visuals today are optimizations on old research. So I wouldn't rain on their parade entirely.

Re:I don't get it

[cupantae]

I can't understand why they're not giving people what they want: ray traced Nethack.

Re:I don't get it

[Sigma 7]

You can only do so much raytracing in the original games. For example, Quake doesn't support or include the map information to create visually detailed worlds - after that, you're guessing on how the world should be shown.

Re:I don't get it

[JCZwart]

This is Intel, not Id. It's a tech demo to show off what Intel's technology is capable of. Ray tracing scenes in real time was absolutely unthinkable just a few years back (and honestly I'm quite impressed with what they've achieved here, since ray tracing is about the most expensive (though also most realistic) way to render a scene in 3D).

Re:I don't get it

[hierophanta]

development has always been an iterative process. simply doing it again, sheds light onto what may have been overlooked or glossed over the first (n) times

Re:I don't get it

[Hatta]

This would have been a lot cooler if they had done Wolfenstein 3d instead.

Re:I don't get it

[AragornSonOfArathorn]

I can't understand why they're not giving people what they want: ray traced Nethack.

You can have ray traced nethack. Just print every screen on a laser printer with high-resolution TrueType fonts.

Re:I don't get it

[Phoghat]

The idea is to play a game "in the cloud" so that you can play it on your Atom core Net Book. Still I'll believe it when I see it.

Graphics card are obsolete

[Orphis]

Mom, can I buy a new cloud to play Halo 10 ?

Re:Graphics card are obsolete

[Elektroschock]

Mein Leben!

Re:Graphics card are obsolete

[Tetsujin]

Mom, can I buy a new cloud to play Halo 10 ?

Don't be silly. You can't play Halo on a cloud... it's a Varse-based game! Why don't you play with one of your game dials instead?

Re:Graphics card are obsolete

[Anonymous Coward]

leapen.

Nothing to see here

[dsavi]

It's rendered in the cloud. If they managed to actually get more bang for the buck- i.e. made this run on conventional hardware- Then I'd be interested. They're just doing something that has been done before, albeit maybe not in real time (But you never know, seeing these new OpenCL apps), running it on high-end servers, and piping it into a small laptop. I'm not sure how much of an achievement this is, we've all heard of gaming in the cloud before.

Re:Nothing to see here

[Dthief]

yeah.....but that accent.......doesnt it make you want to buy the brooklyn bridge from him?

Re:Nothing to see here

[AHuxley]

Yes an intel box with many cores for $x00000 would be neat, but shipping it off to a cloud just seems so 'done'.
Anything that moves this tech forward, rather than just another Intel "demo".

Re:Nothing to see here

[kramulous]

How long before that kind of power is available on a single die? Assuming programmers program a cpu with the same mindset people do with the gpu.

Re:Nothing to see here

[Ecuador]

Exactly, using a bunch of servers to run a game on a laptop is neither impressive not new.
Plus, the game looks nothing like Wolfenstein, which by the way used to run fine on my 386SX - no raytracing there of course. Where are the narrow grey or blue stone-walled corridors? And what is all that furniture doing in Castle Wolfenstein?

Re:Nothing to see here

[xtracto]

Exactly, using a bunch of servers to run a game on a laptop is neither impressive not new.
Plus, the game looks nothing like Wolfenstein, which by the way used to run fine on my 386SX - no raytracing there of course. Where are the narrow grey or blue stone-walled corridors? And what is all that furniture doing in Castle Wolfenstein?

Mmm nope you are wrong. You are thinking of Wolfenstein 3D, the game they are presenting is indeed called Wolfenstein.

Re:Nothing to see here

[Ecuador]

That was supposed to be a joke...

Re:Nothing to see here

[V!NCENT]

According to some calculations I have done, based on Intel's roadmap and extending graphs (yes, you may shoot me), one year ago it was about 4-5 years to get the full packages (ambient occlusion and all that) with a single Intel chip.

But looking at more recent data I suggest 3 years before a very expensive desktop computer can render it. Keep in mind: rendering, excluding fluid animations and all that!

Re:Nothing to see here

[V!NCENT]

PS: this is also ignoiring the new effects that will be introduced and especialy HD gaming. Think about 1024*800 res running at 24-30 fps.

So many

[sych]

So... many... triangles!

Re:So many

[BodeNGE]

Oh my god, ... it's full of triangles!

Re:So many

[ciderbrew]

A double triangle what does it mean?

Re:So many

[Anonymous Coward]

it means newfags can't triforce.

Re:So many

[RulerOf]

A double triangle what does it mean?

Fucking triangles! How do they work!?!?!?

A bag of triangles?? I've go so many questions!

Re:So many

[Anonymous Coward]

no, there aren't. that's the whole point of it, duh.

Re:So many

[Rockoon]

This is the true advantages of raytracing. A rasterizer would have to deal with each and every triangle in that chandelier.

Rasterizers scale on O(triangles) while raytracers scale on O(pixels * log triangles). I dont remember if it was Microsoft Research or something out of Intel, but 5 or so years ago they did some scalability testing and concluded that about 1 million polygons was the sweet-spot where raytracing and rasterization were about equal in efficiency using the per iteration constants derived in their testing.

This was based on visible geometry only, so no pretending that the fact that rasterizers can use logarithmic data structures for hidden surface removal, that that makes any bit of difference.

Since then, triangle counts have remained about the same in games (with more per-pixel processing being done to simulate more geometry,) but the number of pixels have quadrupled as higher and higher resolution displays have become common. Yet they are reaching the limits with the fakes that can be done with shaders, and resolution is probably not going to go through another quadrupling, so raytracing really is comming.. just not quite yet.

When the polygon counts do get high enough, there will be no looking back. Raytracing will be here to stay after that because of the way it scales. At 1 million polygons, a raytracer spends 20 iterations per ray cast using a logarithmic structure.. doubling the number of polygons to 2 million only adds 1 more iteration.. or about 5% more processing power required, and doubling again only adds another ~4.5%, and so on.. meanwhile each doubling of polygons on the rasterizer literally doubles the processing power required.

Re:So many

[grumbel]

A rasterizer would have to deal with each and every triangle in that chandelier.

Or it could just do LOD with a geometry shader on the GPU.

When the polygon counts do get high enough, there will be no looking back.

The problem is that you don't just want high polygon counts, but high polygon counts for dynamic objects. And ray tracing itself has its strength in static objects, as soon as stuff moves and deforms, ray tracing runs into quite a few issues, not necessary unsolvable issues, but that demo was rather lacking in that aspect as the particle system looked like complete garbage compared to todays games.

Or to put it another way: The job of a tech demo is to blow me away, not present something that needs a server farm to run and looks worse then a $200 Xbox360.

Re:So many

[Rockoon]

Or it could just do LOD with a geometry shader on the GPU.

LOD doesnt absolve the scaling problem. Lets say you have a system set up for 25% LOD versions of the geometry, but then double the number of polygons in the geometry.. well you have also doubled up the polygons in the LOD versions as well.

Your thinking only applies if "Double Polygons" = "Double-Sized World" ... whereas the study was on the visible geometry itself, which has nothing to do with the size of the world, where "Double Polygons" = "Double Detail"

Game developers no longer worry about the number of polygons "in the world" .. there are plenty of log n algorithms for ignoring that issue (bsp's, quad tree's, and a plethora of other common scene graphs). The issues they face are dealing with the number of polygons "on screen right now" .. There are few unexplored tricks to faking more geometry than is actually there... pixel shaders are more than enough these days to do almost anything you can think of. The techniques are what they are, and each polygon must be visited and sent to the renderer (because its on screen!) and thats why its O(triangles) for rasterization.

The problem is that you don't just want high polygon counts, but high polygon counts for dynamic objects. And ray tracing itself has its strength in static objects, as soon as stuff moves and deforms, ray tracing runs into quite a few issues, not necessary unsolvable issues, but that demo was rather lacking in that aspect as the particle system looked like complete garbage compared to todays games.

They also didnt spend a hundred million making the game. Sure, raytracing has issues... I think the biggest one that you missed is the much higher cost of anti-aliasing.. for rasterizers, anti-aliasing techniques pretty much fall right out of it.. for raytracers they either need to do super-sampling or actually implement a hybrid with cone-tracing for when a ray hits a polygon edge.. (which has its own issues with regard to reflections and refractions, where the size of the cone possibly becomes nearly 360-degrees after a few bounces)

In the end it is inevitable tho, and it is precisely because of how things scale.. for rasterizers every doubling of visible geometry doubles the computational resources required.. but for raytracers increasing geometry can almost be shrugged off as inconsequential... to put this as clear as day, a raytracer spends 20 iterations per ray for a million polygons, and 30 iterations for a billion polygons. A thousand-fold increase in geometry only requires 50% more computational resources. Once we hit that sweet spot where rasterization and raytracing are about equal in performance, it becomes dumb not to start piling on as much geometry as memory permits.

Re:So many

[grumbel]

LOD doesnt absolve the scaling problem. Lets say you have a system set up for 25% LOD versions of the geometry, but then double the number of polygons in the geometry.. well you have also doubled up the polygons in the LOD versions as well.

A LOD only needs enough polygons to look good on screen, if you add more detail that isn't visible from a distance, the LODs polygon count doesn't need to increase at all. In practice this basically means that you only need to render polygons larger then a pixel, as anything subpixel is lost anyway, and if you look at the tech specs of a modern GPU you'll see that they can already render more polygons then you have pixels on the screen.

I think the biggest one that you missed is the much higher cost of anti-aliasing.. for rasterizers, anti-aliasing techniques pretty much fall right out of it..

There are post-processing algorithms for faking anti-aliasing, already used in current day console games. Might not look as pretty as real anti-aliasing, but might be a viable trade-off for raytracing.

for rasterizers every doubling of visible geometry doubles the computational resources required.. but for raytracers increasing geometry can almost be shrugged off as inconsequential...

A raytracer is only fast for static scenes, if you have something dynamic and need to update your space partitioning for the raytracer, the whole O(log n) magic kind of falls apart.

Re:So many

[robthebloke]

> When the polygon counts do get high enough, there will be no looking back.

Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way. The higher the number of polygons in a character, the more time an artist has to spend painting the skin weights and mapping the UV coords. The relationship between the number of polygons and the asset creation time is exponential. Double the poly count, and expect the modelling/uv mapping alone to take 4 or 5 times longer. The time taken for skinning and blend shape authoring is normally an even bigger time increase. The simple fact of the matter is that there are only 1 or 2 games companies on the planet that are big enough to be able to generate assets of that size. Rockstar are probably the best positioned to generate assets of this size, however if GTA4 took 5 years to produce, do you really think they'd be willing to start a GTA title that took 20 years to develop? Because that's effectively what you are assuming they are going to do.....

As GPU performance increases the one thing game developers *wont* be using it for is increased poly counts, because there are other limiting factors that you have conveniently forgotten. Let's take the example of a character made from a 1million vertex mesh (verts are a better metric than polys). We have 3 floats per vertex, 3 floats per normal, 3 floats per bi-normal, and probably 5 UV/colour sets averaging 3 floats per vertex. Then lets be a little bit restrictive and use only 4 skin weights per vertex (1 int + 1 float). All in all that adds up to 32 floats + 4 ints, or 144 bytes per vertex. That's about 137Mb for the geometry data alone. That of course assumes you don't need any padding or alignment in that data (which could increase that size by 30% or so). Add to that the indices for your 1million triangles (3 ints per tri, 12bytes) - another 11Mb or so. Now then. Lets compute our skinning deformation for each vertex. Essentially this is a weighted linear sum of transformed vectors. We have 1 million verts, each with 4 vertex weights. That means we have to transform 4 vertex positions by 4 matrices, and not forgetting that the bi-normals and normals also need to be rotated. That's a total of 12 vector transforms that need to be performed per vertex, and then the result is a weighted sum of those transformed vec3's. Having deformed your million verts, you then need to update your PVS/spatial hierarchy and *then* you can start the rendering phase. The problem with all of this is not GPU/CPU horsepower (we have it in abundance), but it's simply having enough memory available to be able to firstly store the data set, and more importantly it has to be fast enough to keep the CPU/GPUs fed with data during this process. It's that latter part that is the problem right now.

Since raytracing doesn't speed up the geometry deformation problem, it doesn't help with the biggest limiting factor which is memory bandwidth. This is one area where rasterisation wins. Since you have to access every poly anyway, why not render that triangle at the same time? The extra CPU/GPU ops required to do that are effectively free since you are providing a bit more work for the GPU to perform when it would otherwise be waiting for the next triangle to be sent to the cache. Obviously time spent shading the triangles isn't free, however modern GPU's are very good at early rejection, and if you have at least some rudimentary form of PVS and occlusion testing, the problem is largely moot imho.

At least once a month I hear this same tired argument about raytracing, and have done for over a decade now. Raytracing has never beaten reyes in the filmFX industry, and I don't see it ever winning out in the games industry either. ILM/Pixar/Dreamworks/Framestore/MPC have hundreds of thousands of compute nodes available to them, but none of them has been able to get raytracing to a point where the image quality/performance ratio beats r

Re:So many

[Tetsujin]

it means newfags can't triforce.

SIERPINSKI TRIFORCE!

Re:So many

[Tetsujin]

> When the polygon counts do get high enough, there will be no looking back.

Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way. The higher the number of polygons in a character, the more time an artist has to spend painting the skin weights and mapping the UV coords. The relationship between the number of polygons and the asset creation time is exponential. Double the poly count, and expect the modelling/uv mapping alone to take 4 or 5 times longer.

I think the current workflow for creating 3-D graphics for games puts a heavy emphasis on runtime optimization - making the polycount suitable for the hardware and software that will be displaying it. When the hardware is capable of a substantially higher polycount, the workflow will change. More emphasis will be placed on creating high-detail models, with less emphasis on optimizing their topography, and more reliance on automated tools to handle things like polygon layout and UV mapping. The work style will adjust to fit the new hardware capabilities.

Re:So many

[Rockoon]

A LOD only needs enough polygons to look good on screen, if you add more detail that isn't visible from a distance,

The fact that you cant get over this LOD stuff is mind-boggling, but I think I know why. You dont know the difference between a game engine and a renderer. A renderer renders the polygons it is told to render, which is what was under study. All game engines have a renderer behind them, by it OpenGL, DirectX, etc... these API's do not reduce detail/etc.

The research was quite clear. The sweet spot where raytracing (a rendering method, not a game engine) better scalability begins to pass rasterization (a rendering method, not a game engine) is 1 million polygons.

A raytracer is only fast for static scenes, if you have something dynamic and need to update your space partitioning for the raytracer, the whole O(log n) magic kind of falls apart.

We are talking about O(dynamic objects) here, not O(triangles) .. which is why many videos of realtime raytracing since 2007 or so have included .. dynamic scenes .. such as the one linked to in this article .. which I guess you didn't watch.

Re:So many

[Rockoon]

Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way.

Arent you making an assumption here? Most models these days are not generated 1 polygon at a time. They use advanced packages that generate most of the geometry for them, where the modeller's job is more like a supervisor than a carpenter.

Re:So many

[grumbel]

All game engines have a renderer behind them, by it OpenGL, DirectX, etc... these API's do not reduce detail/etc.

So what? That doesn't stop you from using space partitioning, LODs or other tricks. You simply don't need a million polygons to render a round sphere, a geometry shader can do that for you. It would sure be nice if you could, but if given the choice of implementing LOD or throwing away all your graphics hardware and software and doing it all over again in raytracing, I think doing LODs will probably be the better answer for quite a while.

We are talking about O(dynamic objects) here, not O(triangles) .. which is why many videos of realtime raytracing since 2007 or so have included .. dynamic scenes .. such as the one linked to in this article .. which I guess you didn't watch.

We are talking about games here, not about moving a single object around. Games have hundreds of objects and easily thousands of particles flying around all over the place, they also have vertex shader running the bone deformation on every organic looking thing around and a physics engine crumpling your car. That is quite a different thing then having a tech demo where one object gets moved a little a bit.

Re:So many

[Rockoon]

So what? That doesn't stop you from using space partitioning, LODs or other tricks.

You can use them all you want.. it doesnt help even if you originally had 100 million polygons but culled that set down to only 1 million polygons and sent them to the renderer. Thats the number. 1 million to the renderer, which then must render everything its told to render. You dont get to cull the geometry twice.

You continue to fail to make the distinction between a game engine and a renderer. You seem to think that its the renderers job to cull the geometry. Nope. No it isn't. Its the renderers job to render the geometry its told to render. The culling happens elsewhere, and is certainly of great benefit, but has no bearing on the study in question which studied the number of polygons rendered.

We are talking about games here, not about moving a single object around. Games have hundreds of objects and easily thousands of particles flying around all over the place, they also have vertex shader running the bone deformation on every organic looking thing around and a physics engine crumpling your car. That is quite a different thing then having a tech demo where one object gets moved a little a bit.

One object? Looks to me like a few dozen animated soldiers walking around at the beginning, and above the far building where all those soldiers are walking around, a particle effect with what looks like thousands of individual independently moving particles. This is right in the first 30 seconds or so of the video. Perhaps you should actually watch it.

You are also grasping here because you are now trying to invoke larger numbers of objects, but that doesnt help the rasterizer any. The more objects there are, the better raytracing does in comparison at actual rendering. Both engines need to visit each dynamic object each frame and update them, so they are both at O(n) already.

You dont seem to understand runtime complexity either. You are arguing over constants here. If we cared about the constants, we would all be using insertion sort, because it has the cheapest constant. Sure.. for large N a sort algorithm with better runtime complexity like quicksort wins.. but why care about that.. lets focus on the constants like you want. Lets all use insertion.

Re:So many

[grumbel]

You can use them all you want.. it doesnt help even if you originally had 100 million polygons but culled that set down to only 1 million polygons and sent them to the renderer.

What exactly stops you from culling down further? If you don't even have a million pixels on the screen, whats the point of throwing millions of polygons to the screen?

Sign of the times...

[rh2600]

When a laptop packing a multi-GHz 64bit CPU with gigs of RAM gets called a thin client...

Re:Sign of the times...

[aws4y]

it is thiner than the server cluster computing each frame at the back end of this caned demo.

Re:Sign of the times...

[L4t3r4lu5]

It is a thin client. All it's doing is holding the client software to accept the pre-rendered feed. It does nothing but hold a high speed network connection and display rendered frames.

It's their fault for using such a high powered bit of kit, but if it's doing no processing of its own it's still just a thin client. Albeit extremely expensive.

Re:Sign of the times...

[RulerOf]

it is thiner than the server cluster computing each frame at the back end of this caned demo.

Not only is it thinner, but it's Intel certified not to squash your nuts when used on your lap, unlike the rackmount server.

...I learned that that the hard way.

The rackmount servers do tend to run cooler, though, so if you're not terribly attached to your nuts....

Re:Sign of the times...

[Sulphur]

That is dual core you insensitive clod.

Re:Sign of the times...

[drinkypoo]

It's their fault for using such a high powered bit of kit, but if it's doing no processing of its own it's still just a thin client. Albeit extremely expensive.

Seems more like a thick client anyway...

I doubt they could have done it without the bandwidth that the newer hardware affords. Intel has traditionally been starved for bandwidth of all types; not so now.

Poor ray tracing

[DarwinSurvivor]

Their ray tracer has a few issues.
-The player does not appear in the scope reflection (but his shadow does).
-The people's shadows are cast in a different direction than the car's.

Re:Poor ray tracing

[Purity Of Essence]

1. It's extremely common in FPS games for the player model to be excluded from the player perspective. It really complicates things and usually doesn't look good without a lot of extra work.

2. That's not the car's shadow. The building shadow is the shadow you are seeing. You can't see the car's shadow because the car is mostly (if not entirely) shadowed by the building behind it. The viewing angles were not suited for showing a shadow cast by any directly illuminated portion of the car.

Re:Poor ray tracing

[Anonymous Coward]

You are right, the player model is often excluded, but that isn't really necessary. Especially id Software is usually known to show the player model's shadows and refelctions (including mirrors) since Doom 3.
And if you really want a game with not only visible player model but actually pretty good player animation and physics, you should try out Dark Messiah of Might and Magic.

Re:Poor ray tracing

[noodler]

Talking about shadows,
in the indoor scenes, specificly the one with the nine monitors, there should be loads of shadows underneath the desk.
Especially because there are several lamps above the desk.
There are, however, no shadows.
And the lamps don't seem to be lighting anything.

So i'm pretty curious about their definition of ray tracing.

Re:Poor ray tracing

[ciderbrew]

This sounds like a John Lasseter I saw ages ago. Those guys are scientists not 3D artists. They can't see why it's wrong. It's job done when the maths work. I've not idea why they don't hire in a guy, most of these problems have been identified and fixed in the pre-rendered market years ago. Maybe extra lights kills the frame rate too much.

The worst example of 3D I've seen so far would be the "shadows on a mirror" trick - nice.

Re:Poor ray tracing

[ciderbrew]

SORRY - "This sounds like a John Lasseter interview I saw ages ago"

Re:Poor ray tracing

[Anonymous Coward]

And it looked like there were some nasty artifacts popping out of the render farm when they were showing the street view.

What's the point?

[pacinpm]

I know they just started but still... what is the point of this? There is no upsides to rendering. It's slower (you need 4 servers), it looks worse (they had no antialiasing, ugly smoke, no complex lightning). You can do some things like reflections and refractions and portlas bit easier than with other methods but most of the time you don't need 100% correct reflections/refractions (simplified models work quite nice) and security cameras where implemented in Duke Nukem 3D on i486 machines without problems.

Other than selling Intel chips I see no purpose for this project.

Re:What's the point?

[retroStick]

As someone who has dabbled with raytracing before, I would have to agree. It's an interesting tech demo of something that's possible, but not really of practical use. For instance, they showed the chandelier with a million polys - that's all well and good, but it's on the ceiling! If the game was actually being played, the player would never get close enough to see those clever refractions. (And even if they did, the demo shows the frame rate would drop to around 17-20 FPS).

Re:What's the point?

[gmthor]

From what I heard. Raytracing scales better than rasteriastion. In other words O(raytracing) \subset O(rasterisation). Obviously, raytracing has really bad coefficients.

Re:What's the point?

[91degrees]

This does strike me as a bit of a problem with ray tracing in general. Purists like it because it is an accurate model of the optical system, but while it does have a number of inherent features that you get basically for free, it's slow, and a lot of the time you can get better results in rasterisation by faking.

Re:What's the point?

[leuk_he]

There is no point now. But in 10 years (maybe faster) the cpu speeds has increased to the point that you don't need a high performance cluster. It would be nice if you can at that moment run a game without an advanced GPU. in full detail.

If you have to start research about raytracing when the hardware is cheap enough you are too late.

And as for quality: fun of a game has little to do with grpahics quality. But it has to advance, or else we still would be looking at pong like graphics. people buy 1080p tv at sizes where it almost impossilbel to see the difference with 720p. But they still want the best quality.

PS, when they speak of wolfenstein i still think of the 1991 prequal to doom that was playable on a 286.

Re:What's the point?

[MichaelSmith]

It should scale well for multiple clients, particularly where surfaces are not perfect optical reflectors. If every surface scatters then each client need only require tracing for the last leg of every ray.

Re:What's the point?

[TheRaven64]

Not quite. The complexity of rasterisation is (very) roughly O(number of polygons * number of lights). The complexity of ray tracing is O(number of rays). The number of primary rays is the number of pixels (sometimes multiplied by 4 or 9). The number of secondary rays depends on the number of lights (you fire a ray into the scene and then a secondary ray from what it hits to each light). This means that increasing the complexity of the scene does not affect the ray tracing time very much, but increasing the resolution does. On the plus side, ray tracing gives you shadows and reflections for free. It also degrades more gracefully - you can get a lower quality scene quickly (just from one primary ray per pixel) and then add the details from secondary rays and extra rays if the user doesn't move. In contrast, rasterisation tends to just lower the frame rate.

Re:What's the point?

[hairyfeet]

Not to mention who is actually gonna use this thing? Bandwidth ain't cheap for most folks, and uncapped connections are becoming a thing of the past. Finally you have the fact that a good 90%+ of the games are made for either the consoles first, or are designed to be "multiplatform" which means my $36 HD4650 I bought over a year ago plays just about every game out there at my LCD native 1600x900 thanks to the consoles being so behind the curve.

So other than spending a whole bunch of money and man hours so Intel can go "Ooohh shiny" I fail to see any real world application for this. Film designers aren't gonna give a shit about real time, only quality, and consumers can't afford the bandwidth this hog would suck, which would probably be a slideshow on the average cable or DSL line, and game designers are building for the x360 level graphics which makes this right out. Am I missing something?

Re:What's the point?

[ByteSlicer]

That's all nice in theory. But in practice, the raster version runs on my desktop at 200+ FPS, while the ray-traced version runs at 0.1 (?) FPS.
Probably one day the chipsets will be powerful enough to do this on a single machine, but even then ray-tracing doesn't give a full render solution. You'd need a global illumination implementation (radiosity, photon mapping) to get realistic (secundary) shadows/hilights.

Re:What's the point?

[Anonymous Coward]

My friend had a 486DX with a soundblaster card and a Bose Acoustimass 5 Series 1 system in 1990(rich kid). When I saw Wolfenstein for the first time, all I could say was WOW! The graphics! The sound! Anyway eventually I was able to get a 386SX20 a few years later. It was faster to run Linux Doom on the 486DX in the linux cluster(1994-5) than my computer at home, DOS or Linux it didn't matter, I had a slow video card. I would log in to one of the systems from home using my 14.4 zoom modem and create a remote X session and play it at home. Good times, Good times...

Re:What's the point?

[Amouth]

PS, when they speak of wolfenstein i still think of the 1991 prequal to doom that was playable on a 286.

thats what i was thinking - would be fun to see it re-released with nothing but the graphics improved (still no mouse aim no multilevel no physics)

Re:What's the point?

[robthebloke]

> The complexity of rasterisation is (very) roughly O(number of polygons * number of lights).

Doesn't deferred rendering improve that though?

Re:What's the point?

[MidoriKid]

Not quite. Each ray still has to be tested for intersection. Assuming an efficient spacial database this increases the complexity to O(number of rays * log number of polygons). Point still taken, though.

Re:What's the point?

[j1m 5n0w]

Reflections and shadows are easy from an implementation point of view, but they aren't "free" from a performance point of view, and as MidoriKid noted, rays don't all cost the same - you usually do approximately log(N) ray intersection tests for each ray, with a good acceleration structure, where N is the number of polygons. There are also problems with very large numbers of independently moving geometry - rebuilding the acceleration structure is generally N*(log(N).

In practice, ray tracers slow down as you increase the amount of screen space taken up by complex objects, but they tend to be fairly insensitive to the total amount of geometry in the scene, whereas graphics cards tend to be limited by the total number of polygons in the scene.

Re:What's the point?

[TheRaven64]

There are also problems with very large numbers of independently moving geometry - rebuilding the acceleration structure is generally N*(log(N).

It's been a few years since I hacked on a ray tracer (my PhD was in large data set management, and a ray tracer was one case study), but back then we used a scene graph where we fired the rays independently through the moving scenes. The top-layer scene graph was very coarse and just told you which objects were in roughly which area and the ray tracer then fired the ray through the octrees for each of the objects along its path. Moving an object just meant relocating the object in the scene graph octree. You had two octree traversals - one to find the correct octree(s) to intersect, one to traverse that object's octree - but you didn't have to rebuild the object's octree when it moved.

You could also do some tricks where you tracked which of the top-level octree nodes the rays passed through, so if something moved in part of the scene you only needed to re-fire the rays for part of the screen. This can even help a bit when the camera moves, as small movements mean that you can reuse the results from secondary rays, even if you have to re-fire the primary ones.

Re:What's the point?

[slashdotjunker]

1. Immediate lighting rasterizer = O(S*N*L)
2. Deferred lighting rasterizter =O(S*N)+O(S*L)
3. Ray tracer = O(S*log N*L*D)

where N is the number of solid 3D elements, L is the number of direct illumination lights, D is the indirect lighting depth and S is the number of screen elements.

No matter how I look at this, ray tracing is not very compelling.

Once upon a time, we thought ray tracers were fast. If we hold screen size as a constant and set the number of bounces to 1 for a fair comparison to a 1992 era rasterizer we get the "classic" complexity analysis comparison.

1. Rasterizer = O(N*L)
2. Ray tracer = O(log N*L)

Winner: ray tracer. However, a few things have changed since 1992. First, screen size is important and should not be ignored. This is due to the increasing importance of screen space effects. Second, deferred lighting broke rasterization in half. Third, rasterizers can now do convincing shadows and fake global illumination. So, to keep up with the quality of the average 2010 rasterizer we have to set D>1. This is a 1-2-3 knockout combo for ray tracers.

Rasterizers are the current complexity king. Now, I'll tell you why it will remain the king. Ray tracers have an architecturally bad design. It looks like this:

for p in rays:
    for i in items: raytest
    for s in lights:
        for t in bounces: ...

There is a beautiful elegance to this. It is a good way to learn how to do computer graphics. Unfortunately, this kind of architecture always leads to bad complexity that looks like this: O(f1*f2*f3*f4 ...).

Rasterizers have a better basic architecture. Scatter-gather type architecture tends to lead to nice complexity like this: O(f1)+O(f2)+O(f3)+O(f4). Don't take my word for it, look at the history. The O(N*L) immediate rasterizer got broken up into the O(N)+O(L) deferred rasterizer as soon as enough memory became available. Indirect lighting followed the same pattern.

I'm not saying that ray tracers will always be slow. But, I _am_ saying that if ray tracers ever become fast again, it will be because they have been architecturally restructured into something that looks a lot like a rasterizer. In such a case, any claimed victory by the ray tracer would be a pyrrhic one.

Re:What's the point?

[MobyDisk]

The complexity of rasterisation is (very) roughly O(number of polygons * number of lights)

complexity of ray tracing is O(number of rays)

Both of those statements are completely incorrect. Your own comments explain why:

The number of secondary rays depends on the number of lights (you fire a ray into the scene and then a secondary ray from what it hits to each light).

So now it is O(number of rays * number of lights)

This means that increasing the complexity of the scene does not affect the ray tracing time very much, but increasing the resolution does.

Both increase the ray tracing time significantly. Point lights are simplest, but area lights can cause exponential increases.

Also, you neglect polygons in the ray tracing scenario. Ray tracing time is proportional to the number of polygons in the same way that rasterization is. Overall, the asymptotic complexity of ray tracing is far higher than rasterization, which is why rasterization is the dominant approach today. There are lots of benefits to ray tracing, but speed is not one of them.

Re:What's the point?

[n00854180t]

Wouldn't you still hit the performance bottleneck mentioned above when using any sort of skinned/deformable mesh objects? For a character or the like you'd end up updating a bunch of your object octrees every frame perhaps.

Re:What's the point?

[Anonymous Coward]

Solution: 1 CPU for every screen pixel.

Project Offset

[nacturation]

Anybody know what happened to http://www.projectoffset.com/ ? They released tons of killer videos showing an amazing game concept, outstanding real-time effects... then Intel buys them and... nothing!

Re:Project Offset

[nacturation]

Of course... Google is my friend:

http://www.joystiq.com/2010/07/02/project-offset-team-disbanded-at-intel-offset-software-founders/

Re:Project Offset

[Nagrom]

I'm seeing a fairly generic fantasy world and a bunch of nice rendering techniques that by now have pretty much all appeared in released games, on consoles even. Am I missing something?

Re:Project Offset

[nacturation]

I'm seeing a fairly generic fantasy world and a bunch of nice rendering techniques that by now have pretty much all appeared in released games, on consoles even. Am I missing something?

Keep in mind that these demo videos were released in 2005 by a three person team working out of an apartment. It was met with pretty much universal acclaim back then and still holds up extremely well against any engine today.

Re:Project Offset

[Dekker3D]

Absolutely ridiculous triangle counts and shaders that most of us wouldn't even dream of. Of course, they could've made better use of all that, so that people would actually get enthousiastic about it.

Re:Project Offset

[Squapper]

Yes they had some impressive tech and good artists, but about every experienced game developer in the field (including me) realized that super-ambitious projects started by a handful of indies in a basement rarely makes it to the shelves nowadays.

If you want to create a hit as an indie startup, you make something like Braid or Limbo.

Re:Project Offset

[Pharmboy]

but about every experienced game developer in the field (including me) realized that super-ambitious projects started by a handful of indies in a basement rarely makes it to the shelves nowadays.

There are some exceptions. Valve has a history of buying up these groups and hiring the original people. Day of Defeat, Portal, Team Fortress all started that way, and they have done the same with other small groups as well. One more reason I'm a fan of Valve, they buy talent and put them to work, giving them the opportunity to expand their original dreams.

Re:Project Offset

[Amouth]

If you want to create a hit as an indie startup, you make something like Braid or Limbo.

Both of which are amazing games - although i wish Limbo was longer - but i'm not put off by it, the attention to detail was wonderful.

Re:Project Offset

[Anonymous Coward]

but about every experienced game developer in the field (including me) realized that super-ambitious projects started by a handful of indies in a basement rarely makes it to the shelves nowadays.

There are some exceptions. Valve has a history of buying up these groups and hiring the original people. Day of Defeat, Portal, Team Fortress all started that way, and they have done the same with other small groups as well. One more reason I'm a fan of Valve, they buy talent and put them to work, giving them the opportunity to expand their original dreams.

They have also recently hired Icefrog, the head developer of Dota during the years of its greatest expansion. He's supposed to be creating a standalone Dota for Steam.

Does it run on a Beowulfenstein Cluster?

[Hadlock]

Yeah, you're rendering Wolfensetein on a cluster.... but can you get Wolfenstein running on a Beowulf cluster... or, dare I say it... a Beowulfenstein cluster???
 
;)

Re:Does it run on a Beowulfenstein Cluster?

[L4t3r4lu5]

With enough XML, probably.

Re:Does it run on a Beowulfenstein Cluster?

[arndawg]

Add some SOAP and virtualization in the mix and you got a synergy that will revolutionize the way you manage your beowulf raytracing..

Ironic

[Anonymous Coward]

That none of intels graphics processors have any hope in hell of real time ray tracing.

Re:Ironic

[dave420]

They were working on Larrabee, using up to 48 cores (essentially P54C Pentium cores, with some modifications), which would be much better suited to real-time raytracing than any existing GPUs.

fps counter lying?

[citizenr]

Chandelier part displays 40 fps on top right, but you can clearly see on the screen that its more like 15. Not to mention unimpressive difference between RT and normal renderer. I was expecting something more real life.

Re:fps counter lying?

[Anonymous Coward]

You ARE seeing a slower framerate: Youtube does not play at 40 fps...

Re:fps counter lying?

[cheater512]

That, and I assumed that there was lag when manually altering the camera angle, whilst other things moving around are fluid.

Re:fps counter lying?

[Anonymous Coward]

Measuring in Frames Per Imperial Second, you would get about 15.

Re:fps counter lying?

[GrumblyStuff]

So it's like when Calvin's dad tries to explain to him that they had color photos back in the day but the world was in black&white which is why all old photos are in black&white?

Re:fps counter lying?

[Zacqary Adam Green]

Also, the camera isn't synced with the monitor's refresh rate.

Cloud gaming and latency

[loufoque]

The very idea of using the cloud to render a FPS is preposterous and will never work in practice, for obvious latency reasons.

Re:Cloud gaming and latency

[Purity Of Essence]

Is that supposed to be ironic given the runaway success of the OnLive game service? http://www.onlive.com/

Re:Cloud gaming and latency

[Thanshin]

The very idea of using the cloud to render a FPS is preposterous and will never work in practice, for obvious latency reasons.

How else will you start training for the moment when that computing capacity is on every PC?

You use the cloud, ignore the lag and build an engine ready for the generation of computers that will come in five or ten years. You'll lose a lot of your investigation, but anyone who starts studying RT at that point will be years behind you.

Re:Cloud gaming and latency

[kramulous]

Forward thinking? That's craziness. Where on earth did you get such a crappy idea?

I wonder whether 5 years out is a little too far before this compute power hits the consumer.

Re:Cloud gaming and latency

[Anonymous Coward]

Heh, you say runaway success and I haven't heard anything about OnLive in months.

Re:Cloud gaming and latency

[Fross]

Do you have anything to back up that "runaway success" claim? As far as I can tell it's been shunned by hardcore gamers due >100ms input lag, and I've not seen anything about it having huge takeup.

Re:Cloud gaming and latency

[Anonymous Coward]

If you use the niche group of hardcore gamers to define success then few things will be called successful.

Re:Cloud gaming and latency

[tibit]

I don't know if latency is any sort of a problem. You're talking of a LAN connection. This technology is not meant to render stuff somewhere out there on the intertubes. It needs to be in the same building, or on the same campus.

Re:Cloud gaming and latency

[Danathar]

change "will never work in progress"

to

"will never work in progress for me"

Re:Cloud gaming and latency

[ShooterNeo]

Funny you mention that...I've actually played twitch FPS games on OnLive, a cloud gaming service, and they were playable. If the cloud gaming servers were organized such that nearly all subscribers could reach a server bank within 100 cable miles the latency from the cloud would be negligible.

Re:Cloud gaming and latency

[Anonymous Coward]

It's only >100ms if you have crappy internet.

I'm over 100 miles from an OnLive server and my ping to them is ~30ms. The delay is hardly noticeable and it actually does work pretty great.

You also have to look for other sources of lag. In a DirectX video game rendered locally, the Nvidia drivers are set to render 3 frames ahead by default. At 60fps this equals 16.67ms per frame or 50ms total. So the user input is being delayed by up to 50ms in some cases. When using OnLive we aren't rendering in DirectX so there is no extra delay added by the graphics card and this time it's only a 30ms constant delay (for me).

Also Onlive is brand new and it's only going to get better with more fiber and faster routers.

Re:Cloud gaming and latency

[Fumus]

I know. That's why I don't play multiplayer games. Imagine shooting people with 100ms ping. There's no way you could hit them!

Re:Cloud gaming and latency

[Anonymous Coward]

The very idea of using the cloud to render a FPS is preposterous and will never work in practice, for obvious latency reasons.

How else will you start training for the moment when that computing capacity is on every PC?

You use the cloud, ignore the lag and build an engine ready for the generation of computers that will come in five or ten years. You'll lose a lot of your investigation, but anyone who starts studying RT at that point will be years behind you.

For one thing, programming for "the cloud" is way, way different than programming for a single computer, even when we're talking about many-core processors.

For another, what does "You'll lose a lot of your investigation" mean. Investment maybe?

Ray Tracing is a horribly inefficient method of rendering, and even in 5 or 10 years, there will be a better method that will surpass it. It doesn't matter how much computing power you have, the more efficient solution can always use that amount of power better than you to do more.

Sure, it's remotely possible that hardware capabilities will have some sort of singularity and outpace the imaginations of video game developers at some point, but that won't be a permanent situation, and it's almost guaranteed to never happen due to price concerns.

The surveillance station. ...

[malakai]

The surveillance station.
At a wall in the game you see twelve screens that each show a different location of the level. This can be used by the player to get a tactical gaming advantage. Have you ever seen something similiar in a current game? Again - probably not

Someone doesn't play many games. Many 3D engines, for well over 10 years, have had some means of rendering to a texture and throwing it up on a poly in the game world. I'm going to say that hardware accelerated means of doing this have been common for at-least 6 years.

Re:The surveillance station. ...

[WhitetailKitten]

You wanna know the last game I played that featured this "surveillance camera" business?

Duke Nukem 3D


Ohhhh, snap!
/* OK, it was one monitor at a time, but that's arguably a tactical decision to not let the player see every camera at once */

Re:The surveillance station. ...

[ninjacheeseburger]

Garry's Mod for Half Life 2 allowed you to build your own surveillance station and place/move the cameras where you wanted. You could also change the texture of an object to show the view from the camera.

Re:The surveillance station. ...

[Anonymous Coward]

I think the "probably not" is in reference to the twelve screens.

Re:The surveillance station. ...

[WhitetailKitten]

Garry's Mod for Half Life 2 allowed you to build your own surveillance station and place/move the cameras where you wanted. You could also change the texture of an object to show the view from the camera.

Granted. I said the last game I played. Not the last game. I'm sure Call of Honor Arena 2009 or whatever the kids are playing these days. (My old geezer imitation isn't that good.)

Re:The surveillance station. ...

[daid303]

You had to 'use' the monitor to view it. I think Unreal (or atleast Unreal Tournament) was the first engine that managed to render a 3D back to a texture and display it ingame. And that's more then 10 years old.

Re:The surveillance station. ...

[Anonymous Coward]

Not so, actually there was always a low-resolution view through the monitor, rendered in the game world.

Re:The surveillance station. ...

[Anonymous Coward]

Didn't System Shock do it in, like, 1994?

Two things struck me about this:

[pancakegeels]

1. There is no reason why a game would need a raytraced chandelier. But how good is raytracing at deformation and breakage - what happens if I shoot that rendered glass plate? 2. The reflections make sense as a tactical advantage , but the screen recursion doesn't even fit with reality. Screens have a resolution, cameras taint an image, so zooming into a screen shouldn't lead to a Portal-like infinity. Is it possible to set restraints/limits and add effects to situations like this? Anyway, that was fun, if a little shiny. I love this kind of tech, but its just that little step short of being a game changer for me.

Re:Two things struck me about this:

[leonem]

On point 1, a ray-tracer would probably not incur much additional rendering load shattering the glass (physics is another matter), so long as it remains the same number of polygons. There might be some additional calculation as multiple pieces of glass passed in front of each other, but most raytracing engines put an absolute limit on the number of ray interactions. This is generally not perceptible because, as you point out, screens have a resolution ;)

Re:Two things struck me about this:

[Anonymous Coward]

The last time I read about ray tracing, they needed to keep the objects in a space subdivision tree structure like BSP to get the O(log n) scaling they like to advertise. The problem was that there was no easy way to update a BSP. Is there now a good solution for maintaining an efficient space subdivision tree for a shattering a million-polygon chandelier?

Re:Two things struck me about this:

[leonem]

Ah, no, that's a very good point. My experience is of rendering for video, where there is no penalty for breaking up an object. However I'd therefore assume it's not using pre-calculated structures to speed up collision testing (and is therefore slower).

Re:Two things struck me about this:

[dbIII]

But how good is raytracing at deformation and breakage

It isn't, but good looking brittle fracture shouldn't be too hard to model in other ways (simple finite element arrays with a big mesh) if you don't care about true realism. Simple elastic and plastic deformation on a macro scale (eg. bending a bar) shouldn't be that hard either because you'd be dealing with much bigger elements (cubes, cylinders etc) than the polygons you have to worry about with lighting.

Re:Two things struck me about this:

[robthebloke]

BSP's (in the DOOM sense) had to be aligned to polygon planes, and required the splitting of geometry in order to facilitate nice tricks such as front to back rendering (for transparency), not to mention collision detection. It's rare to see BSP used in such restrictive ways anymore (in games at least), and in fact they have largely fallen out of favour. Portals, Kd trees, Oct-trees, AABB-trees, OBB-trees, ABT trees, and Quad trees are more common approaches these days (effectively most of them are axis aligned BSP trees), and it's rare for the spatial nodes to store single triangles anymore (it's more typically used to store whole objects - although triangles from static level geometry may be bucketed into the nodes). Part of this change was driven by the fact the GPU likes batches of data to process (rather than individual triangles), and the other reason was to facilitate dynamically moving objects. Animating a few thousand objects in a loose KD tree, or an ABT tree would not be computationally expensive. However the time spent computing ray intersections would certainly increase.

I could think of ways around the problem however. For a complex non deforming geometry object (eg chandelier), it would be possible to construct a local space KdTree around it, test the ray against the object bounds, transform into local space of the object, before finally testing the ray against the spatial tree. For cases where that doesn't work (eg a deforming mesh), you either have to accept the extra cost of re-building the tree (the performance on which depends on your mesh size), or you can reverse the problem and construct a Kd Tree around the ray itself (which can be more efficient in some very specific cases).

However you look at it though, deforming geometry adds a lot of overhead into any renderer, ray tracing more so.....

That's... Lovely.

[L4t3r4lu5]

10fps to be able to see glass refraction on a surface so small it's totally inconsequential.

Yawn. Wake me up when they get refraction working with a playable framerate like Source had seven years ago. Regarde

Re:That's... Lovely.

[Smidge204]

Actually my first reaction was the "Lost Coast" demo that Valve put out with Half-Life 2 a few years ago. It had dynamic reflections and refractions in animated water surfaces and stained glass windows with refractions.

And it didn't need four high-powered graphics servers to keep it above 10FPS either.
=Smidge=

Re:That's... Lovely.

[JCZwart]

Ray tracing is way too CPU-intensive to ever be used in actual games. However, to be able to render scenes so fast that you can actually play through them (somewhat), that's new.

The Source engine doesn't ray trace anything, it renders. As do all games. Ray tracing has always been used to create images (remember all those old, quite static games featuring beautiful, pre-rendered images?), just not real time.

Will we get Raytracing in the next 50 years?

[devent]

Everybody agrees that ray tracing is just awesome and I at least think it's the future of 3D computer graphics. But there is only one big 3D hardware vendor left, AMD is more a CPU vendor that tries to get into the 3D market because Intel is too big in the CPUs market. Intel only have small on-board graphic chips. Will we see ray-tracing from Nvidia anytime soon?

I sure hope that maybe Intel or AMD try to take over the 3D computer graphics market with their CPU know-how (ray-tracing is using mostly the CPU). But I really don't hope to see ray-tracing in laptops or desktops in the next 50 years to be mainstream. Nvidia and ATI all focused on triangles and ray-tracing is like an new beginning. http://caustic.com/ is really a step in the right direction with their OpenRL SDK.

Re:Will we get Raytracing in the next 50 years?

[grumbel]

Everybody agrees that ray tracing is just awesome

Actually, no, the raytracing shown in that demo isn't awesome, it is rather primitive and ugly. You can render shiny spheres with it and static high polygon objects, but basically nothing else.

The stuff that you need to make graphics look good is global illumination and that demo had none of that. Todays games on the other side start to get there, you can already find realtime ambient occlusion in some games, you can get soft shadows and there have been tech demos even showing realtime photon mapping. And of course there is a lot of post-processing trickery like crepuscular rays that make things look good.

At a certain polygon count raytracing may have advantages and for many of the advanced global illumination stuff you also end up tracing rays in one form or the other. But the demo shown demonstrated none of that, it was basically your grandfathers primitive ray tracing. Not exactly impressive by todays gaming standards, especially since it even failed to get basic stuff right, like the particle effects which looking ugly by last-gen standards.

Re:Will we get Raytracing in the next 50 years?

[devent]

What about the techdemo from caustic? Is that under the category "awesome"?

Re:Will we get Raytracing in the next 50 years?

[JCZwart]

Ray tracing has been with us for many many years now. However, it's much too math intensive, so totally unsuitable for use in games. Apart from using it to pre-render scenes, which in turn can only be used as statical images.

The use of ray tracing in games doesn't have a future. Figuring out new tricks to get games to render ever more realistic graphics while retaining a playable frame rate does (it's basically what John Carmacks entire career is built upon).

Re:Will we get Raytracing in the next 50 years?

[devent]

You missed my point. Don't you think the stuff that today games do are pretty math intensive? But the math is so fast done because we have specialized hardware for it.

So I ask, when we have the hardware to do ray-tracing like we have the hardware now to do triangles? When will ray-tracing become the mainstream? Because I think that the future is in ray-tracing (maybe I'm wrong).

Re:Will we get Raytracing in the next 50 years?

[demonbug]

I was waiting to see if anyone would bring up Caustic. I was curious how their hardware compares to Intel's, but there doesn't really seem to be enough information available to compare them. IIRC, Caustic was showing off real-time rendering with their Caustic One at resolutions around 640x480, but the demo I'm thinking of is a little old and they may have refined it since then. They do mention a Caustic Two on their website in passing, but I can't find any information on it. Any insight into how Intel's hardware approach compares w/ Caustic's?

Re:Will we get Raytracing in the next 50 years?

[Anonymous Coward]

Not compared to ray tracing, are you kidding me?

Go ahead and come up with this magical hardware that streamlines raytracing, no one else is going to.

Re:Will we get Raytracing in the next 50 years?

[JCZwart]

I'm pretty certain I got your point, actually. :) It's just that games don't need photo realism, so why use a very very math intensive method to render something perfectly when you can use a method that's just very math intensive to render something not perfectly but acceptable to the eyes of a game player nonetheless?

It'll always be that way: the time needed to ray trace a certain scene will always be more than what's needed to render the same scene using umpteen triangles, the textures of which can be enhanced by techniques like bump mapping and what-have-you. The amount of details in a ray traced scene would always be less than the amount of details in a scene that's rendered using 'tricks', because of performance trade-offs.

Yes, current games do stuff that's very math intensive. They might also have multiple methods for rendering the same thing: one for when it's up close and needs to be displayed very detailed, and several more optimized ones for other scenarios. John Carmacks career is pretty much built upon finding clever optimizations like that, enabling Id Software to come up with novel rendering engines (Mike Abrash talks about this in his articles 'Ramblings in Realtime', which make for a pretty interesting read, if you're somewhat into games programming). For ray tracing you'd still have to trace all rays, it's kind of hard to optimize that.

Plus, hardware would only be developed for something that has the potential of becoming widely adopted. The advent of semi-3D games like Wolfenstein, Doom and Duke Nukem 3D made a switch to real 3D very likely, so the gamble of developing 3D rendering hardware proved to be a very profitable one, and nowadays a PC without such hardware is virtually unthinkable. I don't see that happening with ray tracing. I mean, ray tracing a not-so-detailed scene requires a cloud of computers, while for rendering a highly detailed scene in Crysis nothing more than a good gaming PC is required.

And yet the players still don't move like people

[VShael]

I want my kills to look hyper-realistic. And soon.

Submit your Resume

[stimpleton]

If the "Future of Graphics Rendering" was a job being advertised and potential candidates were asked to submit their Resume, then Intel's would be very thin.

The job is asking for 5 years experience, with a tertiary qualification, preferably post grad.

In Graphics, Intel has completed High School and done 2 years admin temping.

And yes, I am still bitter about the Intel i740 Graphics Card. Intel are just great at the snowjobs, even suckering John Carmack in a very ancient .plan update:
"Good throughput, good fillrate, good quality, good features. A very competent chip. I wish intel great success with the 740. I think that it firmly establishes the baseline that other companies (especially the ones that didn’t even make this list) will be forced to come up to."

The reality turned out to be what this story will be - smoke and mirrors.

Re:Submit your Resume

[0123456]

The reality turned out to be what this story will be - smoke and mirrors.

The i740 was OK once you stuck enough video memory on the card: what crippled it was Intel's crazy desire to pull textures over the AGP bus when other cards had large amounts of 128-bit VRAM. I presume the intention was to increase AGP takeup, but the reality was that it made AGP look bad when compared even to older 3dfx cards on PCI.

Hmmm

[DrXym]

It's interesting to see what a game looks like with raytracing, but I don't see any practical use for this tech until they can make it happen in a normal GPU.

The problem with ray tracing is that if you have 1280x720 display then you're going to have to fire off at least 921,600 rays which must be intersected with objects and these in turn split into more rays as they reflect / refract around the screen. In a complex scene you may end up firing millions of rays. And I say at least because at 1 ray per pixel the picture quality will be awful. A ray might miss an edge completely so you get weird ragged edges and patterns blinking in and out. The normal way to address ragged edges is to fire more rays per pixel so you might end up firing 4,5,6 pixels in a ray, and you might jitter (randomize them) to minimize weird effects on patterns. Then if you want shadows and stuff to not like shit you have to think about diffusion & radiosity. Then you have effects like fog, clouds, smoke, fire etc. to worry about.

So you've possibly got to be rendering 5,000,000+ rays per frame in a highly complex scene and do so fast enough to deliver at least 30fps.

Done properly it would look awesome, but the calculation required to get acceptable results is enormous.

Re:Hmmm

[tibit]

Just thinking about the bandwidths is interesting. Start with 150E6 rays per second. Assume that to traverse the binary space subdivision data structures takes, say, 256 bytes, along with another 256 bytes worth of data for the polygon. That requires ~77 gigabytes/s memory bandwidth, sustained. So in practice you need the bandwidth of 6 fastest DDR3 sticks. And your algorithms better kept the CPUs pipelines full, and did proper prefetching, or else cache misses will have you for a day's worth of meals.

Re:And yet the players still don't move like peopl

[Jedi Alec]

Join the armed forces and ship off to Afghanistan? Doesn't get much more realistic than that...

Re:And yet the players still don't move like peopl

[daid303]

Nah, the respawn time sucks in Afghanistan.

Re:And yet the players still don't move like peopl

[MichaelSmith]

Buddhism might be the go.

Joke? Puhleeze.

[RulerOf]

My 486 ray-traced perfectly. I don't understand why we're using processing power to show glass reflections in ray-traced sniper scopes when all the old monitors showed the reflections of people approaching from behind already!

Stupid matte LCD panels.

You were supposed to woosh him ;)

Ahh Youth

[kenp2002]

"The surveillance station. At a wall in the game you see twelve screens that each show a different location of the level. This can be used by the player to get a tactical gaming advantage. Have you ever seen something similiar in a current game? Again - probably not"

Yes, In Duke Nukem 3D... over 15 years ago. And again in a bout 40 other FPS games that followed including the Unreal series, more then a few Quake maps especially in capture and control maps.

"There is nothing more amusing to watch then some young kid discover something old and think it is new" - That quote in action.

Re:Ahh Youth

[Anonymous Coward]

Citation needed.

Re:Ahh Youth

[Anonymous Coward]

You've seen that in a raytraced game? Please, show me where.

Re:Ahh Youth

[Sigma 7]

Duke Nukem 3D, while it did have surveillance, only had one screen. If you stopped watching the screen, it would render a blocky image for one of the cameras it monitors rather than a clear image.

It took until at least the Unreal Engine before a multi-screen display was possible, and I'm not sure how much that impacted the framerate.

Re:Ahh Youth

[Anonymous Coward]

It's going to be a killer feature in Duke Nukem Forever!

Re:Ahh Youth

[Alan Shutko]

Duke Nukem and Quake... Is there anything in a current game? I'm wondering if it's a feature that got dropped off from most current games because it was hard to do with higher quality graphics?

Re:Ahh Youth

[SheeEttin]

Red Faction had security cameras in 2001. Multiple screens on-screen, but I don't remember if you could change them. Half-Life 2 (or one of the episodes) had security cameras, too, that you could change, but I don't think there were more than one at a time. (I don't think it's an engine limitation.)

Re:Ahh Youth

[Anonymous Coward]

Garry's Mod (built on Half-Life 2) can do it, at least. It has this "RT Camera", and there's a special texture you can apply to objects which displays what the camera's pointing at.

I think it's only ever one camera active at a time, though. It's been a while since I played with it.

Uhh. I forget, but I thought such was used in Half-Life 2 itself somewhere as well.

Why don't they run it on GPU's

[Neil Boekend]

Warning: I am not hindered by much knowledge in this area.

It seems to me GPU's, with their massive amounts of stream processors, would be quite suitable to do this job. The separate rays do not interfere with each other but have the same operations applied to them: perfect for stream processing.
To get a 1280*720 display with 9 rays per pixel (to get the edges correct) working you'd need nearly 9.000.000 rays each frame.
With 400 stream processors (A little beyond EUR 100 (HD5670)) you'd need every stream processor to process 22500 rays each frame.
Assume every ray requires 1000 clock cycles.
Assume a frame rate of 40
The clock speed needs to be 1000*22500*40=900000000 Hz. => 900 MHz
900 MHz is almost possible. The GPU I chose worked at 775. It's not an expensive one and you can insert 2 of them for more stream processors
With some optimization this number may fall. Brute force is usually not the best way.
Where did I guess or think wrong? Would it already be possible for the cost of EUR 200?

Re:Why don't they run it on GPU's

[tibit]

Memory bandwidth is the key here. Processing speed is a secondary concern.

Re:Why don't they run it on GPU's

[Spatial]

The two main GPUs in that price range can push 108 and 128 gigabytes/sec respectively. Is that not enough?

Re:Why don't they run it on GPU's

[tibit]

That's when you stream. I don't know offhand how the binary space partitioning meshes with caching. Unless someone shows me research where they benchmarked it and shown it not be an issue, I'll assume that 100-130 gb/s may not be enough. Those figures are for streaming reads/writes. Random access will be slower, perhaps 2x slower, perhaps more. I expect very little cache coherency, so pretty much every 2-3 accesses to a cache line will end up in an eviction. The raytracing needs say 50-100gb/s of random access.

Re:Why don't they run it on GPU's

[dave420]

It doesn't really work like that. Ray tracing is not very good for stream processors, as it requires lots of branches to calculate each ray (as each ray bounces off a different surface or interacts with something else) which will halt the other streams until the branch merges back into the same place as the other streams, turning those 400 stream processors into 1 stream processor and 399 sitting-around-doing-nothing processors.

Sigh

[ledow]

Multi-million dollars graphics render farms and we still can't draw convincing fire, trees or animate a human walking smoothly (even with motion capture you often "see the join" between one action and another).

Re:Sigh

[ciderbrew]

Yeap, I agree... It's going to take a lot more money, CPU power and skill to beat the Uncanny Valley. http://en.wikipedia.org/wiki/Uncanny_valley

Re:Sigh

[tibit]

Motion capture is a crutch. What you really need for fluid motion of humans and other animate models is motion control akin to what they have in robots, say in Big Dog. What motion capture does is basically leave the dynamics and control to a wetware system. It's a hack at best.

The game engine needs a kinetics+kinematics simulator, and a controller like what you'd have in a real-life robot. If you push this idea forward, it enables you to do very realistic tricks. Say you get an extra strength pill -- all it'd do is increase the actuation force limits in your model. The fact that you can jump 15 feet high or bend steel bars just follows from that, no extra code required.

For Intel's demo to be impressive, they'd better implement a full dynamics simulator with motion controller for the animate models, as well as a FEM simulator (linear plasticity + dynamics) for certain objects in the environment. You go to a steel barrel, kick it, and you see a dent. You get a shotgun, you shoot it, it gets a nice ripped hole plus it tumbles. You get a big-ass-blaster, and you can shoot the barrel and keep it afloat in the air.

That would get me impressed. What they did is an intro-to-CG raytracing job with complex models instead of a bunch of spheres on a checkered background.

Moore's Law is NOT a tool

[Carrion Creeper]

In the Knight's Bridge link, Intel PR references Moore's Law as if it were some method for increasing processing power: "and use Moore's Law to scale to more than 50 Intel cores". Moore's Law is a prediction, not a design method. Sheesh.

Add that to the grammar mistake on the Aubrey Isle image, and you have some pretty bad PR for anyone paying attention.

Re:Moore's Law is NOT a tool

[ksandom]

Moore's Law has become an expectation, and thus a design method from a marketing point of view. This is particularly visible in harddisks where they release a harddisk that has been designed to scale up, but only contains a single platter, then a little over a year and a half later, the same hard disk is released with a second platter. The expectation allows them to get ahead, while the previous iteration is slowly allowed to get to it's full potential. Then they work on the next thing and while the current platform grows.

Re:Moore's Law is NOT a tool

[Carrion Creeper]

My problem is more that the press release is putting Moore's Law, which is at best a product life cycle methodology, on the same level as the 22nm process, which is an actual technology for making better/faster/smaller chips.

They put it there so that people who know nothing else can see something familiar in the introductory paragraph. The problem being that they are making the misinformed even more misinformed by using Moore's Law in the wrong context and confusing the issue. Nobody who know better wants to have to explain misconceptions about Moore's Law just because Intel is putting out crappy press releases.

Watch the video on the blog

[ksandom]

It's awesome!

Re:Joke? Puhleeze.

[mehrotra.akash]

My 486 ray-traced perfectly. I don't understand why we're using processing power to show glass reflections in ray-traced sniper scopes when all the old monitors showed the reflections of people approaching from behind already!

Stupid matte LCD panels.

So thats why most laptops come with glossy screens..:)

Re:Joke? Puhleeze.

[V!NCENT]

Wolf3D was ray casting, not ray tracing! ;)

Other than that. whooooosh!

Two triangles is a Square, not a failed Triforce.

[Anonymous Coward]

nt.

Huh?

[Lisandro]

Why would someone want to raytrace a game which is 18 years old?

Re:Huh?

[JCZwart]

Judging the video clips in TFA it's the Wolfenstein remake they're ray tracing (with the BS Swastika replacements, by the way).

Re:Huh?

[Anonymous Coward]

*wooosh*

Props to ze narrator

[smurfsurf]

Greetings from Germany and a special shout-out to ze narrator who has ze proper aczent for demonstrating zis particular game :-)

Intel is obsessed with raytracing

[Sycraft-fu]

They don't like the whole GPU market because the more powerful a GPU you have, often the less powerful a CPU you need. This is particularly true now that GPUs are out and out stream processors. Intel sees this as a threat, and AMD has made it a more explicit threat with their fusion idea (combined CPU/GPU chips).

Well as a result of this Intel has done various things some useful (like make extremely fast processors) and some not. This is one of the "not" things. They have been trying to get people interested in the idea of ray tracing on the CPU. GPUs aren't especially good at raytracing, they are designed for rasterization. Not saying they can't do anything related to it, but their speed advantage isn't there. Of course the problem, as anyone who's gone from the theoretical world of CS classes to the real world can tell you, is that ray tracing is very hard to do quickly on real hardware.

Intel has played with it and done some neat hacks to speed things up, as well as just thrown a lot of modern hardware at it and produce some demos... That seem to produce your reaction almost universally. They don't look much better than the rasterized version.

Ahh Youth

[Anonymous Coward]

He said "in a current game". I also thought of Duke Nukem 3D, but 15 years ago hardly constitutes current...

Ignore the lag

[tepples]

You use the cloud, ignore the lag

How much ignoring do you mean? I know you mean something between a turn-based slideshow and a twitch game, but precisely how much?

Re:Ignore the lag

[Thanshin]

Offtopic: About your signature "I want an Android device with Android Market, but I don't want a phone. Is that so much to ask?"

Have you considered an Archos 5 IT?

Re:Ignore the lag

[tepples]

Thanshin: Let's continue the discussion elsewhere.

Castle Wolfenstein!

[Anonymous Coward]

Speaking of which Wolfenstein you think of, I thought of Castle Wolfenstein on the Apple ][ and Apple ][+

Didn't need much ray tracing there!

"The Voice" and graphics were fun for the time.

So how do I play any of this?

[theskov]

Looks like a lot of fun to play around with, but is it all youtube videos, or can you actually get to try it on your own? Wouldn't mind buying the game to have a chance to see what a modern multicore CPU could pull off.

Re:And yet the players still don't move like peopl

[VShael]

The respawn time sucks everywhere, not just Afghanistan.

Ever seen something similiar in a current game?

[FunkyELF]

The surveillance station.wolf_station.jpg At a wall in the game you see twelve screens that each show a different location of the level. This can be used by the player to get a tactical gaming advantage. Have you ever seen something similiar in a current game? Again - probably not.

Uhm.... Counter Strike had this in one of its levels like 10 years ago.

Realistic, what?

[Anonymous Coward]

He claims the glass on the chandelier is so realistic, but it doesn't look anything like real glass, so what's the point?

Rigid thinking

[Angst Badger]

The model is highly detailed with around one million triangles.

Sounds like the programmers are way too used to the dominant rendering model. One of the advantages of ray tracing is that you don't have to build everything out of triangles; you can have real continuous curves. For example, a ray-traced sphere can be an actual sphere. A lot of objects that require thousands of triangles with current GPUs can be produced using a much smaller number of objects using constructive solid geometry in a ray tracing context. It's analogous to the difference between raster and vector graphics.

Re:Rigid thinking

[grumbel]

One of the advantages of ray tracing is that you don't have to build everything out of triangles; you can have real continuous curves.

Real continuous curves are pretty much useless for gaming, as they are an artificial restriction that really doesn't help much with anything, unless its CAD or you want to fit your game into 64KiB.

It's analogous to the difference between raster and vector graphics.

Vector is only good for low detail stuff like logos, if you want to get photorealism you go with pixels.

Re:Rigid thinking

[Angst Badger]

Real continuous curves are pretty much useless for gaming, as they are an artificial restriction that really doesn't help much with anything, unless its CAD or you want to fit your game into 64KiB.

Actually, there are two benefits aside from reduced memory consumption (which is nothing to sneeze at): many continuous shapes render faster than polygon meshes when ray-traced, and they look better. I have yet to see a 3D game where the triangle mesh wasn't obvious along the boundaries of objects or, for that matter, where the mapping of textures to meshes wasn't also flat and obvious. Look at the barrel-vaulted ceiling and where it meets the wall in TFA. With ray-tracing, it's possible to entirely eliminate the faceting.

Vector is only good for low detail stuff like logos, if you want to get photorealism you go with pixels.

Maybe you missed the part about the analogy. Here's another one: ray-traced, mathematically defined shapes are to polygonal meshes as clay is to Legos. Yes, you can build anything out of Legos, but it's not necessarily the best tool for the job, it's not very flexible, it makes modeling simple shapes harder than it should be, and it's painfully obvious that you built it out of Legos.

Hey, it is a thin client!

[gwolf]

It even fits in a manila envelope!

Already heard about - Nothing new - Trash

[Anonymous Coward]

I'm not sure how much of an archievement squaring the circle is, we've all heard of this before.