Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
tempun

DoomTracer

Recommended Posts

Recently, when looking at ChocoDoom's SF.net page, I stumled across this DoomTracer thing. Basically current version is a ray-tracing renderer + Chocolate Doom.
It looks good, but gives me only a few frames per second.
The Doom part of it is utterly broken:
Requires a 269Mb data pack which consists of DHTP + some other textures, and music (WTF? I have DHTP and I don't need their music!). Only works with DOOM.WAD in its folder; seemingly doesn't support any IWAD except for DOOM.WAD, or PWADs.

Share this post


Link to post

The screenshots are very interesting. It's strange and a shame that it requires that data pack.

Share this post


Link to post
audiodef said:

I looked at the screenshots. What exactly am I looking at?

Chocolate Doom with a ray-tracing renderer. The first screenshot shows it the best - see the dynamic lights they added in the ceiling and the corresponding shadows around the crates?

Share this post


Link to post

Doesn't Doomsday do a pretty good job of dynamic lighting? Light ceiling fixtures glow, health bottles glow, explosions have a nice aura, etc.

Share this post


Link to post
audiodef said:

Doesn't Doomsday do a pretty good job of dynamic lighting? Light ceiling fixtures glow, health bottles glow, explosions have a nice aura, etc.

There's no real shadows, for example.

Share this post


Link to post

Not the same thing at all. The interesting part is the shadows the light casts, not the light itself. Doomsday can't do shadows like that.

I have a friend who is in grad school for graphics with a heavy emphasis on ray tracing, so I know a bit about the subject (I thought it was a fun project when I did it myself in school). I've thought about ray traced Doom before, but ultimately Doom is not a very good fit.

A ray tracer is great for:
* shadows from point light sources
* reflections/refractions/translucency (glass, water, etc)
* complex geometry (the geometrical complexity doesn't have nearly as much impact on speed as with a rasterizer)
* spheres (everyone's favorite RT example)

Doom has none of these things. Additionally, it has some unique drawbacks:
* sprites instead of models, so no interesting shadows there
* flat textures with no bump/displacement maps
* a quirky renderer that is difficult to emulate by other means

If this DoomTracer thing had done nothing to the ChocolateDoom engine you would never be able to tell any visual difference between it and the normal renderer (other than it running orders of magnitude slower and not supporting some of the odd visual hacks people use).

Yeah, you could add stuff to Doom to get some benefit out of using a ray tracer, but then why bother doing it will Doom in the first place? There is nothing in vanilla Doom (unlike say, the dynamic lights in Quake 1) that would benefit from ray tracing.

There's also the massive speed issue. Intel has the fastest ray tracer around that they occasionally bring out for a dog and pony show to hype up their latest hardware, but even that one is extremely slow compared to a traditional rasterized renderer.

Ultimately DoomTracer is just an interesting experiment with no real practical value, similar to the horizontal renderer discussion going on.

Share this post


Link to post

I would argue that the main benefit of a ray-traced Doom wouldn't be the shadows or refractions/translucency, but rather the advanced techniques that ray tracing opens up, such as global illumination. (To be fair Doomsday does try to do something in that direction using "fake radiosity" but the results are... mixed, in my opinion.)

Share this post


Link to post

Actually, Doomsday does do global illumination and dynamic shadow casting as part of the new Bias lighting model. Its not enabled by default because still needs work but is available to play with in any recent beta release.

FakeRadio isn't meant to provide a complete solution to global illumination. This feature aims to model but one small part of a more refined lighting equation.

Bias lighting is designed to be used in combination with FakeRadio. Bias handles the large scale dynamic effects; e.g., a large/dominant light source passing behind a building casting shadows onto the rest of the map. FakeRadio deals with the smaller (mostly static) transfer/bounce-like shadows.

In addition to large-scale lighting effects the Bias lighting model implements "smoothed sector lighting". What this does is interpolate sector lighting values across adjacent sectors. Removing the "hard light edges" between sectors with different values.

Share this post


Link to post

Since I'm now the only person working on this DoomTracer project I thought I should comment.

My original goal wasn't to make anything that was practical or ground-breaking -- it was just an interesting project to me. And while Doom wasn't created for ray tracing, I thought it would be more interesting to see what ray tracing could do for it. Also, I wanted people to learn more about this rendering style by having some code people could play around with (maybe that is practical? I don't know). The problem with some raytraced demos using id engines (Quake 3/4) is that they seemed unavailable, unlike the raytracing demos released here: http://igad.nhtv.nl/~bikker/

As a result of using an ancient game I had to use some creativity by writing code that would automatically place lights throughout the level, make slime/water reflective and spectres refractive.

Also, the comment "If this DoomTracer thing had done nothing to the ChocolateDoom engine you would never be able to tell any visual difference between it and the normal renderer" isn't accurate or fair because when I first started developing DoomTracer, Chocolate Doom wasn't even in the picture. I was able to render levels with lighting and reflective effects. Chocolate Doom was included so that I could have something playable.

Share this post


Link to post
blarghon said:

Also, the comment "If this DoomTracer thing had done nothing to the ChocolateDoom engine you would never be able to tell any visual difference between it and the normal renderer" isn't accurate or fair because when I first started developing DoomTracer, Chocolate Doom wasn't even in the picture. I was able to render levels with lighting and reflective effects. Chocolate Doom was included so that I could have something playable.

What I meant is that there is no 'out of the box' visual feature of Doom that benefits from raytracing*. Point-source lights and reflective effects are something you added to the game.

I'm still curious why you picked Doom of all things - Quake 1 seems much more suited to this.

* I had forgotten about the spectres, though. Mind posting a screenshot of a refractive spectre? :)

Share this post


Link to post
david_a said:

What I meant is that there is no 'out of the box' visual feature of Doom that benefits from raytracing*. Point-source lights and reflective effects are something you added to the game.


He could have tried using Doomsday or GZDoom instead as a base, so there would be levels available using pre-placed sources of light and other stuff (models, reflective surfaces, translucent volumes, etc.) but it would probably have been much more complicated to code given that the ray-tracing renderer would have had to support many other features too.

Share this post


Link to post
david_a said:

What I meant is that there is no 'out of the box' visual feature of Doom that benefits from raytracing*. Point-source lights and reflective effects are something you added to the game.

I'm still curious why you picked Doom of all things - Quake 1 seems much more suited to this.

* I had forgotten about the spectres, though. Mind posting a screenshot of a refractive spectre? :)


Fair enough.

Well I picked Doom because I thought the simple world, with it's 2D BSP for instance, would make rendering super-fast. That's not the case however, and creating a 3D world out of one that is represented by a 2D data structure (no rooms above rooms) results in some kludges here and there.

Quake 1 would probably have been better because I could replace the lightmaps with "real" lights and add refraction/reflection to the liquids. I just wonder how fast the first Quake would run under raytracing. Most desktops only have two cores nowadays and that probably wouldn't cut it. I'm guessing that CPU/GPU hybrid solution would work best.

Here are a couple of spectre shots:
http://idav.ucdavis.edu/~ssshafii/images/doomtracer_screenie12.png
http://idav.ucdavis.edu/~ssshafii/images/doomtracer_screenie13.png (looks a bit strange because there are multiple spectres)

He could have tried using Doomsday or GZDoom instead as a base, so there would be levels available using pre-placed sources of light and other stuff (models, reflective surfaces, translucent volumes, etc.) but it would probably have been much more complicated to code given that the ray-tracing renderer would have had to support many other features too.


Pretty much. It's not super-difficult to modify Chocolate doom because it's mostly straight-forward C code with little abstraction. And the features are minimal. There are still a few bugs that appeared when DoomTracer got mated with Chocolate doom (like holes in the geometry that pop up and disappear right away) though.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×