Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Jul 2009
Offline Last Active Apr 03 2015 04:36 AM

Posts I've Made

In Topic: Maximum color output

02 April 2015 - 02:39 AM

I'm starting to think perhaps rendering 3D hemispheres/cones with depth test enabled might be a better solution.

In Topic: Shadow mapping with GLSL

10 March 2015 - 10:23 AM

For future reference, and as the unfairly downvoted gentleman in this post http://stackoverflow.com/questions/17707638/getting-black-color-from-depth-buffer-in-open-gl-es-2-0 mentions, a depth texture with linear mag filtering will not always work in OpenGL ES. With GL_NEAREST it looks great.

In Topic: Shadow mapping with GLSL

10 March 2015 - 03:59 AM

Vanderry, on 09 Mar 2015 - 8:32 PM, said:
The shadow map is being rendered directly to a texture (no render buffer involved), with settings GL_RGBA and GL_UNSIGNED_BYTE.
That would be the first problem. Render shadows to float textures.


Right you are. That takes care of all the packing business.


Vanderry, on 09 Mar 2015 - 8:32 PM, said:
gl_FragColor = vec4(v_ShadowCoordinate.z / 60.0); // Without packing
You didn’t divide by .w. 60.0 is an arbitrary number—there is no reason to expect that you will get correct results this way.
gl_FragColor = vec4(v_ShadowCoordinate.z / v_ShadowCoordinate.w);
gl_FragColor = vec4(gl_FragCoord.z); // Alternative.


I could see how this would be appropriate when using the depth value calculated by OpenGL, to linearize it if my understanding is correct. I have been assuming that a manual transformation wouldn't suffer the same "skewing". After all, if I performed the same calculation in C++, then the results should be linear, and w would remain 1.0. The 60.0, or view depth, was a desperate attempt to contain the result within the 0.0-1.0 range. I would use a uniform in practice. With the many opportunities for error here, please don't hesitate to correct me.


Vanderry, on 09 Mar 2015 - 8:32 PM, said:
mat4 shadowBiasMatrix = mat4(
    0.5f, 0.0f, 0.0f, 0.0f,
    0.0f, 0.5f, 0.0f, 0.0f,
    0.0f, 0.0f, 0.5f, 0.0f,
    0.5f, 0.5f, 0.5f, 1.0f);
Shouldn’t this be column-major?


My math support classes are assuming row-majority. It would have been a good catch if this wasn't the case.


Vanderry, on 09 Mar 2015 - 8:32 PM, said:
v_TextureCoordinate = a_TextureCoordinate;
  v_ShadowCoordinate = shadowBiasMatrix * u_ShadowMatrix * u_WorldMatrix * a_Position;
This should all be moved to the CPU, I’ve never heard of the shadow coordinate being set in the vertex shader (I would have to spend more time than I am willing to think about whether or not it is possible), below this you have magic numbers again—let’s just stop there.


Isn't the purpose of varying variables to let OpenGL generate fragment-adjusted values across faces? It certainly seems to work, but I may just be doing a whole lot of overcalulation if my assumption is wrong.


Thank you very much for taking the time to read this mess :)

In Topic: Shadow mapping with GLSL

09 March 2015 - 05:31 PM

I guess I am getting better results from using gl_FragCoord.z in the shadow fragment shader, in which case the problem is how to depth test the fragments. I did at one point pass the target texture into the shader, to write the minimum of the old and new z but that didn't work so well in OpenGL ES...

In Topic: Data oriented design

23 February 2015 - 03:53 PM

Hello Randy! I simplified one behemoth of a structure for the purpose of this post. In reality it is part of a quite elaborate (and mostly finished) project that I got some critique for when I passed a code sample to a potential employer. I suppose it might be a good start to unite objects contained in vectors and apply the changes step by step, not necessarily going "all the way".