TSE Relief Mapping?
by Tim Betts · in Torque Game Engine Advanced · 11/02/2005 (10:37 am) · 156 replies
Hey shader junkies, so, we've had bump maps, normal maps, then parallax mapping, so what about the next challenge - relief mapping ? anyone even attempted to get this puppy working on TSE? Now I'm no shader programmer unfortunately, but it would look like that this approach (http://fabio.policarpo.nom.br/relief/index.htm) will yield far more accurate mapping than parallax mapping. Very exciting work. Any guru's willing to step up :) ?
Cheers -- Tim.
Cheers -- Tim.
#2
11/03/2005 (6:05 pm)
God Doom3 is pretty. I can't believe they fired their artist after that masterpiece.
#3
11/03/2005 (6:12 pm)
Thats one hell of a shader.
#4
Very exciting to read, let alone the Curved Relief Mapping in what it can handle, just amazing. Basically, an entire 3D object from any angle with just a few polys and some very clever textures and shader code. Awesome. The demo even contains a very good portion of the shader code !!
Both these documents show that although the shader code is more complex the superior effect is relief mapping. However, as always, having both options gives you maximum flexibility and trade-offs on performance.
I read somewhere that GG is planning to include parallax in their shaders, so how about relief as well.
That's assuming, one of you shader guru's don't beat 'em to it first :)
Wanna take a ride :)
11/03/2005 (6:34 pm)
I think this link sums up the difference between parallax and relief very well. Quote:
In Parallax Mapping we displace the texture coordinates along the view direction by an arbitrary factor times the depth value stored in the depth map. This adds a nice displacement effect at a very low cost but is only good for noisy irregular bump, as the simplified displacement applied deforms the surface inaccurately.
Here in Relief Mapping we want to find the exact displacement value for every given fragment making sure all forms defined by the depth map are accurately represented in the final image. In Relief Mapping, the surface will match exactly the depth map representation. This means that we can represent forms like a sphere or pyraid and they will look correct from any given view angle.
Very exciting to read, let alone the Curved Relief Mapping in what it can handle, just amazing. Basically, an entire 3D object from any angle with just a few polys and some very clever textures and shader code. Awesome. The demo even contains a very good portion of the shader code !!
Both these documents show that although the shader code is more complex the superior effect is relief mapping. However, as always, having both options gives you maximum flexibility and trade-offs on performance.
I read somewhere that GG is planning to include parallax in their shaders, so how about relief as well.
That's assuming, one of you shader guru's don't beat 'em to it first :)
Wanna take a ride :)
#5
11/05/2005 (10:19 am)
Well said, Weston. :)
#6
Do you mean Paul Steed? Because he was fired before Doom 3.
11/05/2005 (7:41 pm)
Quote:God Doom3 is pretty. I can't believe they fired their artist after that masterpiece.
Do you mean Paul Steed? Because he was fired before Doom 3.
#7
11/06/2005 (4:43 am)
Actually I was referring to Adrian Carmack
#8
11/06/2005 (4:49 am)
Wow, just looked it up.. Never new about that one. Tis a shame.. :/ O well, nothing you can do about it a guess.
#9
I guess its probably a very similar thing to this relief mapping. Different terms for similar issues I guess.
11/06/2005 (12:13 pm)
There is a technique called perspective parralax mapping that one of the women researchers at ATI did a presentation about at GDCE, I'd suggest we have a look at that when writing a parallax mapping implementation as it was VERY nice.I guess its probably a very similar thing to this relief mapping. Different terms for similar issues I guess.
#10
11/06/2005 (12:48 pm)
The nice thing about this is the sample with the curved ray so that it can have a see-through edge and not look flat.
#11
11/07/2005 (11:30 pm)
Hey, I've actualy discovered and implemented a more advanced form of relief mapping which produces the exact same results in less itterations. I'm currently writing the paper on it so can't really discuss the details, but in the course of my research I've kinda become experienced with implementing various per pixel displacement mapping techniques such as relief mapping. I've got a license for TSE but havent really looked at it, what shader language does it use? I'm sure it has normal mapping. Has parallax been implemented too? if someone can point me in the direction of the normal or parallax mapping shaders then I'd be happy to whip up relief mapping real quick (parallax too if they dont have it)... shouldn't be too much trouble if I can start from normal mapping. I'd really like to see the terrain relief mapped :)
#12
www.garagegames.com/mg/forums/result.thread.php?qt=28219
11/08/2005 (4:41 am)
Here ya go, the shader for parallax mapping. Scroll down a bit and you will find the post I made with the links to it. Theres also a fix for lightmaps right below it. If you could make a relief mapping shader out of it really quickly, that would be VERY nice! :)www.garagegames.com/mg/forums/result.thread.php?qt=28219
#13
www.noolness.com/downloads/nool-shader-pack-1.zip
11/08/2005 (4:43 pm)
I just implemented the relief mapping outlined in the documents above. I also created a better parallax mapping shader, and for no real reason at all, a normal mapping shader. You can download it here:www.noolness.com/downloads/nool-shader-pack-1.zip
#14
Relief mapping...


Parallax mapping...

Normal mapping...
11/08/2005 (4:50 pm)
Oh....I forgot, screeenshots...yes....Relief mapping...


Parallax mapping...

Normal mapping...
#15
11/08/2005 (4:59 pm)
BTW, the relief mapping requires pixel shader 3.0. The parallax mapping and normal mapping only require pixel shader 2.0.
#16
11/08/2005 (5:06 pm)
Nice =) Good job!
#17
11/08/2005 (5:12 pm)
Bleh.. I cant use it.. :(
#18
11/08/2005 (5:23 pm)
@Ray - The reason for 3.0 is the instruction limits right? The FX Composer sample on Fabio Policarpo's page seems to use the ps_2_a profile to get around this. I think ps_2_a is Geforce FX and higher only and ps_2_b is Radeon X800 and higher and both allow for higher instruction limits on those cards without 3.0.
#19
11/08/2005 (5:35 pm)
Its not the instruction limits. It has to do with the dependency chain for textures being too long.
#20
11/08/2005 (5:38 pm)
Or rather too complex. I got the following error in tse when i tried to run it using pixel shader 2.0:C:\Share\Code\tse\example\shaders\reliefP.hlsl(26): error X5426: Shader uses texture addressing operations in a dependency chain that is too complex for the target shader model (ps_2_0) to handle.
Associate Tom Spilman
Sickhead Games
I quickly looked at the fx shader source posted at this site and it's not too crazy at first glance...
// use linear and binary search float3 ray_intersect_rm( in sampler2D reliefmap, in float3 s, in float3 ds) { const int linear_search_steps=10; const int binary_search_steps=5; ds/=linear_search_steps; for( int i=0;i<linear_search_steps-1;i++ ) { float4 t=tex2D(reliefmap,s); if (s.z<t.w) s+=ds; } for( int i=0;i<binary_search_steps;i++ ) { ds*=0.5; float4 t=tex2D(reliefmap,s); if (s.z<t.w) s+=2*ds; s-=ds; } return s; } float4 relief_map( v2f IN, uniform sampler2D texmap, uniform sampler2D reliefmap) : COLOR { // ray intersect in view direction float3 v = normalize(IN.eye); // serach start point and serach vector with depth bias float3 s = float3(IN.texcoord,0); v.xy *= depth*(2*v.z-v.z*v.z); v /= v.z; // ray intersect depth map float3 tx = ray_intersect_rm(reliefmap,s,v); // get normal and color at intersection point float4 t = tex2D(reliefmap,tx.xy); float4 c = tex2D(texmap,tx.xy); // expand normal t.xyz = t.xyz*2-1; t.y = -t.y; // light direction float3 l = normalize(IN.light); // view direction v = normalize(IN.eye); v.z = -v.z; // compute diffuse and specular terms float diff = saturate(dot(l,t.xyz)); float spec = saturate(dot(normalize(l-v),t.xyz)); // attenuation factor float att=1.0-max(0,l.z); att=1.0-att*att; // compute final color float4 finalcolor; finalcolor.xyz = ambient*c.xyz + att*(c.xyz*diffuse*diff + specular*pow(spec,shine)); finalcolor.w=c.w; return finalcolor; }I'm sure someone could get this working in TSE in an hour or so.