Tidbits on Id Software's next engine

[Intel17]

Well, I've had this e-mail from Brain Harris (really nice guy) of Id Software for a while, but haven't gotten around to posting these neat little tidbits about the next engine;


Yes, in the next engine everything pretty much is a variable. It's
rather easy to increase the samples and decrease the frame rate. You'll
find out a lot more about it this coming Quakecon. We've talked about
using CG, but for the moment everything is still in ASM.

- Brian


Very interesting how JC is using asm, rather than GLSL/Cg. I wonder why?

[991060]

There's no need to use high level language to write simple shaders as those found in DOOM3.

[Intel17]

This isn't for a game with shaders as simple as Doom 3. In fact, Carmack is apparently planning on going crazy with the amount of shaders, if you've listened to the QuakeCon 2004 speech. You'll be able to program things at the surface level like light interaction per-material, getting reflections just right etc., basically doing many surface models. He's also doing stuff like subsurface scattering, partial translucency, bloom effects using HDR.

Also, in an email from Rev (which he posted here), he said that most of the work on the engine is in shader programs, rather than any api-specific stuff.

[ZoinKs!]

Very interesting how JC is using asm, rather than GLSL/Cg. I wonder why?
Because The Carmack is an old school hacker and possibly the last of his kind. Or maybe he likes doing things the hard way. :?

edit: When's the next Quakecon?
edit2: August 11-14, 2005

[bloodbob]

Well Unreal3 uses asm too.

[Intel17]

Well Unreal3 uses asm too.

Well the shaders are written in HLSL/Cg and then compiled into asm at runtime, I believe.

[bloodbob]

Well Unreal3 uses asm too.

Well the shaders are written in HLSL/Cg and then compiled into asm at runtime, I believe.
In some interview they talked about stiching together bits of shader on the fly. I doubt they are stiching together HLSL and recompiling it on the fly I could be wrong though and I think it would be alot harder trying to do multipass decomposition of a shader automatically in a HLSL then doing it at the ASM level.

[991060]

There're probably 2 reasons:

1. Carmack doesn't trust the Cg/GLSL compiler. I believe there's no driver scored 100% in the GLSL parse test ATM. And Cg doesn't compile quite good on ATI HW.

2. He wants total control on the instruction count. When the shaders get too complex, you'll find yourself running out of instruction slots occasionally.

[Zeross]

This is strange because Carmack has been a big proponent of High Level Shading Language since 2002 when he first tested GLSL on a P10 :

The implementation went very smoothly, but I did run into the limits of their
current prototype compiler before the full feature set could be implemented.
I like it a lot. I am really looking forward to doing research work with this
programming model after the compiler matures a bit. While the shading
languages are the most critical aspects, and can be broken out as extensions
to current OpenGL, there are a lot of other subtle-but-important things that
are addressed in the full OpenGL 2.0 proposal.

I am now committed to supporting an OpenGL 2.0 renderer for Doom through all
the spec evolutions. If anything, I have been somewhat remiss in not pushing
the issues as hard as I could with all the vendors. Now really is the
critical time to start nailing things down, and the decisions may stay with
us for ten years.

A GL2 driver won't give any theoretical advantage over the current back ends
optimized for cards with 7+ texture capability, but future research work will
almost certainly be moving away from the lower level coding practices, and if
some new vendor pops up (say, Rendition back from the dead) with a next-gen
card, I would strongly urge them to implement GL2 instead of proprietary
extensions.

I have not done a detailed comparison with Cg. There are a half dozen C-like
graphics languages floating around, and honestly, I don't think there is a
hell of a lot of usability difference between them at the syntax level. They
are all a whole lot better than the current interfaces we are using, so I hope
syntax quibbles don't get too religious. It won't be too long before all real
work is done in one of these, and developers that stick with the lower level
interfaces will be regarded like people that write all-assembly PC
applications today. (I get some amusement from the all-assembly crowd, and it
can be impressive, but it is certainly not effective)

I do need to get up on a soapbox for a long discourse about why the upcoming
high level languages MUST NOT have fixed, queried resource limits if they are
going to reach their full potential. I will go into a lot of detail when I
get a chance, but drivers must have the right and responsibility to multipass
arbitrarily complex inputs to hardware with smaller limits. Get over it.

[bloodbob]

Yeah and where is it for doom 3? he either found out drivers weren't up to the task OR the hardware vendors pushed him no to use GLSL.

[Ragemare]

He mainly talks about using it in research work and I don't think writeing a shader in ASM(if you can call it that) as opposed to writeing it in GLSL is the same as writeing an application in ASM as opposed to C/C++/C# quite yet.

It could be that his next game has a relatively small amount of unique shader code that is stuck together in different sequences to make up the different material shaders. This is afterall what the U3E is doing?

[Chalnoth]

Yeah and where is it for doom 3? he either found out drivers weren't up to the task OR the hardware vendors pushed him no to use GLSL.
I'd say the timing didn't make sense.

[Gabrobot]

Doom 3 does have a render path that uses CG...I guess his research with that path didn't yield results convincing enough to make him switch.

[Chalnoth]

Well, Cg doesn't make sense for Doom3. How could it, with one single shader used for 95% of all pixel processing?

Higher-level languages make much more sense when you have a rendering system that requires more modularity in the shader design.

[Gabrobot]

Well, Cg doesn't make sense for Doom3. How could it, with one single shader used for 95% of all pixel processing?

Higher-level languages make much more sense when you have a rendering system that requires more modularity in the shader design.

Well yeah, what I meant was the path was in Doom 3 so he could play around with CG and see if it was worth switching to for his next engine...since he's still using ASM it seems he wasn't convinced.

[Richard]

The D3 expansion pack comes with CG versions of the interaction.vfp. I don't mind if their future game still has shaders in asm but I hope the engine will (better) support a HLSL for modders to learn quicker.

[Ostsol]

The D3 expansion pack comes with CG versions of the interaction.vfp. I don't mind if their future game still has shaders in asm but I hope the engine will (better) support a HLSL for modders to learn quicker.
Even better would be a material system that generates shaders based on parameters and other requirements. The best tools for designers are those that do not require them to do any programming at all.

[jpr27]

Amen Ostsol :D I dont see it coming in the short term but hopefully some day. Although many designers want more out of current tools and still use coders to help add to and push the envelope on what they envision or getting better results at a reduce cost :) (Flexability)

[Chalnoth]

Right, so what you really want is a system that not only doesn't require any programming to create shaders, but also has a very flexible interface for the programmers working on the game to add new shader modules for the artists to use. I'm currently expecting this to be the case with UE3's shader interface, but we'll have to see.

[Richard]

I'm currently expecting this to be the case with UE3's shader interface, but we'll have to see.

Agreed. Ease of use and power are not usually found running together in the same direction. My personal expectations is that while UE3's material editor will provide some ability to mix some premade effects with simple drag and drop operations, I doubt creating reasonably new surface interactions will be possible without resorting to "notepad". But something is better than nothing at all, obviously.

EDIT: ah yes:

The material framework is modular, so programmers can add not just new shader programs, but shader components which artists can connect with other components on-the-fly, resulting in dynamic composition and compilation of shader code.

[Gabrobot]

The D3 expansion pack comes with CG versions of the interaction.vfp.

Whoa, I hadn't noticed that...odd since I just checked Doom 3 and the Cg and Exp paths have been replaced with the Arb2 path (I assume since patch 1.2), so the game has no use for any Cg programs. I went back and ran Doom 3 1.1 with the Cg programs however, and it did work...no bumpmapping, though I assume that's due to the Cg program.

[Reverend]

There're probably 2 reasons:

1. Carmack doesn't trust the Cg/GLSL compiler. I believe there's no driver scored 100% in the GLSL parse test ATM. And Cg doesn't compile quite good on ATI HW.

2. He wants total control on the instruction count. When the shaders get too complex, you'll find yourself running out of instruction slots occasionally.
That's what I think too. I'll ask.

[Laa-Yosh]

BTW, id is hiring for an enviroment artist - with terrain building experience. Guess they're going to prove that they can do outdoors :)

[DeanoC]

1. Carmack doesn't trust the Cg/GLSL compiler. I believe there's no driver scored 100% in the GLSL parse test ATM. And Cg doesn't compile quite good on ATI HW.

Actually as pointed out by Humus on these very forums, ATI hardware actually does better on Cg code than HLSL at the moment due to Cg being more unoptimised, so ATI's back end is able to do a better job. Of course its possible that John doesn't know this as its pretty counter-intuitive...

[Gabrobot]

BTW, id is hiring for an enviroment artist - with terrain building experience. Guess they're going to prove that they can do outdoors :)

They also seem to be using ZBrush for modeling...

[Intel17]

BTW, id is hiring for an enviroment artist - with terrain building experience. Guess they're going to prove that they can do outdoors :)

Well of course, considering how Carmack is going out of his way to make sure shadowmaps work well in outdoor scenarios!

[Zeross]

They also seem to be using ZBrush for modeling...

They already used it for Doom III : Softimage|XSI for "basic" modeling and ZBrush for adding detail. Maya was used for the animation.

[Intel17]

They also seem to be using ZBrush for modeling...

They already used it for Doom III : Softimage|XSI for "basic" modeling and ZBrush for adding detail. Maya was used for the animation.

Perhaps the level of detail in the next game will be upped significantly because they're using ZBrush from the start?

[Gabrobot]

They already used it for Doom III : Softimage|XSI for "basic" modeling and ZBrush for adding detail. Maya was used for the animation.

I was under the impression they used Lightwave...I know that the guy who did the Imp and Cyberdemon (among other things) used Lightwave, because there was an interview with him on some Lightwave site.

[Colourless]

One of the Doom 3 preview videos even showed Lightwave being used.

[Zeross]

Hummm yes maybe it was Lightwave instead of Softimage, I will check.

[Laa-Yosh]

Id used mostly Lightwave for modeling, and Maya for animation. Nowadays, custom tools are the more important part of the art pipeline, as more and more time is spent with engine specific tasks - thus modeling and animation will work fine in most 3D packages.

[Zeross]

It was indeed Lightwave, sorry that's my bad.
Models generated with Lightwave are about 350 000 polygons, then ZBrush is used to add details and that number is pushed to 1.5 million polygons or more for certain models. These ultra high poly models are used to generate the normal map.