Doom 3 engine release and game code
Moderator: InsideQC Admins
Re: Doom 3 engine release and game code
hehe seems so im not sure if its part of that map but else it looks normal 
heres one from Doom3 itself same options

i gues some will like the less plasticy effect
heres one from Doom3 itself same options
i gues some will like the less plasticy effect
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
Neat stuff. How does Doom 3 look in GLSL without all these fancy shaders? (can you take some screenies please) I'd like to see if heat haze and glass works already, and portal sky 
- motorsep
- Posts: 231
- Joined: Wed Aug 02, 2006 11:46 pm
- Location: Texas, USA
Re: Doom 3 engine release and game code
that part not yet done so i guess they wont work yet
but ill take some screenies of it with the new backend for the curious.
Sikk has made some additions in that regard but atm his code crashes doom3 and noone seem to have made glsl versions for those effects yet so even if the backend could load them i couldnt show you
.
Sikk has made some additions in that regard but atm his code crashes doom3 and noone seem to have made glsl versions for those effects yet so even if the backend could load them i couldnt show you
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
haze seems to work but i noticed the spirit portal in the first room when you enter hell shows no spirits hmm ???

Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
Think i have to explain why the glsl shaders are not there yet 
The code you saw in the previous post gets its registers directly from the vertex and fragment shaders but cubemaps glasswarp etc gets it from the material shader parser.
So whats needed is an interface to get the correct registers from there as well as glsl specific code to handle those extensions. Atm only arb2 has those extensions in draw_common.cpp.
One would wonder then why not just let the ARB2 backend handle those ? well for one when the glsl backend is enabled the ARB2 backend is not so none of these extentions ever get used.
Furthermore disabling the check for the ARB2 backend to force it messes up stuff so you get a weird viewport effect because both backends will try and draw the same stuff (bit like standing in front of a mirror and holding another mirror behind you. So lots of smaller images going back into infinity. It looks totally crap
then comes the problem with missing vertex and fragment shaders to do what ARB2 does, so far noone has made any as far as i know so even if the backend supported them it wouldnt work
Those shaders are not code in the engine there more like text files with instructions to tell the backend what to do and if missing the backend will just disable those extentions and do nothing at all.
ATm im studiying Sikks code to get an idea of expanding the registers to handle more stuff but even his version has no material interaction with the glsl backend yet.
The code you saw in the previous post gets its registers directly from the vertex and fragment shaders but cubemaps glasswarp etc gets it from the material shader parser.
So whats needed is an interface to get the correct registers from there as well as glsl specific code to handle those extensions. Atm only arb2 has those extensions in draw_common.cpp.
One would wonder then why not just let the ARB2 backend handle those ? well for one when the glsl backend is enabled the ARB2 backend is not so none of these extentions ever get used.
Furthermore disabling the check for the ARB2 backend to force it messes up stuff so you get a weird viewport effect because both backends will try and draw the same stuff (bit like standing in front of a mirror and holding another mirror behind you. So lots of smaller images going back into infinity. It looks totally crap
Those shaders are not code in the engine there more like text files with instructions to tell the backend what to do and if missing the backend will just disable those extentions and do nothing at all.
ATm im studiying Sikks code to get an idea of expanding the registers to handle more stuff but even his version has no material interaction with the glsl backend yet.
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
Had a look at justin marshall code and noticed he uses a different approach to glsl basically merging it with the ARB2 backend to handle the same materials quite a nice idea actually.
The downside is that his code will take a humongus effort to port for Doom3 :S as he totally rewritten the entire rendering system. Tbh im not sure im good enough to take on that feat
The downside is that his code will take a humongus effort to port for Doom3 :S as he totally rewritten the entire rendering system. Tbh im not sure im good enough to take on that feat
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
Switching between GLSL and ARB assembly at runtime is something that's theoretically possible, but I'd feel a little nervous doing it on some platforms. In other words - I'd expect it to work on NVIDIA as they can take some of the most awful programmer abuse (lesson #1 in "why you should not develop on NVIDIA"), it should work on AMD but I wouldn't rely on it, and as for Intel - gettouttahere...!
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-

mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
Re: Doom 3 engine release and game code
I made a mistake it seems after reading more into the code i see he replaced the entire arb backend + materials with glsl
i cannot get the darn thing to compile though as he added a managed code entry to the editor code and my compiler chokes a lot on some missing stuff.
the interaction shader as it looks from his game
i cannot get the darn thing to compile though as he added a managed code entry to the editor code and my compiler chokes a lot on some missing stuff.
the interaction shader as it looks from his game
- Code: Select all
// Interaction.crp (c) 2012 BM Studios
//
#include "renderprogs/common.crp"
#include "renderprogs/tr_rprogshared.h"
#ifdef DOOM_FORWARD_RENDERER
varying vec3 var_Vertex;
#endif
varying vec2 var_TexDiffuse;
varying vec2 var_TexNormal;
varying vec2 var_TexSpecular;
#ifdef DOOM_FORWARD_RENDERER
varying vec4 var_TexLightProj;
varying vec2 var_TexLightFalloff;
varying mat3 var_TangentToWorldMatrix;
varying mat3 var_TangentToWorldMatrixInv;
#endif
varying vec4 var_Color;
#ifdef DOOM_FORWARD_RENDERER
varying vec3 var_ViewDir;
#endif
varying vec3 var_Normal;
VertexProgram
attribute vec4 attr_TexCoord;
attribute vec4 attr_Tangent;
attribute vec4 attr_Binormal;
attribute vec4 attr_Normal;
#ifdef DOOM_FORWARD_RENDERER
uniform vec4 u_lightProjectionS;
uniform vec4 u_lightProjectionT;
uniform vec4 u_lightProjectionQ;
uniform vec4 u_lightFalloff;
uniform vec4 u_viewOrigin;
#endif
uniform vec4 u_colorModulate;
uniform vec4 u_colorAdd;
uniform vec4 u_diffuseMatrixS;
uniform vec4 u_diffuseMatrixT;
//
// Main - Entry Point
//
void main() {
gl_Position = ftransform( );
// transform position into world space
#ifdef DOOM_FORWARD_RENDERER
var_Vertex = ( gl_ModelViewMatrix * gl_Vertex ).xyz;
mat4 textureMatrix = mat4( u_diffuseMatrixS, u_diffuseMatrixT, vec4( 0, 0, 1, 0 ), vec4( 0, 0, 0, 1 ) );
#else
mat4 textureMatrix = mat4( vec4( 1, 0, 0, 0 ), vec4( 0, 1, 0, 0 ), vec4( 0, 0, 1, 0 ), vec4( 0, 0, 0, 1 ) );
#endif
// diffuse map texgen
var_TexDiffuse.xy = ( textureMatrix * attr_TexCoord ).st;
// specular map texgen
var_TexSpecular.xy = ( textureMatrix * attr_TexCoord ).st;
// normal map texgen
var_TexNormal.xy = ( textureMatrix * attr_TexCoord ).st;
#ifdef DOOM_FORWARD_RENDERER
// light projection texgen
var_TexLightProj.x = dot( u_lightProjectionS, gl_Vertex );
var_TexLightProj.y = dot( u_lightProjectionT, gl_Vertex );
var_TexLightProj.w = dot( u_lightProjectionQ, gl_Vertex );
// light falloff texgen
var_TexLightFalloff.x = dot( u_lightFalloff, gl_Vertex );
var_TexLightFalloff.y = 0.5;
// construct tangent-space-to-world-space 3x3 matrix
var_TangentToWorldMatrix = mat3(attr_Tangent.xyz, attr_Binormal.xyz, attr_Normal.xyz);
var_TangentToWorldMatrixInv = transpose(var_TangentToWorldMatrix);
var_Normal = attr_Normal.xyz;
#endif
#ifdef DOOM_FORWARD_RENDERER
var_ViewDir = var_TangentToWorldMatrixInv * normalize( u_viewOrigin.xyz - var_Vertex );
// primary color
var_Color = vec4( 0, 0, 0,0 ) * u_colorModulate + u_colorAdd;
#else
// primary color
var_Color = gl_Color * u_colorModulate + u_colorAdd;
#endif
}
EndVertexProgram
FragmentProgram
uniform sampler2D u_normalTexture;
uniform sampler2D u_lightFalloffTexture;
uniform sampler2D u_lightProjectionTexture;
uniform sampler2D u_diffuseTexture;
uniform sampler2D u_specularTexture;
uniform sampler2D u_unlitTransparentTexture;
#ifndef DOOM_FORWARD_RENDERER
uniform sampler2D u_vertTexture;
uniform sampler2D ShadowMap;
#else
uniform vec4 u_lightOrigin;
uniform vec4 u_diffuseColor;
uniform vec4 u_specularColor;
#endif
#ifndef DOOM_FORWARD_RENDERER
uniform vec4 u_viewOrigin;
uniform mat4 u_viewmat;
#endif
uniform int diffuseOnly;
// traditional lambertian blinn-phong lighting model
vec4 lightingModel( vec4 diffuse, vec4 specular, vec3 L, vec3 V, vec3 N, vec3 H, vec4 shadow ) {
specular *= 0.1;
diffuse *= 0.2;
float NdotL = clamp( dot( N , L ), 0.1, 1.0 ) ;
float NdotH = pow( max( dot( N, H ), 0.0001 ), 16 ) ;
return ( diffuse * NdotL ) + (specular * NdotH);
}
vec4 LightPass( float lightNum, vec4 var_Vertex, vec2 vCurrOffset, vec4 u_lightOrigin, vec4 diffuse, vec4 u_specularColor, vec4 u_lightProjectionS, vec4 u_lightProjectionT, vec4 u_lightProjectionQ, vec4 u_lightFalloff, vec4 shadow ) {
#ifndef DOOM_FORWARD_RENDERER
vec4 var_TexLightProj;
vec2 var_TexLightFalloff;
vec3 N = texture2D( u_normalTexture, var_TexNormal.st).xyz;
vec3 var_ViewDir = normalize(u_viewOrigin.xyz - var_Vertex.xyz ).xyz;
#endif
float d2 = length(u_lightOrigin.xyz - var_Vertex.xyz ) * u_lightProjectionS.x ;
// vCurrOffset *= vec2( 0.3, 0.3 );
// vec4 diffuse = texture2D( u_diffuseTexture, var_TexNormal.st + vCurrOffset );
// compute light direction in world space
vec4 u_lightOrigin2 = vec4(1,1,1,1) * mat4(u_lightProjectionS, u_lightProjectionT, u_lightProjectionQ, u_lightFalloff );
float d = length((u_lightOrigin.xyz ) - (var_Vertex.xyz / var_Vertex.w));
#ifdef DOOM_FORWARD_RENDERER
vec3 L = normalize( u_lightOrigin.xyz - var_Vertex.xyz );
#else
vec3 L = normalize(u_lightOrigin.xyz - var_Vertex.xyz );
#endif
//height = height * 0.04f + -0.03f;
//vec2 newTexCoord = var_TexDiffuse.st + (height * V.xy);
// transform normal, view, and light direction
#ifdef DOOM_FORWARD_RENDERER
// compute normal in tangent space from normalmap
N = normalize(2.0 * ( texture2D( u_normalTexture, var_TexNormal.st + vCurrOffset ).xyz - 0.5 ));
N = var_TangentToWorldMatrix * N;
// V = var_TangentToWorldMatrix * V;
L = var_TangentToWorldMatrix * L;
#endif
// compute half angle in world space
vec3 H = normalize( L + var_ViewDir );
// compute the specular term
#ifdef DOOM_FORWARD_RENDERER
vec4 specular = texture2D( u_specularTexture, var_TexNormal.st + vCurrOffset );
#else
float s = texture2D( u_normalTexture, var_TexNormal.st + vCurrOffset ).a;
vec4 specular = vec4( s, s, s, s );
#endif
specular *= u_specularColor;
// compute light projection and falloff
// vec4 lightProjection = texture2DProj( u_lightProjectionTexture, var_TexLightProj.xyw );
// vec4 lightFalloff = texture2D( u_lightFalloffTexture, var_TexLightFalloff );
// compute lighting model
//color *= lightProjection;
//color *= lightFalloff;
vec3 dm = normalize(vec3(d,d,d));
vec4 color = lightingModel( diffuse * var_Color , specular * var_Color, L, var_ViewDir, N, H, shadow );
d = sqrt(d) * 8;
float atten = 23000 / ( d * d2 + d2 * d * d);
color *= atten ;
return color;
}
// vec4 LightPass( vec4 u_lightOrigin, vec4 u_diffuseColor, vec4 u_specularColor, vec4 u_lightProjectionS, vec4 u_lightProjectionT, vec4 u_lightProjectionQ, vec4 u_lightFalloff )
const float blurSize = 1.0/1024.0; // I've chosen this size because this will result in that every step will be one pixel wide if the RTScene texture is of size 512x512
const float blurSizeh = 1.0/1024.0; // I've chosen this size because this will result in that every step will be one pixel wide if the RTScene texture is of size 512x512
vec4 BlurPixelH( sampler2D u_diffuseTexture, vec2 vTexCoord ) {
vec4 sum = vec4(0.0);
// blur in y (vertical)
// take nine samples, with the distance blurSize between them
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x - 4.0*blurSize, vTexCoord.y)) * 0.05;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x - 3.0*blurSize, vTexCoord.y)) * 0.09;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x - 2.0*blurSize, vTexCoord.y)) * 0.12;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x - blurSize, vTexCoord.y)) * 0.15;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y)) * 0.16;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x + blurSize, vTexCoord.y)) * 0.15;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x + 2.0*blurSize, vTexCoord.y)) * 0.12;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x + 3.0*blurSize, vTexCoord.y)) * 0.09;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x + 4.0*blurSize, vTexCoord.y)) * 0.05;
return sum;
}
vec4 BlurPixelV( sampler2D u_diffuseTexture,vec2 vTexCoord ) {
vec4 sum = vec4(0.0);
// blur in y (vertical)
// take nine samples, with the distance blurSize between them
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y - 4.0*blurSizeh)) * 0.05;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y - 3.0*blurSizeh)) * 0.09;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y - 2.0*blurSizeh)) * 0.12;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y - blurSizeh)) * 0.15;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y)) * 0.16;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y + blurSizeh)) * 0.15;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y + 2.0*blurSizeh)) * 0.12;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y + 3.0*blurSizeh)) * 0.09;
sum += texture2D( u_diffuseTexture, vec2(vTexCoord.x, vTexCoord.y + 4.0*blurSizeh)) * 0.05;
return sum;
}
//
// UnlitTransparent
//
vec3 UnlitTransparent() {
vec4 transparent = texture2D( u_unlitTransparentTexture, var_TexNormal.st ) ;
return transparent.xyz ;
}
vec4 CalcBloom()
{
vec4 sum = vec4( 0, 0, 0, 0 );
vec4 sum2 = vec4( 0, 0, 0, 0 );
vec2 texcoord = var_TexDiffuse;
int j;
int i;
for( i= -2 ;i < 2; i++)
{
for (j = -2; j <2; j++)
{
sum += BlurPixelV( u_diffuseTexture, texcoord + vec2(i, j)*0.003) * 0.25;
sum += BlurPixelH( u_diffuseTexture, texcoord + vec2(i, j)*0.003) * 0.25;
}
}
vec4 vWeightsBW = vec4 ( 1.1,1.06,1.11,0 );
vec4 vWeightsSepia = vec4 ( 0.7,0.6,0.7,1 );
vec4 cColor = texture2D( u_diffuseTexture, var_TexNormal.st );
vec4 bloom = sum*sum*0.2 * cColor;
bloom += cColor ;
float brightness=dot( cColor,vWeightsBW );
vec4 temp = brightness * vWeightsSepia;
//vec4 depthrgb = tex2D( depthSample, texcoord );
//float depthinfluence = pow( depthrgb, 128.0 );
sum = BlurPixelH( u_diffuseTexture, var_TexDiffuse ) + BlurPixelV( u_diffuseTexture, var_TexDiffuse );
vec4 res = sum + (bloom ) * temp ;
vec4 diffuse = texture2D( u_diffuseTexture, var_TexNormal.st );
return (res * bloom +bloom + temp );
}
//
// main
//
void main( void ) {
vec4 color = vec4(0,0,0,1);
vec4 diffuse = CalcBloom();
vec4 var_Shadow = BlurPixelV( ShadowMap, var_TexNormal.st );
var_Shadow += BlurPixelH( ShadowMap, var_TexNormal.st );
var_Shadow.r = clamp( 1 - var_Shadow.r, 0.0, 1) * 0.5;
if(var_Shadow.r < 0) {
var_Shadow.r = 0;
}
if(var_Shadow.g == 0) {
var_Shadow = vec4(1,0,0,1);
}
vec4 var_Vertex = texture2D( u_vertTexture, var_TexNormal.st );
vec3 N = texture2D( u_normalTexture, var_TexNormal.st).xyz;
vec3 var_ViewDir = normalize(u_viewOrigin.xyz - var_Vertex.xyz ).xyz;
// Calculate the parallax offset vector max length.
// This is equivalent to the tangent of the angle between the
// viewer position and the fragment location.
float fParallaxLimit = length( var_ViewDir.xy );
float fHeightMapScale = 0.1;
int nMaxSamples = 73;
int nMinSamples = 32;
// Scale the parallax limit according to heightmap scale.
fParallaxLimit *= fHeightMapScale;
// Calculate the parallax offset vector direction and maximum offset.
vec2 vOffsetDir = normalize( var_ViewDir.xy );
vec2 vMaxOffset = vOffsetDir * fParallaxLimit;
// Calculate the geometric surface normal vector, the vector from
// the viewer to the fragment, and the vector from the fragment
// to the light.
#ifdef DOOM_FORWARD_RENDERER
vec3 N = normalize( var_Normal );
vec3 E = normalize( var_ViewDir.xyz );
#else
vec3 E = normalize( var_ViewDir.xyz );
#endif
// Calculate how many samples should be taken along the view ray
// to find the surface intersection. This is based on the angle
// between the surface normal and the view vector.
float nNumSamples = mix( nMaxSamples, nMinSamples, dot( E, N ) );
// Specify the view ray step size. Each sample will shift the current
// view ray by this amount.
float fStepSize = 1.0 / nNumSamples;
vec2 dx, dy;
dx = dFdx( var_TexDiffuse.xy );
dy = dFdy( var_TexDiffuse.xy );
// Initialize the starting view ray height and the texture offsets.
float fCurrRayHeight = 1.0;
vec2 vCurrOffset = vec2( 0, 0 );
vec2 vLastOffset = vec2( 0, 0 );
float fLastSampledHeight = 1;
float fCurrSampledHeight = 1;
float nCurrSample = 0;
/*
while ( nCurrSample < nNumSamples )
{
fCurrSampledHeight = texture2DGrad( u_diffuseTexture, var_TexNormal + vCurrOffset, dx, dy ).a;
if ( fCurrSampledHeight > fCurrRayHeight )
{
// Find the relative height delta before and after the intersection.
// This provides a measure of how close the intersection is to
// the final sample location.
float delta1 = fCurrSampledHeight - fCurrRayHeight;
float delta2 = ( fCurrRayHeight + fStepSize ) - fLastSampledHeight;
float ratio = delta1/(delta1+delta2);
// Interpolate between the final two segments to
// find the true intersection point offset.
vCurrOffset = (ratio) * vLastOffset + (1.0-ratio) * vCurrOffset;
// Force the exit of the while loop
nCurrSample = nNumSamples + 1;
}
else
{
// The intersection was not found. Now set up the loop for the next
// iteration by incrementing the sample count,
nCurrSample++;
// take the next view ray height step,
fCurrRayHeight -= fStepSize;
// save the current texture coordinate offset and increment
// to the next sample location,
vLastOffset = vCurrOffset;
vCurrOffset += fStepSize * vMaxOffset;
// and finally save the current heightmap height.
fLastSampledHeight = fCurrSampledHeight;
}
}
*/
// color += LightPass( 0, var_Vertex, vCurrOffset, vec4( 100000, 100000, 100000, 0), vec4(0.0008, 0.001, 0.009, 0.1), vec4(0.1, 0.3, 0.2, 0.1), vec4(0.1, 0.1, 0.1, 0.1),vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(1,1,1,1) );
//color += LightPass( 0, var_Vertex, vCurrOffset, vec4( 100000, 100000, -100000, 0), vec4(0.01, 0.01, 0.01, 0.1), vec4(0.01, 0.01, 0.01, 0.1), vec4(0.1, 0.1, 0.1, 0.1),vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(1,1,1,1) );
//color += LightPass( 0, var_Vertex, vCurrOffset, vec4( 100000, -100000, 100000, 0), vec4(0.08, 0.08, 0.08, 0.1), vec4(0.02, 0.04, 0.03, 0.1), vec4(0.1, 0.1, 0.1, 0.1),vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(1,1,1,1) );
//color += LightPass( 0, var_Vertex, vCurrOffset, vec4( -100000, 100000, 100000, 0), vec4(0.02, 0.03, 0.02, 0.01), vec4(0.02, 0.04, 0.03, 0.1), vec4(0.1, 0.1, 0.1, 0.1),vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1), vec4(0.1, 0.1, 0.1, 0.1, vec4(1,1,1,1) );
for(int i = 0; i < numLights; i++) {
float shadow = var_Shadow.r;
vec4 lightProjectS = r_lightProjectionS[i];
vec4 lightProjectT = r_lightProjectionT[i];
color += LightPass( i / numLights, var_Vertex, vCurrOffset, vec4(r_lightOrigin[i], 0.0), vec4(0.1,0.1,0.1, 0) , vec4(1,1,1, 0), lightProjectS, lightProjectT, r_lightProjectionQ[i], r_lightFalloff[i], vec4(1,1,1,1) ) * diffuse * (shadow + 0.3);
}
//gl_FragColor = (color + 0.4) * var_Shadow * vec4(1,1,1,1) ;
gl_FragColor.xyz = color.xyz; //((color.xyz) ) + (UnlitTransparent()) ;
gl_FragColor.a = 1;
}
EndFragmentProgram
/*
void main( void ) {
float height = texture2D( u_normalTexture, var_TexNormal.st ).z;
// compute view direction in world space
vec3 V = normalize( u_viewOrigin.xyz - var_Vertex );
// compute light direction in world space
vec3 L = normalize( u_lightOrigin.xyz - var_Vertex );
height = height * 0.04f + -0.03f;
vec2 newTexCoord = var_TexDiffuse.st + (height * V.xy);
// compute normal in tangent space from normalmap
vec3 N = normalize(2.0 * ( texture2D( u_normalTexture, newTexCoord ).xyz - 0.5 ));
// transform normal, view, and light direction
N = var_TangentToWorldMatrix * N;
V = var_TangentToWorldMatrix * V;
L = var_TangentToWorldMatrix * L;
// compute half angle in world space
vec3 H = normalize( L + V );
// compute the diffuse term
vec4 diffuse = texture2D( u_diffuseTexture, newTexCoord );
diffuse *= u_diffuseColor;
// compute the specular term
vec4 specular = texture2D( u_specularTexture, newTexCoord );
specular *= u_specularColor;
// compute light projection and falloff
vec4 lightProjection = texture2DProj( u_lightProjectionTexture, var_TexLightProj.xyw );
vec4 lightFalloff = texture2D( u_lightFalloffTexture, var_TexLightFalloff );
// compute lighting model
vec4 color = lightingModel( diffuse, specular, L, V, N, H );
color *= lightProjection;
color *= lightFalloff;
color *= var_Color;
// output final color
gl_FragColor = color;
}
*/
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
Oh btw i got a nvidia and no it wont take that
hehe. Atleast not with anything i tried feeding it.
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
mh wrote:... I'd expect it to work on NVIDIA as they can take some of the most awful programmer abuse (lesson #1 in "why you should not develop on NVIDIA"), it should work on AMD but I wouldn't rely on it, and as for Intel - gettouttahere...!
Tell me about it, and that's with nouveau, even (if it's not worse) :/ My sprite implementation works great on nouveau and nvidia, but drops to 0.4 fps on intel
Leave others their otherness.
http://quakeforge.net/
http://quakeforge.net/
- taniwha
- Posts: 399
- Joined: Thu Jan 14, 2010 7:11 am
Re: Doom 3 engine release and game code
Yeah, Justin Marshall's code is probably too alien to integrate into a "vanilla" branch of Doom 3.
He's trying to tackle next-gen paradigms in a similar fashion to RAGE or some of the other
Virtual Texture \ Virtual Normals \ Virtual Geometry? It's a forward looking approach
but has a lot of overhead for hobbyist users. That whole paradigm might be the best
approach to maximize the look of deployed content. It reminds me of old 8bit games
that were sprite sampled from 16bit games (R-Type for the Sega Master System)
and looked better than thought possible on the 8bit hardware.
Here the idea is to boil-down a gang of beefy workstations and terabytes of data into something
that will run on a normal PC. As you can see, this approach requires the mapper\hobbyist to
have a muscular rig to take advantage. From a purely social\political POV it's kinda divisive between
the "haves" and the "have nots" in a way not seen before in hobby\mod culture.
I doubt that was Justin's intention though, it's more likely that he is taking the long view
that by the time his work is complete and has caught-on most of the target audience
will have better hardware than now and thus they could use their own single workstation
rather than a NAS array and 20 workstations... (and of course, the solution is scalable so
you could just scale-down the scope of what you bake... though you'd probably be mocked
and scorned for poor texture quality ala RAGE etc...)
That snippet you grabbed seems to cover only the "forward" portion of his renderer. AFAIK
a significant amount of the renderer is "deferred"...meaning; if you merged that code
it might still look wrong because the other visual aspects are handled in the other
render mode.
I find his project exciting and interesting but I am dismayed that such a talented
fellow didn't instead focus on keeping the existing engine paradigm and just expand
features, optimize performance, etc. How much better would it have been to
see "existing" Doom 3 mods run on an improved engine than throwing out the
baby with the bath-water and making modders start fresh in what is essentially
a whole new platform.
Of course, The Dark Mod is already kinda guilty of it's
own divergence well before the GPL release. Other mods would be hard-pressed
to use it's AI, extinguishable lights or Light-Gem systems so I guess that puts
me as the potential stone thrower in a glass house...
It would've been better if TDM had worked with the community to make more generally applicable
versions of it's core systems so the other Doom 3 mods would have stealth
and advanced AI too but I suppose that's down to no other mods showing interest
in collaborating on that work and therefore no votes in the process. (And TDM
folk being more into Thief than Doom 3 therefore more isolated... )
shrugs...
He's trying to tackle next-gen paradigms in a similar fashion to RAGE or some of the other
Virtual Texture \ Virtual Normals \ Virtual Geometry? It's a forward looking approach
but has a lot of overhead for hobbyist users. That whole paradigm might be the best
approach to maximize the look of deployed content. It reminds me of old 8bit games
that were sprite sampled from 16bit games (R-Type for the Sega Master System)
and looked better than thought possible on the 8bit hardware.
Here the idea is to boil-down a gang of beefy workstations and terabytes of data into something
that will run on a normal PC. As you can see, this approach requires the mapper\hobbyist to
have a muscular rig to take advantage. From a purely social\political POV it's kinda divisive between
the "haves" and the "have nots" in a way not seen before in hobby\mod culture.
I doubt that was Justin's intention though, it's more likely that he is taking the long view
that by the time his work is complete and has caught-on most of the target audience
will have better hardware than now and thus they could use their own single workstation
rather than a NAS array and 20 workstations... (and of course, the solution is scalable so
you could just scale-down the scope of what you bake... though you'd probably be mocked
and scorned for poor texture quality ala RAGE etc...)
That snippet you grabbed seems to cover only the "forward" portion of his renderer. AFAIK
a significant amount of the renderer is "deferred"...meaning; if you merged that code
it might still look wrong because the other visual aspects are handled in the other
render mode.
I find his project exciting and interesting but I am dismayed that such a talented
fellow didn't instead focus on keeping the existing engine paradigm and just expand
features, optimize performance, etc. How much better would it have been to
see "existing" Doom 3 mods run on an improved engine than throwing out the
baby with the bath-water and making modders start fresh in what is essentially
a whole new platform.
Of course, The Dark Mod is already kinda guilty of it's
own divergence well before the GPL release. Other mods would be hard-pressed
to use it's AI, extinguishable lights or Light-Gem systems so I guess that puts
me as the potential stone thrower in a glass house...
It would've been better if TDM had worked with the community to make more generally applicable
versions of it's core systems so the other Doom 3 mods would have stealth
and advanced AI too but I suppose that's down to no other mods showing interest
in collaborating on that work and therefore no votes in the process. (And TDM
folk being more into Thief than Doom 3 therefore more isolated... )
shrugs...
- nbohr1more
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Re: Doom 3 engine release and game code
There's nothing in that shader code that's overly advanced. He's even carrying forward some of the old low-quality stuff from the original shader, and doing a normalize per-vertex - that's going to lose him some quality as square roots don't linearly interpolate.
His blur code is evil - 25x9x2 texture samples per-fragment I make it - that's going to utterly crucify his framerate, even if he is using a 512x512 scene texture. He may even be faster just copying it to CPU-side (pipeline stalls and all) and doing a gaussian on the CPU, then TexSubImaging it.
His blur code is evil - 25x9x2 texture samples per-fragment I make it - that's going to utterly crucify his framerate, even if he is using a 512x512 scene texture. He may even be faster just copying it to CPU-side (pipeline stalls and all) and doing a gaussian on the CPU, then TexSubImaging it.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-

mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
Re: Doom 3 engine release and game code
I thought extinguishable lights are possible with vanilla Doom 3 o_O
What are Light-Gem systems ?
What are Light-Gem systems ?
- motorsep
- Posts: 231
- Joined: Wed Aug 02, 2006 11:46 pm
- Location: Texas, USA
Re: Doom 3 engine release and game code
Might have another solution upcomming when sikk gets his engine done
its atleast somewhat closer to the code in Normal Doom3 and he allready moved code parts out of the CPU and onto the GPU though he allso made changes to the editor but so far only in regards to lighting (Ambient term) which seems to have been missing in the light editor. My guess is that Doom3 didnt support Ambient lights natively ?. Only downside i can see is that you need an updated set of shaders but he allready made the bulk of them. Ill see if i can get him over here so we can have a discussion about his ideas for it.
its atleast somewhat closer to the code in Normal Doom3 and he allready moved code parts out of the CPU and onto the GPU though he allso made changes to the editor but so far only in regards to lighting (Ambient term) which seems to have been missing in the light editor. My guess is that Doom3 didnt support Ambient lights natively ?. Only downside i can see is that you need an updated set of shaders but he allready made the bulk of them. Ill see if i can get him over here so we can have a discussion about his ideas for it.
Productivity is a state of mind.
-

revelator - Posts: 2567
- Joined: Thu Jan 24, 2008 12:04 pm
- Location: inside tha debugger
Re: Doom 3 engine release and game code
In TDM the light sources are usually made of multiple entities and often combine a real light and ambient light.
To make the aesthetics look correct, shadows are often disabled when the candle-holder or torch are lit.
Various conditions such as water arrows and simple finger-snuffing can extinguish different lights and
this is all setup in the SDK code. Scripts could do most of this of course but it has be made a systematic
part of the mod so that mission authors do not need to arrange light scripting all over their maps.
AI have been given awareness of light levels, whether lights are lit or extinguished and have
a visibility system to determine whether the player can be seen "in the light" or if he is
blending into the shadows. The "Light Gem" shows the player how bright he is and whether the
AI are likely to see him. This is a concept taken from the Thief games which the mod emulates.
Apparently similar "light detection" systems are present in games like System Shock and Deus Ex
from the same parent company as Thief (Looking Glass Studios).
There was once a Doom 3 mod called Sapphire Scar which planned to remake something
like System Shock in a similar fashion as The Dark Mod. Doom 3 has some hints and echos
of that game and it's surprising that there is no real stealth in the game given the
survival horror vibes it has. What would it be like hiding in the shadows from the roaming
eyes of those demons and zombies? Thus far nobody has tried such a thing...
To make the aesthetics look correct, shadows are often disabled when the candle-holder or torch are lit.
Various conditions such as water arrows and simple finger-snuffing can extinguish different lights and
this is all setup in the SDK code. Scripts could do most of this of course but it has be made a systematic
part of the mod so that mission authors do not need to arrange light scripting all over their maps.
AI have been given awareness of light levels, whether lights are lit or extinguished and have
a visibility system to determine whether the player can be seen "in the light" or if he is
blending into the shadows. The "Light Gem" shows the player how bright he is and whether the
AI are likely to see him. This is a concept taken from the Thief games which the mod emulates.
Apparently similar "light detection" systems are present in games like System Shock and Deus Ex
from the same parent company as Thief (Looking Glass Studios).
There was once a Doom 3 mod called Sapphire Scar which planned to remake something
like System Shock in a similar fashion as The Dark Mod. Doom 3 has some hints and echos
of that game and it's surprising that there is no real stealth in the game given the
survival horror vibes it has. What would it be like hiding in the shadows from the roaming
eyes of those demons and zombies? Thus far nobody has tried such a thing...
- nbohr1more
- Posts: 54
- Joined: Fri Dec 09, 2011 7:04 am
Who is online
Users browsing this forum: No registered users and 1 guest