shadows

[nib]

I notice in the cg arbvp1 profile there is a glstate.texgen[0].eye.s ( srtq ) variable. I’d assume that these TexGen calls fill the glstate variable…

glActiveTexture(GL_TEXTURE4);

glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
glTexGenfv(GL_S, GL_EYE_PLANE, &mtexture_matrix[0]);
glEnable(GL_TEXTURE_GEN_S);

glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
glTexGenfv(GL_T, GL_EYE_PLANE, &mtexture_matrix[4]);
glEnable(GL_TEXTURE_GEN_T);

glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
glTexGenfv(GL_R, GL_EYE_PLANE, &mtexture_matrix[8]);
glEnable(GL_TEXTURE_GEN_R);

glTexGeni(GL_Q, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
glTexGenfv(GL_Q, GL_EYE_PLANE, &mtexture_matrix[12]);
glEnable(GL_TEXTURE_GEN_Q);

glBindTexture(GL_TEXTURE_2D, mShadowTexture);

If I pass in my own texture matrix to a cg program, then I’d assume these texgen calls would be irrelevant? In the previous example these calls would work on texture unit 4?

---

Also, I create fbo structure in my program. The program attaches a texture made with glTexImage2D. It also attaches a render depth buffer. I assume I cannot set the depth render buffer to a arbitrary texture unit in a cg fragement program? If I made a depth texture instead of a render buffer for depth, then I could use that depth texture in a texture unit in a cg program?

---

Trying to understand tex2Dproj in cg versus tex2D. So, tex2Dproj is going to divide x,y,z by the w value :

x/w y/w z/w 1 where 1 would be w/w = 1…

I assume that

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC, GL_LEQUAL);
glTexParameteri(GL_TEXTURE_2D, GL_DEPTH_TEXTURE_MODE, GL_INTENSITY);

is going to toggle the w result from tex2Dproj?

Thanks for any insights. Just attempting to do shadows again…I posted a few months ago about it…

[k_szczech]

If I pass in my own texture matrix to a cg program, then I’d assume these texgen calls would be irrelevant
To find out which gl state variables are revelant check your shader code and see which ones it reads. There is no rule other than that.

I assume I cannot set the depth render buffer to a arbitrary texture unit in a cg fragement program
You cannot set any render buffer to any texture from withing fragment program - application must do that.
You can create GL_DEPTH_COMPONENT16/24 texture and bind it to FBO. You don’t need a shader to render to depth texture.

[nib]

I see. So, the texgen stuff is basically for fixed pipeline vertex processing – no need to call this in my application.

If I use the depth map then tex2Dproj should automatically adjust itself for a depth comparison. But if I pass it a color texture map its going to return color results.

I see my radeon 9800 driver on the mac supports GL_DEPTH_COMPONENT16 at the most.

The shader is reading from the texture using tex2Dproj. Actually, when I create my shadow fbo stuff I just turn the shaders off to speed things up. Then later on, when I’m going to draw with shadows I use my shader program. ( got to get it to work though ) I’ll get rid of the renderbuffer and use the depth texture instead – see if the fbo will validate.

See how it goes … its probably the texture matrix calculation that is going to trip me up.

[nib]

I can see another shadows sub issue. Lets assume that I use a depth buffer comparison for shadows. But the program is drawing plants with billboards. ( red book p240 ) Since its transparent depth is turned off when the billboards are drawn. Yet, if I turned depth on when I draw these billboards into the fbo I’m just going to get plane like blocks in the depth buffer. I wonder if I don’t draw the ground in the color buffer, say make the ground black, then check against the color ( and against it )too for a shadow if there is a transparency?

Got the depth texture into the fbo and it appears to work. Though, the tex2Dproj is still not working.

[arekkusu]

Please read chapter 8.7 in the GLSL spec . texture2D() will not perform any shadow comparison. You want to use shadow2D along with a sampler2DShadow.

[k_szczech]

But the program is drawing plants with billboards
Usually plants are drawn using alpha test, not alpha blend. If alpha test fails, no pixel is drawn into framebuffer and no value is written to depth buffer.

Please read chapter 8.7 in the GLSL spec
Well, in GLSL you have texture2D and shadow2D. In CG it’s tex2D, so you should probably check if there is some function for sampling shadowmap.

[nib]

Hmm, put in the alpha test.

Essentially, when I’m drawing to the fbo with transpatents to create the shadow map, I enable the alpha test with 0.1. When I look at the texture in opengl profiler -> resources ( at a break point ) I can see that the the leaves etc. are now in the depth texture. Its not going to matter what the colors look like when I’m creating the depth texture. I’ll just turn the colors off completely. Though, I need a color texture to have a complete fbo. Otherwise, I remain drawing the same way when doing colors.

So, billboards are not a problem. If the billboard is off in the distance ( like a sun ) and always faces the eye then the alpha test works. But say I have 5 billboard planes all intersecting each other at x degree increments, then I wanted the blending on. If depth is on, then half of the boards get clipped off and this changed how the blending looked.

Its going to boil down to the texture matrix – thats where I ate it last time.

I think as I’m debugging, I’ll use tex2D and just divide the xy by w manually. This way I can ignore the depth for the moment. Once things look under control as far as the depth texture matrix is concerned, then I’ll just switch to tex2Dproj which will throw in the depth test.

Thanks for the alpha test suggestion.

[arekkusu]

Originally posted by nib:
I need a color texture to have a complete fbo.
No you don’t. You can have only a depth attachment, as long as read and draw buffers are set to NONE.

[nib]

Hmm, I’ll have to try that. I’m using a fbo class object availible from the http://www.gpgpu.org/developer/ site.

I set only the depth texture in the class and tried to validate. It did not validate. I’ll try to set the buffers to none. Pretty new with fbo – disclaimer.

[nib]

Had a few more questions regarding shadows with projective textures.

I can see a projection occuring in my program. Though, the issue tends to be the shadow is too large and not exactly placed under the objects.

Many examples I see are very idealistic. Is there an algorithmic way to set the far and near, fov in gluperspective for an arbitrary light position when drawing the shadow map?

The screen is a rectangle. Yet, the fbo is a square. I assume that is why many examples have an aspect ratio of 1?

[Komat]

Originally posted by nib:

I can see a projection occuring in my program. Though, the issue tends to be the shadow is too large and not exactly placed under the objects.

The texture is probably projected incorrectly, the projection matrix likely does not correspond to the matrices used for shadowmap rendering or scale&bias matrix is wrong.

[nib]

I had another question. In the “Red Book” fifth edition version 2, on page 455 there is example 9-18 Calculating texture coordinates. I get to the line where the code transposes the tmpMatrix ( or what is the texture matrix ). Why is this transpose being done? After a while looking at this has made me blind. The rest of the example appears to make sense except for the magic transpose.

[nib]

Think I understand now about the transpose stuff…its row vs column interpretation of the matrix. I use the vvector.h stuff now and it works fine.

Ok, another newb question. I am getting shadows now but I had to do some tweaks that imply I’m doing something else wrong in regards to the texture matrix. Here goes…

In the cg tutorial book, it states that when you multiply the “object coordiate” by the view and then the projection matricies you get a result in the [-1,1] range. Is this assuming that the object coordinate is divided out by w? x/w, y/w and z/w where w =1?? I’m assumeing the object psace coordinate is passed into the vertex program via v : POSITION. Otherwise, I’m not sure how the results get into the [-1,1] range.(?)

Currently, when I add my bias matrix that multiplies and scales by 0.5 then I get odd results.

So, since I don’t have a bias matrix ( which I should but it did not work ) I divide the resulting swizzle xy by the width of my square texture and add 0.5. Doing this creates the expected shadow patterns via tex2D – but this is the wrong way to do it. I’d like to use the tex2Dproj but I’m a little confused about the object coordinate set up. I assume the z value is the depth?

Suggestions would be appreciated.

[nib]

I got the shadows working.

But a note, I think tex2Dproj with xyzw has a bug on the mac. I changed depth coordinates via keyboard to many different values and it never seems to work. But tex2Dproj xyw works – do the depth check on the result passed back. Its a ati radeon 9800 card. I’ll see if there is a difference on an nvidia card at some point.

The aliasing and depth seems to be a tweaking issue.

Looks good but I have to try and speed up the fbo somehow.

[OneSadCookie]

As always, if you think there’s a bug, you should file a bug report. http://bugreport.apple.com/ Make all our lives better

[nib]

Ya, its mvidia cg 1.5 beta 2. Probably some bugs in there but B is for beta. Still wonder when the final version will be released. Have not seen any news lately. Cricket chirps.

Hmm, fragment program a no go on my g4 iBook. According to driver monitor I can have a vertex program but no fragment program. No fbo either. I bet shadows would be too slow on the iBook anyways. Blows up in cgCombinePrograms3 – can see it in the assembly. Think its a radeon 9200 on the iBook. Time to break out glew and start to disable things. Works great on the g5 with a radeon 9800.

Just using the arbfp1 and arbvp1 profiles. Going to the lowest common denominator.