Wolfenstein Gets Ray Traced 184
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."
Re:Poor ray tracing (Score:4, Informative)
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 (Score:2, Informative)
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:Cloud gaming and latency (Score:1, Informative)
Heh, you say runaway success and I haven't heard anything about OnLive in months.
Re:The surveillance station. ... (Score:4, Informative)
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:fps counter lying? (Score:1, Informative)
You ARE seeing a slower framerate: Youtube does not play at 40 fps...
Re:What's the point? (Score:4, Informative)
Re:Ahh Youth (Score:4, Informative)
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:Project Offset (Score:4, Informative)
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:I don't get it (Score:2, Informative)
Re:Cloud gaming and latency (Score:1, Informative)
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:What's the point? (Score:2, Informative)
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:Ahh Youth (Score:3, Informative)