Tidbits on Id Software's next engine
- Thread starter Intel17
- Start date
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.
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.
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.Intel17 said:
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.
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.
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?
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?
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 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.
Chalnoth said:
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:
Similar threads
