Slashdot Mirror

I don't know how you imagine that game engines work or are "expected" to work. Frostbite utilizes Enlighten to provide real-time global illumination. I don't think Quake 1 did anything like that.

Take a look at Geomerics. Most of the visual quality that raytracing is supposed to provide is really better handled by radiosity, and Geomerics real-time radiosity and dynamic lighting is the best I have seen. It is being used in the new version of EVE Online and Battlefield 3. CUDA acceleration was just released for the SDK, which should bring radiosity lighting calculations down to less than 3ms/frame.

  It is based on "geometric algebra" (GA,real-valued Clifford algebra) which without any exaggeration is the most general and elegant form of math that can be used to describe physics and geometry. It works in any dimension of any signature, (5D "conformal" with two null-square dimensions being common for graphics) and allows operations and primitives which aren't effectively possible in conventional computer geometry. About half the top people in the GA field founded Geomerics.

One of the rare experts in GA in the UK who didn't join Geomerics is Ian G.C. Bell who co-wrote Elite, the seminal 3-D and space trading game from which Eve is descended. Ian has a free book, "Maths for (Games) Programmers" online, but the encoding of the HTML math requires using something like Netscape 4.79.

A far more usable introduction is Leo Dorst's free, small GA Viewer program and its associated pdf tutorials, which include the conformal model. This allows playing with the math visually (and it is fun), while also having rigorous but comprehensible instruction.

Wow! Ray Tracing!!! With one virtual photon per pixel!! That's like 10e-100th of what we see every time we look at something. Reality is just around the corner, I can feel it!

Come back to me when someone's figured out real-time radiosity...

http://fantasylab.com/
http://www.geomerics.com/

crap....

Waiter! Red pill, please!

It's amusing to read this. This guy apparently works for Intel's "find ways to use more CPU time" department. Back when I was working on physics engines, I encountered that group.

Actually, the Holy Grail isn't real time ray tracing. It's real time radiosity. Ray-tracing works backwards from the viewpoint; radiosity works outward from the light sources. All the high-end 3D packages have radiosity renderers now. Here's a typical radiosity image. of a kitchen. Radiosity images are great for interiors, and architects now routinely use them for rendering buildings. Lighting effects work like they do in the real world. In a radiosity renderer, you don't have to add phony light sources to make up for the lack of diffuse lighting.

There's a subtle effect that appears in radiosity images but not ray-traced images. Look at the kitchen image and look for an inside corner. Notice the dark band at the inside corner. Look at an inside corner in the real world and you'll see that, too. Neither ray-tracing nor traditional rendering produces that effect, and it's a cue the human vision system uses to resolve corners. The dark band appears as the light bounces back and forth between the two corners, with more light absorbed on each bounce. Radiosity rendering is iterative; you render the image with the starting light sources, then re-render with each illuminated surface as a light source. Each rendering cycle improves the image, until, somewhere around 5 to 50 cycles, the bounced light has mostly been absorbed.

There are ways to precompute light maps from radiosity, then render in real time with an ordinary renderer, and those yield better-looking images of diffuse surfaces than ray-tracing would. Some games already do this. There's a demo of true real-time radiosity, but it doesn't have the "dark band in corners" effect, so it's not doing very many light bounces. Geometrics has a commercial real-time game rendering system.

Ray-tracing can get you "ooh, shiny thing", but radiosity can get to "is that real?"

Ray-tracing has been around forever, people have implemented dedicated ray-tracing hardware in the past, and yet it's never managed to replace other rasterization methods for a few key reasons:

#1: It makes terrible use of memory bandwidth. Rays diverge very quickly from most detailed surfaces, so branching etc. eat up all of your potential cache performance. A more efficient rasterizer outperforms a recursive ray-tracer even when generating lots of lookup texturemaps to achieve the same effects (reflection/refraction/shadows etc.).

#2: It doesn't handle radiosity very well. Standard rasterizers can approximate radiosity quite well:
http://fantasylab.com/
http://www.geomerics.com/

#3: By the time you fix some of the performance issues with ray-tracing, the hardware ends up being more complicated and byzantine than even the more twisted modern graphics architectures (tilers, heirarchical depth buffers, etc), and efficiency still isn't as high.

#4: The O(log n) vs O(n) argument is wrong since it assumes the entire scene is fed to a standard rasterizer. In fact, frustum culling at the application level is also O(log n) and tends to be much more cache-friendly since all of the non-visible geometry outside the frustum (which is the majority of the total geometry for most real applications) can be tested exactly once per frame instead of once per ray.

It's silly to call ray-tracing the "next big thing". The fact is that ray-tracing is already being used where appropriate via techniques such as shadow mapping, cube-mapping, volumetric rendering etc. It will never be the end-all be-all rendering algorithm, and after having designed graphics pipelines for more than a decade I doubt it ever be competitive with what you could achieve using the same resources in other ways.

The dimensions may not be quite what you think. This paper sounds to me very like technology which is already being used in games engines and robotics applications, eg for lighting models and collision detection.

The idea is that there are various things that make rotations of objects much nicer to handle than translations. But if you add some extra dimensions, you can turn the translations into rotations. It's to do with conformal projection. Translations on a 2D plane are difficult to handle (at least in the framework of Clifford algebra), but if you map that plane onto the surface of a sphere in 3D, then you can identify the 2D translations with rotations on the surface of the 3D sphere. Similarly, you can exchange 3D translations for rotations in 4D, if you create a new dimension which allows you to have an origin for your rotations which is lifted outside "real" 3D space. It turns out to be nice to be able to do rotations about a point at infinity, too, which you can achieve by doing the same trick to go up to 5D. A consequence is that each no-D point in 3D gets represented by a 2D surface in the 5D, a line gets turned into a 3D hypersurface, etc.

The nice thing about rotations is that you can do them with spinors, and you can use spinors to rotate lines and planes directly without having to break them down into points. In the 5D system you can also use geometric algebra to compute directly whether and how different hypersurfaces meet, again without having to compute points and normals and things, which is good for collision detection.

It looks to me that this article is doing pretty much the same trick, turning 4D into 6D, that the geometric algebra people are using turning 3D into 5D.

Here's a paper from a group at Amsterdam university discussing some of this stuff, using it for a ray-tracing program. See also the previous two papers in the series, here. They've also just got a book out, "Geometric Algebra for Computer Science" (links to Amazon etc).

There's also a company called Geomerics based in Cambridge in England that has used the technology to develop a new lighting engine, which it has just released for the Unreal platform.

How about real-time radiosity?

http://www.geomerics.com/