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 21 Feb 2008
Offline Last Active Apr 13 2015 08:33 AM

Posts I've Made

In Topic: Logo Feedback

27 March 2015 - 07:30 AM

Some kind of animal, maybe a racoon.

In Topic: Shadowmapping

08 December 2014 - 11:10 AM

The transformed vertex due to the model*view*projection transformation ends up in clip space. To translate that into ndc, you need to take into account the perspective divide as such:

// vertex shader:
float4 p = mul(mvp, vertex);
o.screenPos = p;

// fragment shader:
float2 screenPos = (i.screenPos.xy / i.screenPos.w) * 0.5 + 0.5;

You ignore the z coord.


screenPos will be in 0..1 range.  Is this what you need?


gluPerspectiveA(90.0, 2.0, 10.0, 1000.0 * 1000.0);



This doesn't look right to me. You are passing a near plane of 10 (which means you will get shadow clipping when the camera is very close), and a far plane of 1000000. Also, why is aspect ratio = 2?


I'd suggest to go with an orthographic projection to begin with instead of sharing the same projection matrix between your main camera and your light shadow caster.

In Topic: Shadowmapping

08 December 2014 - 03:45 AM

Is the light a directional one? Where are you calculating the light's projection and view matrices?

gluPerspectiveA(90.0, 2.0, 10.0, 1000.0 * 1000.0);

What is the last parameter of gluPerspectiveA, is it the far plane? If so, it may be too big and you lose depth precision. You should also be using an orthographic projection for your directional light, as it's considered to be very very far away.

Matrix44<double> SMVP = ( (ACTUAL_MODEL * shadowView) * ACTUAL_PROJECTION ) * ShadowbiasTex;

The order of multiplication in opengl is projection * view * model, I think you got this the other way round.

I'll have a better look at your code later, I am at work now.

In Topic: Uniform Buffer Confusion

17 October 2014 - 02:57 PM


I see, it still doesn't make sense how you would know if the uniform buffers provided fulfill the shader program requirments.



Personally, if the shader does not contain the specific uniform buffer name (using glGetUniformBlockIndex), I ignore it/send a warning to the console.


Moreover, my renderer is a deferred renderer so I more or less know exactly what kind of shaders I have at any given time.

In Topic: Uniform Buffer Confusion

17 October 2014 - 09:41 AM

I do it in the following way:


My UniformBuffer has a usage flag, which is "Default" or "Shared". Now we have 2 scenarios on using the UBO:


1) If the UniformBuffer usage is "Shared", then the UBO send an event to the ShaderManager to register this UBO to all the loaded shaders. In my engine it's guaranteed that all the shaders are pre-loaded, so when you create a shared UBO, it's also guaranteed that all the shaders will know about it. When the renderer is binding a shader, it also binds its registered UBOs.


2) If the UniformBuffer usage is "Default", then I manually register the UBO to whichever shader I want.


I use the std140 layout as well.

I am not sure if this approach is 100% correct though. Reading haegarr's approach makes me re-think of my design a bit.