Jump to content
  • Advertisement
  • entries
  • comments
  • views

Project: DOOM

DOOM: Post Mortem

Sign in to follow this  
Vilem Otte


For past 2 months there was a challenge running here on GameDev.net - this time I finally decided to participate.


I, as many others, remember DOOM as one of the first (if not first) 3D games that we have played. GROOM is inspired by DOOM, built upon custom in-house ray tracing library, it allows you to experience a small map rendered with path tracer. The single level design is inspired by level from DOOM 2 - Dead Simple.

This is not the only similarity with DOOM, having half-robot and half-demon spider-like enemy is another, and AI and behavior is also similar (enemies need to be 'activated' by shooting, otherwise they are not aggressive).


The whole idea of mine was bringing a real time path traced game (as DOOM was essentially a game using ray-casting). This whole had to begin with building a ray-tracer. Or to be precise a ray-tracer library that is fast enough to render complex environments at interactive frame rates. For this I was putting together something I will refer to as "OpenTracer" (subject name to change) - which ended up in OpenCL based library for ray-tracing.

If something went right, it is indeed this ray-tracing library. It actually ended up having quite interesting features like:

  • Support for BVH ray tracing (built using SAH, HLBVH, MULTI-LEVEL)
  • MULTI-LEVEL BVH being the most useful, allowing not just for dynamic scenes, but also instancing
  • BVHs (even bottom level) can be dynamically rebuilt (for characters with skeletal animation)
  • Semi-programmable pipeline (would need a bit of work, but still - possible)
  • Support for textures (building big texture atlas, which is then used during rendering)
  • Somewhat useful library interface (building 'data buffers', requesting BVH built for those, etc.)
  • Due to library design, it is technically re-usable
  • Etc.

I just went a bit ahead and wanted to try rendering some nice pictures, let me show an example here (of Crytek's sponza), the following image was rendered in under 1 second on AMD Radeon Rx 590 (interesting fact - it can run on Intel HD 620):


Fig. 01 - Sponza path traced (note, I have placed enemy from DOOM into it)

Other than that, what went right is actually finishing the project. With longer competitions (like 2-months ones) the original interest goes away after short time, and you need to keep working on the project to actually finish it.


If I can state which parts I'm not satisfied in the project - the list would be quite long. But first and foremost it is the scale of the level and having a lot more programmer's art than what I wanted. The actual art for the game was made within last 72 hours before final deadline, not sooner. Luckily the first thing I did was blocking out the design for the level:


Fig. 02 - Block out design of the level

Of course, having a good art requires time - so I had to make as much as fast as possible - most of the models ended up being blocky. Additionally to that I was probably saving way too much geometry to end up with high performance (the actual performance hit by having more triangles isn't really a problem ... as there is BVH acceleration structure - theoretically doubling the geometry adds just single additional level to it).

In the end I was actually able to build up most of the map, and an enemy (which has a hand made skeletal animation). Although not nearly at the quality I wanted.


I have hit the typical problem for most challenges or jams and that is - time management is critical (I have literally planned what to have finished by when - to actually be able to finish the game). Some deadlines were done long before, some few days after. But mostly I have kept to written features/dates and that helped me finish the project. Unlike Ludum Dares (in which I participate regularly) time management for longer project is different (additionally you also have to fit in work/business and family into it ... and yes, even recent Ludum Dare was put into the plans).

Apart from that, I've found out that handling dynamic scenes with ray-tracer is far harder compared to standard renderers like Direct3D (or even software rasterizeration ones). While I was working with ray-tracing a lot during my studies, I have actually never worked with fully dynamic scenes or dynamic deformable objects in it.


The challenge was actually quite interesting, I enjoyed it a lot (especially due to fact that I could work with ray-tracing). If you want to try it - go ahead and try playing the game.


Sign in to follow this  


Recommended Comments

There are no comments to display.

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!