Tenebrae 2

[Nick[FM]]

Do you guys remember Tenebrae that was kind of an "add-on" to Quake1? It added stencil shadows and per pixel lights (alá 3DMark03 ;) and DOOM III). Well, now the chaps are working on Tenebrae 2 which is for Q3A! They have posted some screenies, and IMHO it looks good. It seem still to be in an quite early stage (as I didn't spot any shadows in the shots), but by looking at what they did to Q1, I don't doubt that this version will be anything less than awesome!

http://tenebrae.sourceforge.net/index.php?page=screenshots21.txt


*edit: a link to their homepage for you lazy ones: http://tenebrae.sourceforge.net/ :)

[Tahir2]

Looks bloody awesome at this stage ;)

Could they do something similar to Unreal Tournament? If so why dont they!! (Sorry me prefers UT to Q3 .. heh)!

[LeStoffer]

It looks outstanding, but I fear for performance.

Anyway, they are using Cg (mainly for vertex shaders), which of course alarmed some on their forum. But there's apparently no need to panic for those who, ahhmm, doesn't think that highly of Cg.

By: jpaana ( Jarno Paananen )
RE: Tenebrae 2.0 CG et ATI
2003-01-30 07:50
There's one fanATIc guy in the team who will make sure ATI cards don't suffer from this decision (and I'm using Cg on my own projects too). Cg will probably be compiled offline and used mostly for vertex shaders using the ARB_vertex_program extension which basically all cards support. For pixel shaders the situation is a bit more complex and at least some of the stuff has to be handwritten anyway. So don't worry :-)

[Doomtrooper]

Quake 2 was worthwhile as it was actually fun to go through the game again after all these years, this MOD to Quake 3 doesn't have as much appeal for me at all.

[Nick[FM]]

Quake 2 was worthwhile as it was actually fun to go through the game again after all these years, this MOD to Quake 3 doesn't have as much appeal for me at all.
AFAIK, Tenebrae 1.x was for Quake1 and not Q2. :wink:

[Saem]

Could they do something similar to Unreal Tournament? If so why dont they!! (Sorry me prefers UT to Q3 .. heh)!

I don't think Tim Sweeny cares to share. From my understanding he hasn't released the source for build of the Unreal engine used in Unreal or Unreal Tournament. This is likely because a fair bit of the code is still in use in the build that's used in Unreal Tournament 2003 and Unreal 2.

[jpaana]

Well we don't have any Quake3 code in there, just using the same file formats. The engine code is still based on Quake 1 source.

[Doomtrooper]

Oops Quake 1..my bad.

[Reverend]

Great... now I have to re-install Quake3.

[epicstruggle]

Other than quake what other games have release their source code. If not mistaken half-life right? anyother?

later,

[Nick[FM]]

Great... now I have to re-install Quake3.
Same here! I hope I can find the CD somewhere.. :?

jpaana,

any word when Tenebrae 2 will be released? Even as an Alpha or Beta?

[Crusher]

Heretic and Hexen 1&2 have open source code, but the rendering portion shouldn't be all that different from Quake. Quake 2 is open source as well. Tribes 2 source code can be obtained cheap... that is if there's anyone left in charge of it to give you a license. That's all I can think of off the top of my head for retail game engines, though there are dozens of free, open source, amateur engines available.

[jpaana]

]Great... now I have to re-install Quake3.
Same here! I hope I can find the CD somewhere.. :?

jpaana,

any word when Tenebrae 2 will be released? Even as an Alpha or Beta?

There's actually no need for Quake 3 cd, we are aiming for standalone engine with all-custom art. The tools are Quake 3 ones and so are the fileformats, but with extensions especially in the shader language to support bumpmapping. Thus you can't run Quake 3 levels without some work.

Can't give any definite estimates about alpha or beta, you FM people should know that, when it's done of course :wink: The code in its current state is pretty much not ready for public consumption, though it is available from CVS and you can run customized Q3 maps with it even now.

[Nick[FM]]

There's actually no need for Quake 3 cd, we are aiming for standalone engine with all-custom art. The tools are Quake 3 ones and so are the fileformats, but with extensions especially in the shader language to support bumpmapping. Thus you can't run Quake 3 levels without some work.
Is the render engine also yours, or is it based on the Q1? or?

Can't give any definite estimates about alpha or beta, you FM people should know that, when it's done of course :wink: The code in its current state is pretty much not ready for public consumption, though it is available from CVS and you can run customized Q3 maps with it even now.
Hehe.. We always let our users know our release dates. What you say! :wink:

Do you guys btw, have any future plans for the Tenebrae "engine"? Lisense it etc?

[BoddoZerg]

Too bad I don't have Quake 3...

By the time its done, TeneBrae will look exactly like DOOM3. Planning on competing against id in the engine-licensing game? :p

[jpaana]

]
Is the render engine also yours, or is it based on the Q1? or?


Very loosely based perhaps, though there probably isn't any original rendering code left except for console and status bar or so possibly.

]
Hehe.. We always let our users know our release dates. What you say! :wink:

Do you guys btw, have any future plans for the Tenebrae "engine"?
Lisense it etc?

:)

Well as long are there is original GPL'ed Quake code included, which is pretty much still, especially in the game logic and utility stuff, we don't have much choice than to keep it GPL'ed. The current attitude in the team is that it's actually good as is. If someone wants to benefit from our work, they still have to share their own modifications, which in turn benefits us and the community at large. Even if someone bought commercial license to use the Quake code, our stuff is still under GPL so the same rule applies. So no, we aren't competing with id in that business (yet :wink: )

[Nick[FM]]

Well as long are there is original GPL'ed Quake code included, which is pretty much still, especially in the game logic and utility stuff, we don't have much choice than to keep it GPL'ed. The current attitude in the team is that it's actually good as is. If someone wants to benefit from our work, they still have to share their own modifications, which in turn benefits us and the community at large. Even if someone bought commercial license to use the Quake code, our stuff is still under GPL so the same rule applies. So no, we aren't competing with id in that business (yet :wink: )
Aaah, I see. Wouldn't it be reasonable to make such an engine 100% in-house? I'm not sure what you guys have planned and so, but it would sound like an pretty interesting idea to have an engine out there, which would be compatible with already familiar tools, and be very good tech wise, but still at a very affordable lisensing price. :wink: You all would actually get someting out of it, and by the look of your screenshots, it doesn't loose in IQ to the "big" engines out there. Ok, I haven't seen the performance of it, and (do correct me if I'm wrong) it seems that you guys don't have the shadows implemented (or turned on) yet? At least I didn't spot any in the shots..

Still, IMHO very interesting and cool work you guys are doing! 8)

[jpaana]

]
Aaah, I see. Wouldn't it be reasonable to make such an engine 100% in-house? I'm not sure what you guys have planned and so, but it would sound like an pretty interesting idea to have an engine out there, which would be compatible with already familiar tools, and be very good tech wise, but still at a very affordable lisensing price. :wink: You all would actually get someting out of it, and by the look of your screenshots, it doesn't loose in IQ to the "big" engines out there. Ok, I haven't seen the performance of it, and (do correct me if I'm wrong) it seems that you guys don't have the shadows implemented (or turned on) yet? At least I didn't spot any in the shots..

Still, IMHO very interesting and cool work you guys are doing! 8)

Yeah it might very well be reasonable if we weren't doing other stuff too :)
All of us have dayjobs or are studying fulltime so we aren't that interested in the financial side of it yet. We have thought of it though, but not very seriously. So for the time being GPL suits us fine.

As for performance and shadows. If you have tried "Tenebrae 1", we have the same performance with 10x polygons or so :) Well not quite, but very substantially faster anyway. Shadows are on in the shots, but not very easy to spot as there aren't any moving entities and even the flashlight is broken at the moment :) But it's there anyway.

[K.I.L.E.R]

How slow will it be? ;)
2fps at 1024x768 32bpp and 2x FSAA as well as 64 tap aniso?

[Tagrineth]

How slow will it be? ;)
2fps at 1024x768 32bpp and 2x FSAA as well as 64 tap aniso?

As for performance and shadows. If you have tried "Tenebrae 1", we have the same performance with 10x polygons or so Well not quite, but very substantially faster anyway.

;)

[Sxotty]

Too bad I don't have Quake 3...

By the time its done, TeneBrae will look exactly like DOOM3. Planning on competing against id in the engine-licensing game? :p

If you read it you don't need Quake3 to play it. Tenebrae 1 is awesome by the way. I hope this turns out as good. I hope they don't liscence it in a way, b/c if they do it encourges developers to be like UT and not release code. On the other hand JC has enough money already, and I am sure those guys could use more.

I prefer Id b/c they open source their stuff and I think their engines are more streamlined than UT.

[epicstruggle]

On the hardware side we will support all the current supported cards, and plan to use nVidia's CG to do vertex-pixel programs.

Quote from tenebrae site. Why use CG?

later,

[Luke Philpot]

Tenebrae 2 looks really, really good. I can't wait for a alpha/beta/demo :D

[BNA!]

Just in case that some readers here like to do some editing for tenebrae or other games using per pixel lighting via normal maps:

I've created 41 normal maps from high poly models which could be used in such rendering engines.
You can download them via my forum (registration is obligatory to prevent pure file leeching - don't worry, no spam...)

41 normal maps for download (http://www.doom3world.org/phpbb2/viewforum.php?f=33)

He's an example:

http://www.doom3world.org/doom3/d3f/shots/kat_rbump7.jpg

Have fun!

[jpaana]

On the hardware side we will support all the current supported cards, and plan to use nVidia's CG to do vertex-pixel programs.

Quote from tenebrae site. Why use CG?

later,

The better question is why not.

It's much easier, faster and less error prone to write the code first in clear syntax, take the compiler output, optimize it (Cg compiler isn't that good in some cases, generates extra moves and such) and use. If you fear that our code would somehow unfairly favor one IHV, you're mistaken...

Unless you have a better alternative in hand of course...

[epicstruggle]

If you fear that our code would somehow unfairly favor one IHV, you're mistaken...

Actually thats exactly why i fear it. Can you explain why it wont favor Nv, over Ati, im really curious. I have not looked at CG in detail so I might be abit ignorant in it. :)

later,

[jpaana]

If you fear that our code would somehow unfairly favor one IHV, you're mistaken...

Actually thats exactly why i fear it. Can you explain why it wont favor Nv, over Ati, im really curious. I have not looked at CG in detail so I might be abit ignorant in it. :)

later,

Well to us Cg is just a tool to convert this:

struct vertexOut {
float4 color : COLOR0;
float4 texCoord0 : TEXCOORD0;
float4 texCoord1 : TEXCOORD1;
};

struct fragment {
float4 col : COLOR;
};

fragment main( vertexOut I,
uniform sampler2D colorMap,
uniform sampler2D lightMap,
uniform sampler2D lumaMap)
{
fragment O;
float4 color = tex2D(colorMap, I.texCoord0.xy);
float4 light = tex2D(lightMap, I.texCoord1.xy);
float4 luma = tex2D(lumaMap, I.texCoord0.xy);
O.col = saturate(I.color * color * light + luma);

return O;
}

into this:

!!ARBfp1.0
# ARB_fragment_program generated by NVIDIA Cg compiler
# cgc version 1.0.0002, build date Dec 18 2002 14:00:35
# command line args: -profile arbfp1
#vendor NVIDIA Corporation
#version 1.0.02
#profile arbfp1
#program main
#semantic main.colorMap
#semantic main.lightMap
#semantic main.lumaMap
#var float4 I.color : $vin.COLOR0 : COLOR0 : 0 : 1
#var float4 I.texCoord0 : $vin.TEXCOORD0 : TEXCOORD0 : 0 : 1
#var float4 I.texCoord1 : $vin.TEXCOORD1 : TEXCOORD1 : 0 : 1
#var sampler2D colorMap : : texunit 0 : 1 : 1
#var sampler2D lightMap : : texunit 1 : 2 : 1
#var sampler2D lumaMap : : texunit 2 : 3 : 1
#var float4 col : $vout.COLOR : COLOR : -1 : 1
TEMP R0;
TEMP R1;
TEMP R2;
TEX R0, fragment.texcoord[0].xyxx, texture[0], 2D;
TEX R1, fragment.texcoord[1].xyxx, texture[1], 2D;
MUL R0, fragment.color.primary, R0;
TEX R2, fragment.texcoord[0].xyxx, texture[2], 2D;
MAD R2, R0, R1, R2;
MOV_SAT result.color, R2;
END

which we'd include in the code _after_ checking out it is reasonable. As you can see, the compiler isn't perfect yet, the last instruction can be removed and the second to last replaced with MAD_SAT result.color, R0, R1, R2;

This is just a simple example of the code we are using it for, it becomes harder to keep track of everything on a shader when the instruction counts rise.

This specific compiled version is for the ARB_fragment_program extension, which runs on R300 and NV30 cards at the moment (it could be considered the "native" extension of R300), but the same Cg code could be compiled for NVidia's or anyone's extensions too. True, at the moment there are no other extensions in the Cg compiler, but the source is available and actually I've been working on backends for the ATI vertex and fragment shader extensions for previous cards.

Anyway, sure we'd use a better program to do this but at the moment there really aren't alternatives and Cg works pretty well for the purpose we have for it.

[epicstruggle]

Ok, I think I get it now. :oops: I didnt realize what you were doing. Im curious what kinda performance increases are you getting from this?

later,

[jpaana]

Ok, I think I get it now. :oops: I didnt realize what you were doing. Im curious what kinda performance increases are you getting from this?

later,

If you mean by checking the compiler output, it's usually a few commands off, so no big deal.

If you mean compared to the old hand-coded assembler in Tenebrae 1, none, the code is just easier to maintain. We are adding lots of different shaders into Tenebrae 2 so this becomes a very important issue.

[epicstruggle]

so why do alot of people say that cg is bad(usually ati fans). i guess i thought that the output from the cg compiler would only run on nv hardware. (if i understand you, the ouput can be tweaked so that it runs on any hardware.)

thanks for taking time to answer my questions. Im still learning comp. graphics programming. THis shows me how far I still have to go.

later,

[jpaana]

so why do alot of people say that cg is bad(usually ati fans). i guess i thought that the output from the cg compiler would only run on nv hardware. (if i understand you, the ouput can be tweaked so that it runs on any hardware.)


I think most of the resistance to Cg is because it is done by NVidia, not because the compiler is bad or anything. Sure it could support more non-NVidia profiles, but it's quite understandable it doesn't, so far. Moving the control of Cg to some more neutral organization would probably help with that though. The compiler source if available from NVidia under pretty liberal license, so adding them isn't impossible, only the code is a bit heavy to understand at first.

There's no tweaking required as such to get the code to run on different platforms, especially if you use the D3D profiles, the code runs on all cards that have the capability to run that shader version. The OpenGL situation is a bit different as the only common extensions (ARB_*_program) are so new and advanced that only R300 and NV30 can run them. It's only that if you want the last bits of performance, you should check the code out and fix the easy stuff manually.

thanks for taking time to answer my questions. Im still learning comp. graphics programming. THis shows me how far I still have to go.

later,

Sure, no problem, good luck in you quest :)

[Rodéric]

TSEUH

ARB_fragment_program requires R300/NV30 but not ARB_vertex_program.

[jpaana]

TSEUH

ARB_fragment_program requires R300/NV30 but not ARB_vertex_program.

Yeah, my oversight. Actually I had "fragment" there instead of * but somehow ended up changing it...

Yeah, we'll probably move to use ARB_vertex_program on all platforms instead of the current vendor specific extensions. Thanks to Doom 3 it should be universally supported soon enough.

[Doomtrooper]

Well to us Cg is just a tool to convert this:

struct vertexOut {
float4 color : COLOR0;
float4 texCoord0 : TEXCOORD0;
float4 texCoord1 : TEXCOORD1;
};

struct fragment {
float4 col : COLOR;
};

fragment main( vertexOut I,
uniform sampler2D colorMap,
uniform sampler2D lightMap,
uniform sampler2D lumaMap)
{
fragment O;
float4 color = tex2D(colorMap, I.texCoord0.xy);
float4 light = tex2D(lightMap, I.texCoord1.xy);
float4 luma = tex2D(lumaMap, I.texCoord0.xy);
O.col = saturate(I.color * color * light + luma);

return O;
}

into this:

!!ARBfp1.0
# ARB_fragment_program generated by NVIDIA Cg compiler
# cgc version 1.0.0002, build date Dec 18 2002 14:00:35
# command line args: -profile arbfp1
#vendor NVIDIA Corporation
#version 1.0.02
#profile arbfp1
#program main
#semantic main.colorMap
#semantic main.lightMap
#semantic main.lumaMap
#var float4 I.color : $vin.COLOR0 : COLOR0 : 0 : 1
#var float4 I.texCoord0 : $vin.TEXCOORD0 : TEXCOORD0 : 0 : 1
#var float4 I.texCoord1 : $vin.TEXCOORD1 : TEXCOORD1 : 0 : 1
#var sampler2D colorMap : : texunit 0 : 1 : 1
#var sampler2D lightMap : : texunit 1 : 2 : 1
#var sampler2D lumaMap : : texunit 2 : 3 : 1
#var float4 col : $vout.COLOR : COLOR : -1 : 1
TEMP R0;
TEMP R1;
TEMP R2;
TEX R0, fragment.texcoord[0].xyxx, texture[0], 2D;
TEX R1, fragment.texcoord[1].xyxx, texture[1], 2D;
MUL R0, fragment.color.primary, R0;
TEX R2, fragment.texcoord[0].xyxx, texture[2], 2D;
MAD R2, R0, R1, R2;
MOV_SAT result.color, R2;
END

which we'd include in the code _after_ checking out it is reasonable. As you can see, the compiler isn't perfect yet, the last instruction can be removed and the second to last replaced with MAD_SAT result.color, R0, R1, R2;

This is just a simple example of the code we are using it for, it becomes harder to keep track of everything on a shader when the instruction counts rise.

This specific compiled version is for the ARB_fragment_program extension, which runs on R300 and NV30 cards at the moment (it could be considered the "native" extension of R300), but the same Cg code could be compiled for NVidia's or anyone's extensions too. True, at the moment there are no other extensions in the Cg compiler, but the source is available and actually I've been working on backends for the ATI vertex and fragment shader extensions for previous cards.

Anyway, sure we'd use a better program to do this but at the moment there really aren't alternatives and Cg works pretty well for the purpose we have for it.

I would assume the lack of PS 1.4 support in CG is not optimizing the shader for ATI cards including the 8500/9000/9100/9200 which would force these cards to use PS 1.1 and multi-pass even though the hardware is capable of not having to.

Carmack is using PS 1.4 in Doom 3, so I assume PS 1.4 is now exposed through a open ARB non-proprietary extension.

[jpaana]

I would assume the lack of PS 1.4 support in CG is not optimizing the shader for ATI cards including the 8500/9000/9100/9200 which would force these cards to use PS 1.1 and multi-pass even though the hardware is capable of not having to.

Carmack is using PS 1.4 in Doom 3, so I assume PS 1.4 is now exposed through a open ARB non-proprietary extension.

As I said above, the only generic OpenGL extensions supported by Cg are the ARB ones and especially the fragment shader needs a new card as it requires basically PS 2.0 level functionality with some extras. But there isn't such thing as PS x.y in OpenGL anyway. So we can't use Cg for PS 1.x cards, but the good thing is that all 1.x level functionality is simple enough that writing shaders in assembly is still viable (if not necessarily fun) and the reason we have handwritten code for NVidia's 1.1 level cards (Cg isn't quite enough for the tricks we need to make everything fit in the combiners), ATI's 1.4 level cards and Matrox's 1.3 level cards using the respective vendor extensions.

The only ways to use "PS 1.4"-level of functionality in OpenGL are still ATI's function call-based and text-based (only available on Mac OSX it seems though) extensions. There's no real reason to make a vendor neutral version as the only cards that can't additionally support the more advanced ARB extensions are ATI's and they can use the old extension. For the programmer, relying on new extensions and thus new drivers is a bit pain anyway, even for Carmack.

[Retro]

Hi, I´ve been enjoying tenebrae1 very much, any chance of an update on tenebrae2´s status ? Thanks :)

[Humus]

I think most of the resistance to Cg is because it is done by NVidia, not because the compiler is bad or anything.

Actually, it does generate suboptimal code. Especially for R300. This is the code you got:


TEMP R0;
TEMP R1;
TEMP R2;
TEX R0, fragment.texcoord[0].xyxx, texture[0], 2D;
TEX R1, fragment.texcoord[1].xyxx, texture[1], 2D;
MUL R0, fragment.color.primary, R0;
TEX R2, fragment.texcoord[0].xyxx, texture[2], 2D;
MAD R2, R0, R1, R2;
MOV_SAT result.color, R2;
END


In three of the lines you got .xyxx swizzles. These swizzle have no place whatsoever there. The Cg compiler is notoriously bad at spitting out swizzles all over the place, something that significantly hurt performance on R300, while leaving NV30 unaffected. If you really want to use Cg you'll have to be very aware of this and fix that in your shaders before release.
If official glslang support comes around soon I think you should look into that.

[jpaana]

I think most of the resistance to Cg is because it is done by NVidia, not because the compiler is bad or anything.

Actually, it does generate suboptimal code. Especially for R300. This is the code you got:


TEMP R0;
TEMP R1;
TEMP R2;
TEX R0, fragment.texcoord[0].xyxx, texture[0], 2D;
TEX R1, fragment.texcoord[1].xyxx, texture[1], 2D;
MUL R0, fragment.color.primary, R0;
TEX R2, fragment.texcoord[0].xyxx, texture[2], 2D;
MAD R2, R0, R1, R2;
MOV_SAT result.color, R2;
END


In three of the lines you got .xyxx swizzles. These swizzle have no place whatsoever there. The Cg compiler is notoriously bad at spitting out swizzles all over the place, something that significantly hurt performance on R300, while leaving NV30 unaffected. If you really want to use Cg you'll have to be very aware of this and fix that in your shaders before release.
If official glslang support comes around soon I think you should look into that.

Yup, quoting myself above


which we'd include in the code _after_ checking out it is reasonable. As you can see, the compiler isn't perfect yet, the last instruction can be removed and the second to last replaced with MAD_SAT result.color, R0, R1, R2;


Actually I've since used DX9 summer update HLSL compiler since, making the quite trivial conversion to ARB program is easier than fixing Cg code :wink:

Yup, I also have the shaders written in GLSlang, just waiting for a driver to actually test them :wink:

[MasterBaiter]

Hi, I´ve been enjoying tenebrae1 very much, any chance of an update on tenebrae2´s status ? Thanks :)

Ditto! :?:

[PeterAce]

Yup, I also have the shaders written in GLSlang, just waiting for a driver to actually test them :wink:

Can these GLSlang shaders be run on the "support" drivers (non-WHQL Catalyst 3.10 drivers?) :

http://www.beyond3d.com/forum/viewtopic.php?t=9107

I presume when the final WHQL Catalyst 3.10 drivers arive you will be also able to test them out as well.

Can you report on your results here? Thanks.

[jpaana]

Yup, I also have the shaders written in GLSlang, just waiting for a driver to actually test them :wink:

Can these GLSlang shaders be run on the "support" drivers (non-WHQL Catalyst 3.10 drivers?) :

http://www.beyond3d.com/forum/viewtopic.php?t=9107

I presume when the final WHQL Catalyst 3.10 drivers arive you will be also able to test them out as well.

Can you report on your results here? Thanks.

Yeah, they run for the most part but there seem to be issues with z invariance between the fixed function global pass and the per-light shaders. I'm in contact with ATI devrel to sort these out.

As for performance it's pretty hard to say as the GLSlang path isn't rendering the correct image but it seems to be roughly on par with the hand written ARB path.

[MasterBaiter]

An Industri-Alpha preview is up over here: http://industri.sourceforge.net/ :P

[Malo]

wow, quickly someone download this "leaked-alpha" and have a look! i'm at work.....

[PeterAce]

Yup, I also have the shaders written in GLSlang, just waiting for a driver to actually test them :wink:

Can these GLSlang shaders be run on the "support" drivers (non-WHQL Catalyst 3.10 drivers?) :

http://www.beyond3d.com/forum/viewtopic.php?t=9107

I presume when the final WHQL Catalyst 3.10 drivers arive you will be also able to test them out as well.

Can you report on your results here? Thanks.

Yeah, they run for the most part but there seem to be issues with z invariance between the fixed function global pass and the per-light shaders. I'm in contact with ATI devrel to sort these out.

As for performance it's pretty hard to say as the GLSlang path isn't rendering the correct image but it seems to be roughly on par with the hand written ARB path.

How are the Final WHQL Catalyist 3.10 drivers now?

[jpaana]

No change from the hotfix driver.