Slashdot Mirror
Intel Shows Off Quake Wars, Ray Traced
An anonymous reader writes "At the Research@Intel Day 2008, Intel showed a ray-traced version of Enemy Territory: Quake Wars. Compared to the original game, a water with reflections and refractions and a physically correct glass shader were added. Also, a camera portal with up to 200 recursions to itself has been demonstrated. To show off this ongoing research in the topic of real-time ray tracing, a four-socket system with quad cores has been used that allowed rendering the enhanced visual effects in 1280x720 at 14-29 fps. Just two years before, early versions of Quake 4: Ray Traced ran only at 256x256 with 17 fps. Even though Intel's upcoming Larrabee will be primarily a rasterizer, the capabilities for also doing ray tracing on it should deliver interesting opportunities."
No, they are simply colour mapping. They are not using pixel shaders.
I see two things here:
1. It runs on 4 x quad core. Which is about just 4X the CPU power a normal user could have right now. A 4X speed improvement isn't probably that far away. They may be hoping to reach a point where a dedicated video card is no longer needed. With the required performance level being so near, adding some extra support to the CPU may be enough.
2. Raytracing scales differently than methods currently used in games. With raytracing, increasing resolution is what adds the processing time, while adding detail is very cheap. Which I'm guessing means that as soon as you get raytracing going in real time at a decent resolution, adding extra quality is cheap. This would radically change the current situation, and possibly drastically bump the quality level.
3. Raytracing implements effects like shadows and transparency in a straightforward manner, which should make it easier to code. Game developers should like that. Also, in my understanding, raytracing also doesn't need to decompose things like spheres into lots of triangles, so the engine can test a ray's collision with a sphere directly. If you can specify parts of a scene as objects like spheres, toruses and such, it'd result in much finer detail.
What I think Intel is trying to do here to ATI/AMD and nVidia is the same thing fast CPUs did to soundcards. There's no longer a real need to have specialized hardware to play MIDI or add effects to sounds, since the CPU is quite capable of doing it itself. In fact, IIRC, Creative had to *blackmail* John Carmack into supporting EAX, because he could implement the same effects faster using the CPU.
Most people don't understand the beauty of ray tracing .... oh wait a minute, most people are DUMB! that's right >;D
...
Seeing these comments reflects very well the average human intellect about a subject before talking about it.
Then what's so special in ray tracing versus rasterization?
It's actual real world based mimickery. Ray tracing mimicks how real world works.
Ask yourself would you prefer physics to correlate to real world physics, or something quickly around the corner which is something like that but not quite? That's the difference between rasterization and ray tracing. Rasterization comes close, but never is quite the real thing, while ray tracing works to replicate real world physics of light.
Yes, it actually is physics calculations, in this case, the physics of light and visualizing it.
Then there's things like radiosity tracing aswell
With Raytracing / radiosity tracing just provide enough computational power, and you can make it look real, like an photo. With rasterization you can't do that, to rasterize, and make proper looking shaders, they never get quite there, but even doing the shaders, you need to think about how the real world works first, how light travels, how it interacts with what it hits, in other words how the rays interact with objects.
Rasterization is JUST a cheap trick to make it look something like that, nothing else.
It's a bit like comparing veggie soy "meat" to the real thing It's something like it, but not really, just a "cheap trick".
Now they used 16 cores to that, 4 cpus. Moore's law, CPU power doubles every 18 months, that means JUST 3 years before high end home users can enjoy something like that. in 4.5 years it becomes common, 6 years and it's every day. Be prepared for the coming of Ray Tracing. In about 7.5 to 9 years all graphics are probably ray tracing.
And that all without any software, or architectural advantages, it'll probably happer sooner with Intel making a hard effort to make it reality.
Pulsed Media Seedboxes
Yeah the genre could use more creativity. That said, ETQW is not your run of mill FPS.
Multiplayer only. Encourages teamwork by having five different classes that need to work together. Each map has multiple objectives. The two sides doesn't have the same weapons, vehicles and, more then often then not, specialities.
If you like FPS multiplayer games but crave more then deathmatch and capture the flag give the demo a try. Avaliable on both linux and windows(and mac but only full game afaik).
A bit of a plug, but it's a fun game.
As a fairly long-time FPS player, I can tell you that no FPS will EVER have any large amount of teamwork (unless you're in a clan, playing with friends, etc), no matter how much the game 'encourages' it.
A reflection on a doorknob and shadows are already quite easily achievable by current raster-based techniques. The former with dynamic cube-map FBO/PBO reflections (not perfectly accurate reflections, but given the size of a doorknob, more than acceptable). For the latter, per-fragment shadows (maps and volumes) have been around for quite some time (granted, in certain extremely high detail scenes ray tracing shadows might be faster).
.. Not sure that was entirely on-topic, but there's my tuppence on the near future adoption of ray tracing. Of course eventually everything will be done with unbiased rendering (basically just firing photons around and making them behave just like real photons would, see Maxwell Render. Currently, still extremely time consuming)
The biggest immediately noticeable pros of ray tracing from what I've seen are reflections in arbitrarily complex geometry (current generation raster shadows are only viable for planar and some spherical reflections, unless there's a technique I'm not aware of). This, however isn't a good enough reason to switch to a purely ray traced paradigm IMO.
From a gameplay perspective it all seems a bit niche, but I'm sure there's someone out there with an idea that could make use of it. I just don't see FPS du jour picking it up any time soon.
Having said that, ray tracing may be a good utility to use alongside rastering techniques for things like sub-surface scattering or ambient occlusion.
You can't have played Tribes http://en.wikipedia.org/wiki/Starsiege:_Tribes or OpFlash http://en.wikipedia.org/wiki/Operation_flashpoint much.
Even with total strangers they were quite good at forcing people to help each other.
http://www.zombieapocalypse.tv/
The POV-Ray version 4.0 has been "informally decided" to be released under GNU GPLv3 by the devteam. Admittably, the release is probably far off in future, since it'll be almost complete rewrite.
Phillip Slusallek was demonstrating full screen real time raytracing using a custom RPU (raytrace processing unit) in 2005, and that unit was running at less than 100 MHz. For a fraction of the hardware cost of a quad quad core system, you could do real time raytracing with less hardware investment than a modern GPU.
Actually, with your standard raster renderer, they're mostly cheating to make this stuff work. Yes, you can get away with it in very specific scenes, but it's really kinda annoying to have to count how many doorknobs the player can cram into their field of view at one time, to make sure performance doesn't drop to crap when they're suddenly staring at 10 doors instead of just one or two. What happens when you start running around a hotel? Whaddya know - none of the doorknobs reflect anything anymore! Why? Because PowerPoint isn't in the games section at your local BestBuy.
Dynamic shadows are still optional in just about every game that features them. Why? Because only really fast, expensive cards can do it, and even that's stretching it. Some engines will only render dynamic shadows from one light, and the ones that do it for more than one have to be very careful about not placing too many light sources too close together. This will get better as games finally drop support for DirectX 8 fallback (DX8 is generally not able to do dynamic lights at all), but the other restrictions will likely remain for quite some time.
There's a lot of shortcuts, hacks, and arbitrary map design rules to make this type of thing work. Even things that we're pretty good at these days like water are often more restricted than they seem. You know that nice water in Valve's Source engine? You can't have more than one body of that high-quality water on the screen at the same time, or you're liable to get "unexpected behavior." In other words, it doesn't work. This is specifically mentioned in some of the map making tutorials. So you'll find nowhere in a decently designed map where you can have two different pools with that nice high-quality, reflective, refractive water. You can use the "cheaper" water, though. The cheaper stuff still looks OK, but it's not the real deal and looks strange to see the two side by side. This is mostly an issue where the level of the water is different between two pools of water, such as having a diving pool next to a raised water tank or something. If they're the same height, you can just cheat and use one one body of water clipped through the intervening area for both both bodies of water. This only works, of course, in places where the area in between is unimportant - water floating in mid-air just might be an unexplainable phenomenon in the context of some story lines.
The way I read this, raytracing makes solutions for these types of problems more universal (ie. you just have water, no BS about what kind of water it is and where it can be), and the performance hit for doing it several times in a scene is way less. I'm in no way involved with graphics engines, but I would assume that most of these features require rendering the scene multiple times with different deformations, and that raytracing is somehow faster at this.
"I do a grep for shit, bollocks, and tits before checking in code. I'm professional..." -RECURSIVE_META_JOKE, reddit.com
I guess that depends on how you define teamwork. In the etqw context I have engineers coming around to repair my vehicle when it's damaged. Field Ops supplying me with ammo. Medics healing and reviving me so I can complete a hack on the objective. Strogg technicians creating spawn hosts from fallen enemy troops so I can respawn behind enemy lines. Strogg oppressors putting up shields around me so I can disarm an explosive charge without getting shot in the back.
The addition of objectives gives players something to rally around and keeps things focused.
Of course etqw isn't the perfect game. Stacked teams, assholes and terrible games isn't unheard of.
But find a couple of server with a play style and regulars you like, and it is certainly better then many other games I've played.
It also has built in VOIP so the tools for very coordinated teamplay on public servers is there.
The playerbase is generally mature, even the younger crowd. I've almost never heard the voip abused and there isn't much non verbal abuse either(disclaimer: I haven't played on that many US servers).
But yeah, if you define teamwork as huge team pushes with perfect squad balance and shifting ad hoc goals you need to join a clan.
As a general rule, raytracing excels at secondary-ray tasks (= when one additional ray is shot originating from point of impact of the first, primary ray) like shadows, reflections, refractions, and the like, but doesn't pay off for primary-ray only tasks (solid wall, ground, ...) This is because rasterization is an optimization for the primary-ray-only case - you need local information only, no need to shoot rays for the entire surface, you can interpolate across it.
... how much % of the visible frame? In typical game scenes, opaque surfaces are the majority. This is not because of hardware limitations, but simply because most game worlds are NOT full of shiny surfaces.
Now, those doorknobs will make
A hybrid is the best approach. You correctly guessed that with rasterization, secondary-ray effects need to be calculated in multiple (and costly) passes. Moreover, since these passes usually render to a texture, you get aliasing issues because the texture pixels do not 1:1 match the screen pixels. You get blocky shadowmaps, blocky reflections, or noticeable noise when moving (in case the map is too large).
This sig does not contain any SCO code.
Back in the 6502 days, self modifying code wasn't just a trick, it was how some things were done. For example, there were no 16 bit indexed memory access methods. The main method for indexed memory references used one of the 8 bit registers for the low 8 bits of the address, and an immediate value for the high 8 bits. To loop over more than 256 values, you had an outer loop that modified the immediate value of the instruction every 256 iterations.
What if Tetris was invented by Nazis?