Xycaleth

Members
  • Content count

    219
  • Joined

  • Last visited

Community Reputation

2391 Excellent

About Xycaleth

  • Rank
    Member

Personal Information

  • Interests
    Business
    Education
    Programming
    QA
  1. OpenGL Transform Feedback empty on iOS

    Have you set up the transform feedback varyings before linking the shader program?
  2. OpenGL why unbind VAO

    From the GL4.5 spec, in reference to glBindVertexArray: My bad. I misread the text :) I'm sure it wasn't allowed somewhere but maybe I remembered wrong.
  3. OpenGL why unbind VAO

    There's no good reason to do this. You should know at all times in your program which VAO is currently bound so that you don't repeatedly bind the same VAO. Or if you're just starting out, make those redundant calls to bind the VAO you need every time. Relying on a specific VAO to be bound in functions X, Y and Z becomes a maintainability nightmare later down the road. And there's certainly not any need to unbind VAOs. If you're using core OpenGL, it's an error to bind the "default VBO" since core GL doesn't have one.
  4. Working code doesnt work in opencl

    Last time I checked you can also use printf from CL kernels. It might have been an extension but it should be widely supported.
  5. OpenGL Why so many fence/sync types?

    It looks like all four extensions give the same functionality except GL_APPLE_sync can only be used in OpenGL ES, GL_ARB_sync and GL_ARB_fence are only for OpenGL, and GL_NV_fence can be used in GL and GLES both (remember that GL and GLES are effectively different APIs, worked on by two separate Khronos working groups, even they have converged in the past few years).   EGL_ANDROID_native_fence_sync works with either GL or GLES as long as you use EGL as your platform layer and effectively does the same job as the other 4 extensions with the addition of being able to synchronize across contexts as well.
  6. Thanks for the advice guys. I'll be starting off with diffuse only reflections so that simplifies things a lot. I have a fairly basic photon mapping solution going at the moment (visualising it just by rendering the scene from some point in the map, instead of generating the lightmaps) but I'm having with this case: +-------------------+ |              L  | |  ----------------+ |               X  | +------------------ + L = Light, X = problem area I'm getting very noisy results at X, with around 30M photons. I would guess this is because a small percentage of photons will reach is from L - is this just an inherent issue with photon mapping? At least, without increasing the number of photons even further.   I might try out path tracing as well to compare the results.
  7. I'm currently interested in writing a lightmap generator for the old Quake3 BSP format as a side project and was wondering what techniques the latest and greatest lightmap generators are using. I've come across a few such as photon mapping of some sort (UE4), rasterization + irradiance gradients (The Witness), and as far as I can tell the map compiler for Quake3 used some radiosity-based technique.   What techniques are games using nowadays? I'm looking for something which gives fast convergence and doesn't require too much tweaking to get the desired results. I initially thought to use photon mapping and actually made a start, but I thought it would be good to get some more opinions first. I'm initially writing this for CPU, and then moving to GPU when I have a good understanding of how the algorithm works. Any advice is welcome :D
  8. OpenGL Rendering MD3 in Modern OpenGL

    An interesting idea could be to store your all the vertex positions for your key frames in a texture, with a single row storing all your positions, and each subsequent row is a single key frame. When you come to draw your animated frame, you can set a single float uniform for which frame to use, and then sample all your vertex data from the texture using this float as the y coordinate, and then use gl_VertexID as the x coordinate. That way you get your frame interpolation for free through the bilinear texture filtering.
  9. It doesn't look like you're setting up the vertex attributes anywhere (i.e. calling glVertexAttribPointer).
  10. Try restructuring your shader to look like this: void main() { gl_FragColor = vec4( diffuse, opacity ); vec4 a = texture2D( map1, vUv ); vec4 b = texture2D( map, vUv ); vec4 texelColor; if(vUv.x >= 0.0 && vUv.x < 1.0 && vUv.y >=0.0 && vUv.y < 1.0) // <- Sample from a different texture for that square texelColor = a; else texelColor = b; gl_FragColor = gl_FragColor * texelColor; } Calling texture2D inside a non-uniform if block can result in undefined behaviour, so you should hoist them out of the if/else and do them all the time. Then you can select which result you want.
  11. When you specify the vertex count (or index count) in glDrawArrays or glDrawElements, you're actually specifying the number of times the vertex shader should be run. Nothing else matters. Calling glVertexAttribPointer doesn't 'create vertices', it's setting up pointers from which the vertex shaders can fetch per-vertex attributes, but they aren't necessary.
  12. What version of OpenGL ES are you targeting? The texelFetch function is supported from ES 3.0 onwards.
  13. OpenGL Processing "GL.XML"

    On the opengl.org website, there's a README file describing the format of these XML spec files.   https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/readme.pdf   It has complete descriptions of what all the different tags do.
  14. Does anyone know where to get GLee?

    I would recommend using GLEW instead as it's more up-to-date. That, and the website works.
  15. glLinkProgram crash on Intel

    Can you post your whole shader? There's a lot missing from your abbreviated version which could potentially be causing issues