Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 05 Oct 2011
Offline Last Active Dec 06 2014 01:10 PM

Posts I've Made

In Topic: Trouble reading from depth-texture

29 July 2013 - 10:17 PM

Yep! I set 7 as the active texture unit, bind the texture,and then set 7 as the value of the gCascadedShadowMap texture uniform.


I was hoping someone might now what possible things could 'block' the texture from being read from? Are their constraints on the bind states of the frame buffer objects? I've tried binding and unbinding the relevant frame buffers in various places, but I'm sure I've not exhausted the possibilities.

In Topic: FBO - Render to texture not working

21 July 2013 - 05:15 PM

Fixed a small bug - I forgot to reset the glClearDepth to 1.0f after setting it to 0.25f. But still not working. 


I think it has something to do with my gBuffer. My gBuffer has 4 color textures and a depth/stencil texture attached to its FBO. The shadow map FBO has only a depth texture attached. When I do my light pass I have my g-buffer fbo bound, and then I bind the shadow-map's shadow texture to an appropriate texture unit. It appears as if the gBuffer cannot "see" the shadow texture sitting in the unbound FBO. By my understanding I thought this would work but is there some technicality here that I'm not aware of?

In Topic: FBO - Render to texture not working

20 July 2013 - 07:15 PM

I don't think thats it. I'm not using the texture for anything else.


(edit) Being doing more testing and it would appear that the depth clearing is being applied to my g-buffer (previously bound frame buffer) and not to the shadow FBO. I can't see why though, I am definitely binding the shadow FBO before clearing the depth buffer.

In Topic: Stencil shadow volumes - a thing of the past?

11 June 2013 - 03:44 PM

Weird.. I thought I submitted a reply to this...


I'm not sure why you're having so many self-shadowing issues. On my last project we used them specifically for character self-shadowing, and used a different technique for character-on-world shadows!

Interesting! I mean, my self-shadowing certainly works, its more an issue of artifacts close to the silhouette edge. May I ask, how did you determine your silhouette edges? 
The issue I seem to be having, even when calculating a smooth silhouette edge (cutting along the line where non-ambient light reaches zero), is that the lighting is smooth and continuous but the shadow volumes are sharp wedges, and therefore I seem to invariably see artifacts close to the silhouette edge. Later I'll try to post an example when I have my laptop.

In Topic: Per-polygon self shadowing problem with stencil shadows

26 May 2013 - 12:44 PM

Hello friends. I liked the link posted by Tesselator I set about to implementing it and I've gotten quite close I think. I've tested that it correctly emits the silhouette edges exactly where the non-ambient lighting reaches 0. 


The only problem that remains is shown below. (Never mind the diamond shaped region at the left, that's a model in the background with non-continuous surface normals, which I need to add special case code to handle)


The lighting shader is currently set to draw green where the shadow will be. The Z-fighting you see on the upper half is not really an issue because the shadow only blocks non-ambient light, and so it will have no affect on the lighting there.


The real problem is the extreme right and left interior faces of the torus. The light is pointed in the negative Y direction. The shadow volume is projected straight down, and these extreme edges do not quite catch the shadow.

I have tried a few tricks to enlarge the projected shadow. For example, If I was projecting a shadow volume from triangle (v0,v2,v4), I would instead project (v0-eps*n0, v2- eps*n2,v4-eps*n4) where n0,n2,n4 are the respective normals for v0,v2,v4 and epsilon is a small positive value. This actually worked very well except it created gaps in the shadow volume, producing narrow (or in some cases fairly wide) line artifacts.