ARB Shader TXP operator

OpenGL OpenGL: Basic Coding
1

Hello everyone!

I made a shadow mapping Cg shader program and compiled it to the ARBfp1.0 (for use with OpenGL) and am having some problems…

In Cg the corresponding function for TXP is tex2Dproj(). This function is supposedly smart enough to know if the texture it is projecting is a depth map or not. If it is a depth map it will only return [1, 0] depending if the fragment is in the the shadow or not. So it basically does all the work for you. However, it seems that the TXP operator doesn’t work this way. I just want to make sure that is my problem.

In short: Does the TXP operator act any different if the texture it is projecting is a depth map or not.

Thanks in advance!

(If I need to figure out if the fragment is in the shadow or not, I’d be happy to see some sample code on how to do this. Don’t want to re-invent the wheel and all.)

2

hey fingolfin, you can find the answers to questions like this in the corresponding spec, though you have to dig a little :wink:

http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt

excerpt:

Interactions with ARB_shadow

The texture comparison introduced by ARB_shadow can be expressed in 
terms of a fragment program, and in fact use the same internal 
resources on some implementations.  Therefore, if fragment program 
mode is enabled, the GL behaves as if TEXTURE_COMPARE_MODE_ARB is 
NONE.
3

Thanks, but…

Since I am a <bonehead>, is that telling me that it does not act differently if the texture being projected is a depth texture?

I am no OpenGL guru, so I’m not very sure what “TEXTURE_COMPARE_MODE_ARB is NONE” is telling me. Seems like all this is saying is, “if you want to do some fancy texture comparison, you can code it in a fragment program.” This is kind of obvious, but I am trying figure out “how” to code it.

So the answer is “No, it does not act differently”. Meaning I have to code the comparison?

4

Unfortunately in the ARB_fragment_program spec a shadow map does not behave as one (i.e. does not return a shadow comparison). There is another extension called ARB_fragment_program_shadow (I think) which allows you to specify as an option that you do want these lookups to do the comparison.

Matt

5

Thanks for the help folks, doing some more reading it looks like all I have to do is compare the projected depth buffer value for the fragment I am at with the projected texture’s coordinate r value to determine if I am in shadow or not. Will try that as soon as I can and see what I get. So far the depth buffer is being projected fine, it is just that I want a shadow not a depth buffer =D.

6

The simple comparison didn’t do it for me. Can anyone tell me some details behind the math of that comparison? Any links or anything that may help me do it manually. The only things I have found have not been very detailed. (And clearly didn’t work). Thanks in advance!

7

if you look at the spec for ARB_fragment_program_shadow, that matts mentioned, you’ll see an example of how to accomplish this very thing:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program_shadow.txt

look at all the other extensions while you’re there. you never know when one of them might come in handy. add this to your favorties:
http://oss.sgi.com/projects/ogl-sample/registry/

note that there are many steps in shadow mapping, any one of which could botch the whole thing if it’s out of whack.