[MUD-Dev2] [DESIGN] Ray traced environments

Adam Martin adam.m.s.martin at googlemail.com
Mon Mar 26 07:39:24 CEST 2007


On 20/03/07, John Buehler <johnbue at msn.com> wrote:
> > John Buehler wrote:
> > > Processors are fast.  They're getting more numerous per box.  We have
> > > graphics coprocessors.  Physics coprocessors are also out
> > there.  It may
> > > be
> > > time to start talking about raytracing in games.

Problems:
 - raytracing is fundamentally non-OpenGL / DirectX, which means all
the API's would need re-doing, and all the engines that interface to
those API's, and all the learning in people's heads
 - what raytracing does exceptionally well (curved surfaces,
parametric objects, naturally-deformable terrain/meshes, 3d textures,
infinitely high resolution from one data set, light reflection and
refraction, radiosity) is for the most part no longer much desired in
the industry (thanks to the arrival of and improvements in shader
technology), or is already being simulated "just good enough" by
throwing excessive hardware at the problem in scanlines (e.g. 3d
textures, curved surfaces, and IIRC to a minor extent parametric
objects)
 - triangle-processing hardware and raytracing hardware IIRC aren't
particularly similar, and the only commercial manufacturer of
raytracing hardware shot itself in the head years ago and has merely
limped along since, so lots of extra R&D would be needed to get
hardware at an appropriate quality and stability level.

> > - Physics co-processors are still-born.
>
> Agreed.  Their existence suggests the desire for one box to do more.  Too
> bad for the PhysX guys that Cell and multi-core arrived at the same time.

As someone who works almost entirely in *online* games, I beg to
differ: a deterministic physics coprocessor lets me do networked
physics games which are currently impossible thanks to the
non-determinism of CPU's and lack of software physics that runs fast
whilst emulating the CPU in order to fix that.

>
> > The reason is that ray-tracing is O(pixels), while scan-line tends to be
> > O(polygons) + a small contribution from O(pixels).
>
> Spread the word  :)
>

IMHO it's a case of "Yet another technically superior but
fallen-by-the-wayside" alternative. Ten years ago, simplistic
raytracing hardware made triangle renderers look ugly as sin, but for
whatever reason(s) the opportunity wasn't taken by anyone - except the
triangle companies ;).

Personally, I greatly prefer it - it's more powerful (artistically)
and higher quality - but the R&D gap at the moment is, I suspect,
insurmountable - at least on the hardware side. I'm sure we'll see
*some* raytracing software games appear in the near future that are
very impressive (*) - like the handful of software voxel games that
successfullly went head to head with OpenGL games almost 10 years ago
(was it Soldier of Fortune that used voxels to do actual blades of
grass, and fine-grained obstruction of line-of-sight?), but it was
only worth the effort for a narrow range of games.

(*) IIRC there were a few non-commercial ones about 5 years ago that
made extensive use of the "fully deformable meshes at no cost" to make
deformable terrain a fundamental part of the gameplay.

Adam



More information about the mud-dev2-archive mailing list