Doom 3 engine release and game code

[ceriux]

i read a bit back and someone said quake c is back ? so, will it be as easy to code for doom 3 as it is for quake?

[raynorpat]

Just finished most of my GLSL backend, so this should help somewhat. It's still missing environment bumpmapping and the ability to load custom GLSL shaders from a material.

I'm probably missing something in my shader implementation, since the flashlight acts strange on some materials.

Here's the ol' zip:
http://redyardgames.com/d3_glsl_backend.zip

[mh]

Just finished most of my GLSL backend, so this should help somewhat. It's still missing environment bumpmapping and the ability to load custom GLSL shaders from a material.

I'm probably missing something in my shader implementation, since the flashlight acts strange on some materials.

Here's the ol' zip:
http://redyardgames.com/d3_glsl_backend.zip

Nice one. I see you're not doing the alpha/red swizzle on the normal map in your FS though; you'll need to modify the texture loader for that.

I'm fairly committed to writing an ASM to HLSL converter right now, but time pressures are so far preventing me from making much progress. That might be useful for you or others at some point in the future.

[revelator]

Gonna ask ID on the bethesda blog how there stance is on using exsisting glsl shaders for reference.
With some luck i can maybe persuade them to release the glsl parts as part of the sdk (would be a huge help for beginners).

[raynorpat]

I see you're not doing the alpha/red swizzle on the normal map in your FS though; you'll need to modify the texture loader for that.

Ah, good call. I just updated the zip, so my interaction shader is more or less complete for now.

I can tell the difference as well without the specular LUT and the normailization cubemap, a lot less noisy for sure.

[mh]

I can tell the difference as well without the specular LUT and the normailization cubemap, a lot less noisy for sure.

Yeah, it's slightly subtle in that it doesn't impact in any radical way on the overall scene, but I think it looks awesome, everything is just so solid and clean.

[silverjoel]

Here's the source that can be compiled with VC++ Express. This was the iodoom3 guys idea, I just put it together.

https://sites.google.com/site/quakeupda ... ects=0&d=1

You need to compile it as debug without tools or release without tools.

[leileilol]

can sum1 port 2 the psp.

also port it 2 dreamcast as the dreamcast is most powerful video game console #1

[revelator]

i predict smoldering nah i guess most of the heavy stuff can be disabled the voodoo II port was a fine example of that.

[nbohr1more]

What do you think of this ATI paper about using Render to Vertex Buffer (R2VB) for dynamic shadow volume creation on the GPU (amongst other things) for DX10 style rendering on DX9 hardware:

http://www.csee.umbc.edu/~olano/s2006c0 ... ermann.pdf

???

[nbohr1more]

Not to spam this thread with tech demos (etc)... but what do you think of Humus's "Shadows that Rock" implementation for Shadow Mapping?

http://www.humus.name/index.php?page=3D&ID=28

[mankrip]

also port it 2 dreamcast as the dreamcast is most powerful video game console #1

Hellllllllllllll YEAH!

[mh]

Not to spam this thread with tech demos (etc)... but what do you think of Humus's "Shadows that Rock" implementation for Shadow Mapping?

http://www.humus.name/index.php?page=3D&ID=28

Bad aliasing on the shadow edges.

These demos typically only use a single light source and a relatively low poly count ("shadows that rock" actually has two lights). That's fine for a demo but Doom 3 can have multiple light sources and a much higher poly count so I'd question if it's reasonable to implement such a technique. It would also require a raising of the hardware specs beyond what the original engine required.

[nbohr1more]

Thanks for the feedback.

I've always thought Humus was one of the best at squeezing performance out of ATI hardware so it's a little surprising to hear his implementation wouldn't fare favorably.

(I guess it's easy to pull good FPS in these types of demos. )

I am still more curious about that R2VB method. I wanna see what Doom 3 runs like when every part of Stencil Volume is done on the GPU (including silhouettes).

I've been curious about this concept ever since I heard the first crabby rants about the CPU expense of the shadows over at Beyond3D after the game was released.

Is it worth being curious about it, or is that method also flawed in some way?

----

One other thing on the topic of maxing-out DX9 SM2.0 as a low-end target:

What do you think of using Alpha Test shaders to implement Dynamic Branching on SM 2.0 hardware?

http://www.humus.name/index.php?page=3D&ID=50

[mh]

Doom 3 doesn't use branching in it's shaders, but there are a few other tricks you can do to simulate branching, like the MAX and MIN instructions.

Big problem with dynamic branching simulation using alpha test or stencil test is that it won't work with early-Z rejection as it depends on the fragment shaders executing. You'd get better performance out of Doom 3 by tweaking it to be early-Z friendly (in particular as it does a Z prepass and so is otherwise ideally set up for it - just that pesky stencil buffer use for everything kinda ruins it ).

None of that would have been an option when Doom 3 was originally developed as early Z in hardware didn't really exist at the time.

Second big problem about simulating branching with alpha test or stencil test is that it has to coexist peacefully with any other alpha test or stencil test that the engine does - and Doom 3 does a lot of both.

All academic however as the OpenGL asm shaders that Doom 3 used don't support branching anyway, and so Doom 3 doesn't need to use any kind of dynamic branching tricks.