Real-time Raytracing For PC Games Almost A Reality 292
Vigile writes "Real-time raytracing has often been called the pinnacle of computer rendering for games but only recently has it been getting traction in the field. A German student, and now Intel employee, has been working on raytraced versions of the Quake 3 and Quake 4 game engines for years and is now using the power of Intel's development teams to push the technology further. With antialiasing implemented and anisotropic filtering close behind, they speculate that within two years the hardware will exist on the desktop to make 'game quality' raytracing graphics a reality."
Re:Big improvement on the way (Score:5, Informative)
Re:Big improvement on the way (Score:5, Informative)
With raytracing, there are lots of new possibilities. For one thing, reflection and refraction actually work like they do in real life. That means accurate mirrors, lenses, and water refraction. Lights can work accurately if you want them to, and radiosity can be precomputed for static scenes. That may just be eye candy to most people, but there are potentially game-play enhancements that make real life optics part of the game. Most of it (except good lenses) has been faked before with rasterization, but raytracing will actually let you set up a series of mirrors and telescopes to peek around corners in a FPS for instance. I can imagine a true hall of mirrors in an FPS would be at least a little more interesting than what we have now, too.
The other big technological benefit of raytracing is that it's asymptotically faster than rasterization. Raytracing is O(log n) versus O(n) for rasterization, which means that even though raytracing is currently slower (the constants involved in raytracing are higher), after the break even point is passed much less of the available computational power will be needed to render the scene and can instead be used for physics and AI.
Re:Is it still relevant? (Score:2, Informative)
This is super important because no matter how many cores you have, the bottleneck will still be going to memory and getting the data. In rasterization, the data accesses have pretty good spatial locality, but in areas with very high frequency lighting, there is just too much data, and every pixel is hitting a different part of it. Most of the really good ray tracers set up bundles of rays that have good locality, but this is really only trying to emulate rasterization with ray tracing in order to gain some of its performance characteristics.
In short, if rasterization can't do it, then it's going to be too slow to do in real time anyways. What ray tracing does give you is simplicity of writing code and freedom to do whatever you want, but it will never have the performance characteristics to be considered real-time. Even if you did have enough compute power to ray trace your scene at full resolution at full speed, it would be unconscionable to actually do it, because of the sheer amount of electricity wasted.
Re:Big improvement on the way (Score:1, Informative)
http://www.dream17.co.uk/softography.php?id=18&s=screens&url=screenshot_superstardust_amiga&i=02 [dream17.co.uk]
Re:Big improvement on the way (Score:2, Informative)
Re:Ya I haven't really seen many benefits (Score:5, Informative)
The problem with faking everything is that it quickly breaks down as your needs get more complex. For example, I've been working with a colleague recently on doing some nice, fast, impressive fake effects - most notably a system that can simulate a light shining through stained glass (not just a straight texture projection). We came up with a novel and fast way to fake it, but it completely breaks down if, say, two stained glass windows are in-line and you try to shine a light through... It simply doesn't work.
The advantage of doing things "for real" are that compatibility between your different effects is almost guaranteed, and your coders don't have to spend immense amounts of time curing those problems.
Re:Big improvement on the way (Score:3, Informative)
Re:Ya I haven't really seen many benefits (Score:4, Informative)
Just wanted to add a bit more explanation of this. Lightmapping has traditionally been the most effective way to get radiosity in a scene while still remaining real-time. When effects like normal and parallax mapping came along, lightmaps were suddenly incompatible. It took Valve to sort this out (though their solution is far from ideal), and only now, with UE3 and Gears of War, does it actually look halfway decent (Half-Life 2's solution washed things out, it's as if the normal mapping simply isn't there).
To solve the problem of two fake effects being incompatible, Valve invented a new fake effect to bridge it. You can imagine what happens when you start trying to mix a large number of effects. This is why the holy grail is still real-time raytracing - it's also a bit like why we want to have the Theory of Everything, as opposed to a bunch of little physics theories that each apply to a special case.
big O (Score:5, Informative)
- O(log n) in the number of objects in the scene
- O(n) in the number of primary rays, generally some multiple of the number of pixels on the screen (though it might be a bit less if you're using MLRTA)
- O(n) in the number of lights (though there may be some shortcuts) if shadow rays tests dominate
- O(something big) if there's a lot of reflective and/or refractive objects and you don't do anything to mitigate the rampant recursion
- O(n log n) in the number of photons, if you're using photon mapping
- O(n log n) in the number of objects that moved since the last time you rebuilt the acceleration structure
That first one was what the original post was refering to. (Tracing a single ray is O(n log n). Tracing a pixel involves sending one or more rays and a shadow ray for each light for each primary ray that hit an object. Tracing a whole image involves tracing a lot of pixels. If the number of pixels and the number of lights are assumed to be a constant, they drop out of the big O equation. It's a very big constant, though, and that's one reason why ray tracers are so slow. However, once you get enough CPU to compensate for that large constant, the algorithm starts running pretty fast, and it doesn't slow down much at all when you throw lots of geometry at it.Unintended consequence (Score:5, Informative)
Today, most CG effects must be hard coded, using tricks, shaders, complex modeling techniques, multiple passes, etc... In the raytracing world, as you are aware, the engine is easier to use, and I would also say, easier to code. It is also very easy to parallelize (so a specialized card could bring HUGE performance gains) and require few modeling tweaking compared to the current T&L world. In a raytracer, shadows (including self-projecting), reflections, refractions, bump mapping, displacement mapping, etc... are an integral part of the renderer, they are not a lot of different modules stacked on top of each other. Bringing down the complexity of the rendering engine hopefully frees more resources to work on other parts of the game.
Re:Big improvement on the way (Score:3, Informative)
Want to blow a hole in that wall? Instead of having destructible section pre-modeled, you just boolean subtract the shape of the explosion. Is it a brick wall, so the hole should have jaggy bits? Just run a greebling [wikipedia.org] algorithm on the edges.
Want to have breakable glass? Instead of having to make all your windows of sections that will probably have visible seams, have them be solid sheets and then use an L-system fractal starting from the point of impact to seperate it into shards that are different every time you break it.
Want to make a smooth sphere? You can have it exactly x^2+y^2+z^2=c instead of modelleing it as a 500-sided polyhedron.