Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Dec 2001
Offline Last Active Jul 18 2014 07:30 PM

Posts I've Made

In Topic: Bind a VBO as a TexImage2D?

26 June 2014 - 12:36 PM

ok. Yeah cool. That looks like it will work. I think you have to create the GL_TEXTURE_BUFFER separately with a glGenTextures call, but then it looks like you can just straight up bind a buffer to that. I'll play around with it. 



In Topic: Bind a VBO as a TexImage2D?

25 June 2014 - 09:14 PM

It occurs to me, I'm being dumb because I can probably find a way to just have the first Shader render the data directly to a texture instead of extracting the data through Transform Feedback... But anyway, I guess I'm still curious about the OP anyway. :)

In Topic: Dynamic Ambient Occlusion

24 June 2014 - 03:39 PM

ok. so rambling on-wards. My central hangups are still just about implementation. I'm somewhat worried about performance but it's way easier to deal with that after implementation rather than obsessing about it now. Mostly I just want to learn this stuff; secondarily it's a bonus if it looks amazing and runs at framerate...


So here's my thoughts about implementation. Is anything in here either insane or just stupid because I don't know about some awesome GPU trick?


Basically, I think I can generate better results by generating AO data using the actual voxel cube faces, instead of their verts due to the fact that they are cubes and not a smoother mesh. Maybe this is wrong... Feedback appreciated :)


GPU 1 (generate our disks with which we will perform the AO algorithm described in the Gems 2 chapter)
vertex shader (pass-through)
geometry shader
at the center of each face of each block that is facing air
generate one point
generate the appropriate normal
transform feedback -> retrieve the list of points/normals
fragment shader: discard unless there is a way to just get the pipeline to stop after Transform Feedback?
CPU 1 (build the disk lookup data structure)
extracted points/normals go into textures
build out the hierarchical representation data structure within the textures
GPU 2 (First AO pass. Basically, render a single quad with UVs [0..1] to cover the whole data texture)
vertex shader (pass-through)
fragment shader
run AO pass #1 and store accumulated shadow data into a new texture
CPU 2 (here just to pass the texture back to the GPU for the second AO pass)
extract shadow info texture from GPU 2
Is there is a way to run the second GPU pass without coming back out to the CPU? If the texture is already bound from the previous render, I guess it's still in the same place?
GPU 3 (Second AO pass)
render a single quad with UVs [0..1] to cover the whole data texture.
vertex shader (pass-through)
fragment shader
run AO pass #2 and store accumulated shadow data into a shadow info texture
GPU 4 (render the actual scene)
vertex shader
geometry shader
for each cell center
generate the 2 triangles to render
fragment shader
in addition to normal logic, use AO data to shade mesh
because we generated AO data for faces, not verts, blend between up to nearest 4 face values as calculated in GPU 2+3

In Topic: Dynamic Ambient Occlusion

23 June 2014 - 09:19 PM

So is that article I posted actually SSAO though as opposed to an approximation of true AO? I thought it was the latter, not the former. My understanding is that a lot of SSAO implementations use the depth buffer hack for faster rendering but then you get jenky outcomes. The GPU Gems article, I think, is approximating global AO. Ya? Or am I just wrong on terminology?


Anyway, the AO for minecraft-like worlds is pretty great.


Just from a theoretical learning perspective though if you have the answer to my original question can you provide it?


Thanks :)

In Topic: Problem with glDrawElementsInstanced and glVertexAttribDivisor

16 June 2014 - 02:26 PM

ok, well, found the answer.


If you are using glVertexAttribPointer, the data will be converted to a floating point value. For passing unsigned data without information loss, like I'm trying to do, you should use glVertexAttribIPointer. I'm not totally sure why there would be data loss since I would have imagined that it would be a (uint32_t)((float)originalValue) kind of thing, but there you have it. Data is getting into the shader. Happy times!