Tenebrae 2

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.

 

Quote from tenebrae site. Why use CG?

later,

 

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

 

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

He's an example:



Have fun!

 

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...

 

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.

 

Ok, I think I get it now. 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.

 

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,

 

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.

Sure, no problem, good luck in you quest

 

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.

 

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.

 

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

 

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

Code:

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

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

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

 

Ditto!

 

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.