[quake3] Quake 3 Raytracing Patch

[Stephan Reiter]

Woah, Thilo, that video is gorgeous! Thank you so much for your  
effort, you already made my day! :-)
I'm also glad that you were able to apply it to the EF version  
without additional steps necessary ...

As for your questions and remarks, I might shed some light on the  
issues:

> A few things I noticed: the Quake3 game assets are a bit older than
> EliteForce's, and thus standard quake3 offers fewer opportunities  
> to show off
> the raytracing stuff.

That's right. Raytracing shines especially when rendering surfaces  
with interesting properties regarding light transport, i.e  
reflections or refractions. EF is a great playground for this,  
because you glass, shiny weapons and a lot of metal.


> A few textures seem to be garbled. E.g. the shadow of the player is  
> a garbled
> rectangular on the floor, but you know that already I guess.

Thanks for pointing that out, but you're right - I noticed that, too,  
and I have an explanation. There are two aspects to consider, both  
are related to numerical precision, or, actually, a lack there of.  
The player shadow is basically a quad with a special partially  
transparent texture. It's placed on the floor and when doing  
rasterization rendered in a seperate pass after the world so blending  
works. As shadow and floor are aligned they end up with identical  
depth values on screen. The only reason for the player shadow to stay  
on top is because it is rendered last with a depth comparison of <=.  
If you would render the floor first (we're ignoring blending here)  
and then the shadow, you'd not see any pixels of the quad in the  
final image, because they would have been overwritten by then.
The problem with raytracing is that there's no order like this: All  
triangles are in memory at the same time and the raytracer basically  
returns the id of a hit triangle that is closest to the camera. When  
it comes to floor and shadow it cannot make a decision and you'll end  
up with a noisy pattern due to floating point imprecisions.
Furthermore as we need to perform alpha blending on the player  
shadow, we have to get its backcolor - the floor. We do this by  
spawning a secondary ray at the hit point with a slight offest along  
the direction vector to avoid self-intersection. Due to this offset  
we're not even guaranteed to hit the floor at all, so even if the  
player shadow ends up on top, it might be shaded with a missing or  
incorrect background.

That's a world of pain, isn't it? The only way to solve this problem  
will be adding an offset to all decals along their normal (away from  
the surface they rest on). Randomizing this offset avoids problems  
with decals that are in the same plane. I actually tried to do this  
in RE_AddPoly in tr_scene.c, but it either does not cover this case  
or is not working as expected.


> And finally the lighting is of course very different and sometimes  
> not what
> you would expect. Considering that quake3 was never meant to be  
> raytraced
> this is understandable.


Lighting is different because the lightmap is ignored and the camera  
is treated as a point light source. I actually planned on  
implementing a realtime photon mapper and ditch the lightmaps, but I  
never got around to it. I think I'll invest some time later today and  
add lightmap support.

There's also something important about the raytracing effects in the  
EF version: The only reason we actually get these is due to the fact  
that the shader compiler actively modifies the scripted shaders! It  
looks for the use of an environment map and replaces it with the  
reflected color at the intersection point. To add effects like these  
to Q3 you'll most definitely have to modify said lines in the shader  
compiler.

A better solution would be adding new keywords to the shader language  
and then modifying the scripts by hand. We could also add keywords  
for refraction (interesting for water!) and other new effects. But  
since this is a lot of work I decided to go the automated route for  
my thesis ...

I'm glad it works for you!
Stephan

Am 07.03.2008 um 03:02 schrieb Thilo Schulz:

> On Donnerstag, 6. März 2008, Stephan Reiter wrote:
>> Some screenshot goodness:
>> http://picasaweb.google.de/stephan.reiter/IoQuake3Raytraced
>>
>> Looking forward to hearing from the brave that try this, :-)
>> Stephan
>
> I managed to compile your code and tested it on my system of  
> course. Know
> also, apart from the not completely applyable part, that the patch  
> applied
> without any conflicts at all against my EliteForce stuff.
>
> A few things I noticed: the Quake3 game assets are a bit older than
> EliteForce's, and thus standard quake3 offers fewer opportunities  
> to show off
> the raytracing stuff.
> A few textures seem to be garbled. E.g. the shadow of the player is  
> a garbled
> rectangular on the floor, but you know that already I guess.
> And finally the lighting is of course very different and sometimes  
> not what
> you would expect. Considering that quake3 was never meant to be  
> raytraced
> this is understandable.
>
> It runs on my Athlon 64 3200 with about 2-3 fps at a resolution of  
> 800x600 :)
>
> As your videos were pretty small and not as much could be seen on  
> them I
> created a video with larger resolution, encoded using the ffmpeg h. 
> 264 codec.
> Mplayer or VLC should play it alright.
> Here's the link:
>
> http://thilo.tjps.eu/download/raytracing2.avi
>
> I rendered this at a resolution of 1024x768 using ioquake3's built- 
> in video
> recorder. Average framerate was about 1 fps :)
>
> -- 
> Thilo Schulz