How can I perform the following image processing tasks using OpenGL ES 2.0 shaders?

- Colorspace transform ( RGB/YUV/HSL/Lab ) 
- Swirling of the image 
- Converting to a sketch
- Converting to an oil painting

How can I do these image processing tasks using OpenGL ES 2.0 shaders?

My code approaches GLSL shader management in the way, that it creates each shader and the associated program and deletes each shader and program. I recently read http://www.opengl.org/wiki/GLSL_Object and there it is stated that:

&gt; The shader object, due to being attached to the program object, will
&gt; continue to exist even if you delete the shader object. It will only
&gt; be deleted by the system when it is no longer  attached to any program
&gt; object (and when the user has asked to delete it, of course).

Do I get this correctly, if I call `glDeleteShader()` on the shader object after linking to the program, I only need to track the program? Is it safe to assume this is always true?

Proper way to delete GLSL shader?

I am working on some shaders, and I need to transform normals. 

I read in few tutorials the way you transform normals is you _multiply them with the transpose of the inverse of the modelview matrix_. But I can&#39;t find explanation of why is that so, and what is the logic behind that?

Why transform normals with the transpose of the inverse of the modelview matrix?

I&#39;d like to get a list of all the uniforms &amp; attribs used by a shader program object.  `glGetAttribLocation()` &amp; `glGetUniformLocation()` can be used to map a string to a location, but what I would really like is the list of strings without having to parse the glsl code.

Note: In OpenGL 2.0 `glGetObjectParameteriv()` is replaced by `glGetProgramiv()`.  And the enum is `GL_ACTIVE_UNIFORMS` &amp; `GL_ACTIVE_ATTRIBUTES`.


In OpenGL is there a way to get a list of all uniforms &amp; attribs used by a shader program?

When you are learning 3D programming, you are taught that it&#39;s easiest think in terms of 3 transformation matrices:

   1. *The Model Matrix*. This matrix is individual to every single model and it rotates and scales the object as desired and finally moves it to its final position within your 3D world. &quot;The Model Matrix transforms model coordinates to world coordinates&quot;.

   2. *The View Matrix*. This matrix is usually the same for a large number of objects (if not for all of them) and it rotates and moves all objects according to the current &quot;camera position&quot;. If you imaging that the 3D scene is filmed by a camera and what is rendered on the screen are the images that were captured by this camera, the location of the camera and its viewing direction define which parts of the scene are visible and how the objects appear on the captured image. There are little reasons for changing the view matrix while rendering a single frame, but those do in fact exists (e.g. by rendering the scene twice and changing the view matrix in between, you can create a very simple, yet impressive mirror within your scene). Usually the view matrix changes only once between two frames being drawn. &quot;The View Matrix transforms world coordinates to eye coordinates&quot;.

   3. *The Projection Matrix*. The projection matrix decides how those 3D coordinates are mapped to 2D coordinates, e.g. if there is a perspective applied to them (objects get smaller the farther they are away from the viewer) or not (orthogonal projection). The projection matrix hardly ever changes at all. It may have to change if you are rendering into a window and the window size has changed or if you are rendering full screen and the resolution has changed, however only if the new window size/screen resolution has a different display aspect ratio than before. There are some crazy effects for that you may want to change this matrix but in most cases its pretty much constant for the whole live of your program. &quot;The Projection Matrix transforms eye coordinates to screen coordinates&quot;.

This makes all a lot of sense to me. Of course one could always combine all three matrices into a single one, since multiplying a vector first by matrix `A` and then by matrix `B` is the same as multiplying the vector by matrix `C`, where `C = B * A`.

Now if you look at the classical OpenGL (OpenGL 1.x/2.x), OpenGL knows a projection matrix. Yet OpenGL does not offer a model or a view matrix, it only offers a combined model-view matrix. **Why?** This design forces you to permanently save and restore the &quot;view matrix&quot; since it will get &quot;destroyed&quot; by model transformations applied to it. Why aren&#39;t there three separate matrices?

If you look at the new OpenGL versions (OpenGL 3.x/4.x) and you don&#39;t use the classical render pipeline but customize everything with shaders (GLSL), there are no matrices available any longer at all, you have to define your own matrices. Still most people keep the old concept of a projection matrix and a model-view matrix. **Why would you do that?** Why not using either three matrices, which means you don&#39;t have to permanently save and restore the model-view matrix or you use a single combined model-view-projection (MVP) matrix, which saves you a matrix multiplication in your vertex shader for ever single vertex rendered (after all such a multiplication doesn&#39;t come for free either).

So to summarize my question: Which advantage has a combined model-view matrix together with a separate projection matrix over having three separate matrices or a single MVP matrix?

Why would it be beneficial to have a separate projection matrix, yet combine model and view matrix?

I&#39;ve been attempting to write a two-pass GPU implementation of the Marching Cubes algorithm, similar to the one detailed in the first chapter of GPU Gems 3, using OpenGL and GLSL. However, the call to `glDrawArrays` in my first pass consistently fails with a `GL_INVALID_OPERATION`.

I&#39;ve looked up all the documentation I can find, and found these conditions under which `glDrawArrays` can throw that error:

 1. `GL_INVALID_OPERATION` is generated if a non-zero buffer object name is bound to an enabled array or to the `GL_DRAW_INDIRECT_BUFFER` binding and the buffer object&#39;s data store is currently mapped.
 2. `GL_INVALID_OPERATION` is generated if `glDrawArrays` is executed between the execution of `glBegin` and the corresponding `glEnd`.
 3. `GL_INVALID_OPERATION` will be generated by `glDrawArrays` or `glDrawElements` if any two active samplers in the current program object are of different types, but refer to the same texture image unit.
 4. `GL_INVALID_OPERATION` is generated if a geometry shader is active and mode is incompatible with the input primitive type of the geometry shader in the currently installed program object.
 5. `GL_INVALID_OPERATION` is generated if mode is `GL_PATCHES` and no tessellation control shader is active.
 6. `GL_INVALID_OPERATION` is generated if recording the vertices of a primitive to the buffer objects being used for transform feedback purposes would result in either exceeding the limits of any buffer object’s size, or in exceeding the end position offset + size - 1, as set by `glBindBufferRange`.
 7. `GL_INVALID_OPERATION` is generated by `glDrawArrays()` if no geometry shader is present, transform feedback is active and mode is not one of the allowed modes.
 8. `GL_INVALID_OPERATION` is generated by `glDrawArrays()` if a geometry shader is present, transform feedback is active and the output primitive type of the geometry shader does not match the transform feedback primitiveMode.
 9. `GL_INVALID_OPERATION` is generated if the bound shader program is invalid.
 10. **EDIT 10/10/12:** `GL_INVALID_OPERATION` is generated if transform feedback is in use, and the buffer bound to the transform feedback binding point is also bound to the array buffer binding point. **This is the problem I was having, due to a typo in which buffer I bound. While the spec does state that this is illegal, it isn&#39;t listed under glDrawArrays as one of the reasons it can throw an error, in any documentation I found.**

Unfortunately, no one piece of official documentation I can find covers more than 3 of these. I had to collect this list from numerous sources. Points 7 and 8 actually come from the documentation for `glBeginTransformFeedback`, and point 9 doesn&#39;t seem to be documented at all. I found it mentioned in a forum post somewhere. However, I still don&#39;t think this list is complete, as none of these seem to explain the error I&#39;m getting.

 1. I&#39;m not mapping any buffers at all in my program, anywhere.
 2. I&#39;m using the Core profile, so `glBegin` and `glEnd` aren&#39;t even available.
 3. I have two samplers, and they are of different types, but they&#39;re definitely mapped to different textures.
 4. A geometry shader is active, but it&#39;s input layout is `layout (points) in`, and `glDrawArrays` is being called with `GL_POINTS`.
 5. I&#39;m not using `GL_PATCHES` or tessellation shaders of any sort.
 6. I&#39;ve made sure I&#39;m allocating the maximum amount of space my geometry shaders could possible output. Then I tried quadrupling it. Didn&#39;t help.
 7. There is a geometry shader. See the next point.
 8. Transform feedback is being used, and there is a geometry shader, but the output layout is `layout (points) out` and `glBeginTransformFeedback` is called with `GL_POINTS`.
 9. I tried inserting a call to `glValidateProgram` right before the call to `glDrawArrays`, and it returned `GL_TRUE`.

The actual OpenGL code is here:

        const int SECTOR_SIZE = 32;
        const int SECTOR_SIZE_CUBED = SECTOR_SIZE * SECTOR_SIZE * SECTOR_SIZE;
        const int CACHE_SIZE = SECTOR_SIZE + 3;
        const int CACHE_SIZE_CUBED = CACHE_SIZE * CACHE_SIZE * CACHE_SIZE;
        
        MarchingCubesDoublePass::MarchingCubesDoublePass(ServiceProvider* svc, DensityMap* sourceData) {
            this-&gt;sourceData = sourceData;
            densityCache = new float[CACHE_SIZE_CUBED];
        }
        
        MarchingCubesDoublePass::~MarchingCubesDoublePass() {
            delete densityCache;
        }
        
        void MarchingCubesDoublePass::InitShaders() {
            ShaderInfo vertShader, geoShader, fragShader;
            
            vertShader = svc-&gt;shader-&gt;Load(&quot;data/shaders/MarchingCubesDoublePass-Pass1.vert&quot;, GL_VERTEX_SHADER);
            svc-&gt;shader-&gt;Compile(vertShader);
            geoShader = svc-&gt;shader-&gt;Load(&quot;data/shaders/MarchingCubesDoublePass-Pass1.geo&quot;, GL_GEOMETRY_SHADER);
            svc-&gt;shader-&gt;Compile(geoShader);
            shaderPass1 = glCreateProgram();
            static const char* outputVaryings[] = { &quot;triangle&quot; };
            glTransformFeedbackVaryings(shaderPass1, 1, outputVaryings, GL_SEPARATE_ATTRIBS);
            assert(svc-&gt;shader-&gt;Link(shaderPass1, vertShader, geoShader));
            
            uniPass1DensityMap = glGetUniformLocation(shaderPass1, &quot;densityMap&quot;);
            uniPass1TriTable = glGetUniformLocation(shaderPass1, &quot;triangleTable&quot;);
            uniPass1Size = glGetUniformLocation(shaderPass1, &quot;size&quot;);
            attribPass1VertPosition = glGetAttribLocation(shaderPass1, &quot;vertPosition&quot;);
            
            vertShader = svc-&gt;shader-&gt;Load(&quot;data/shaders/MarchingCubesDoublePass-Pass2.vert&quot;, GL_VERTEX_SHADER);
            svc-&gt;shader-&gt;Compile(vertShader);
            geoShader = svc-&gt;shader-&gt;Load(&quot;data/shaders/MarchingCubesDoublePass-Pass2.geo&quot;, GL_GEOMETRY_SHADER);
            svc-&gt;shader-&gt;Compile(geoShader);
            fragShader = svc-&gt;shader-&gt;Load(&quot;data/shaders/MarchingCubesDoublePass-Pass2.frag&quot;, GL_FRAGMENT_SHADER);
            svc-&gt;shader-&gt;Compile(fragShader);
            shaderPass2 = glCreateProgram();
            assert(svc-&gt;shader-&gt;Link(shaderPass2, vertShader, geoShader, fragShader));
            
            uniPass2DensityMap = glGetUniformLocation(shaderPass2, &quot;densityMap&quot;);
            uniPass2Size = glGetUniformLocation(shaderPass2, &quot;size&quot;);
            uniPass2Offset = glGetUniformLocation(shaderPass2, &quot;offset&quot;);
            uniPass2Matrix = glGetUniformLocation(shaderPass2, &quot;matrix&quot;);
            attribPass2Triangle = glGetAttribLocation(shaderPass2, &quot;triangle&quot;);
        }
        
        void MarchingCubesDoublePass::InitTextures() {
            for (int x = 0; x &lt; CACHE_SIZE; x++) {
                for (int y = 0; y &lt; CACHE_SIZE; y++) {
                    for (int z = 0; z &lt; CACHE_SIZE; z++) {
                        densityCache[x + y*CACHE_SIZE + z*CACHE_SIZE*CACHE_SIZE] = sourceData-&gt;GetDensity(Vector3(x-1, y-1, z-1));
                    }
                }
            }
            glGenTextures(1, &amp;densityTex);
            glBindTexture(GL_TEXTURE_3D, densityTex);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);
            glTexImage3D(GL_TEXTURE_3D, 0, GL_R32F, CACHE_SIZE, CACHE_SIZE, CACHE_SIZE, 0, GL_RED, GL_FLOAT, densityCache);
            
            glGenTextures(1, &amp;triTableTex);
            glBindTexture(GL_TEXTURE_RECTANGLE, triTableTex);
            glTexParameteri(GL_TEXTURE_RECTANGLE, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
            glTexParameteri(GL_TEXTURE_RECTANGLE, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
            glTexParameteri(GL_TEXTURE_RECTANGLE, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
            glTexParameteri(GL_TEXTURE_RECTANGLE, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
            glTexImage2D(GL_TEXTURE_RECTANGLE, 0, GL_R16I, 16, 256, 0, GL_RED_INTEGER, GL_INT, triTable);
        }
        
        void MarchingCubesDoublePass::InitBuffers() {
            float* voxelGrid = new float[SECTOR_SIZE_CUBED*3];
            unsigned int index = 0;
            for (int x = 0; x &lt; SECTOR_SIZE; x++) {
                for (int y = 0; y &lt; SECTOR_SIZE; y++) {
                    for (int z = 0; z &lt; SECTOR_SIZE; z++) {
                        voxelGrid[index*3 + 0] = x;
                        voxelGrid[index*3 + 1] = y;
                        voxelGrid[index*3 + 2] = z;
                        index++;
                    }
                }
            }
            
            glGenBuffers(1, &amp;bufferPass1);
            glBindBuffer(GL_ARRAY_BUFFER, bufferPass1);
            glBufferData(GL_ARRAY_BUFFER, SECTOR_SIZE_CUBED*3*sizeof(float), voxelGrid, GL_STATIC_DRAW);
            glBindBuffer(GL_ARRAY_BUFFER, 0);
            
            glGenBuffers(1, &amp;bufferPass2);
            glBindBuffer(GL_ARRAY_BUFFER, bufferPass2);
            glBufferData(GL_ARRAY_BUFFER, SECTOR_SIZE_CUBED*5*sizeof(int), NULL, GL_DYNAMIC_COPY);
            glBindBuffer(GL_ARRAY_BUFFER, 0);
            
            glGenVertexArrays(1, &amp;vaoPass1);
            glBindVertexArray(vaoPass1);
            glBindBuffer(GL_ARRAY_BUFFER, bufferPass1);
            glVertexAttribPointer(attribPass1VertPosition, 3, GL_FLOAT, GL_FALSE, 0, (void*)0);
            glBindBuffer(GL_ARRAY_BUFFER, 0);
            glEnableVertexAttribArray(attribPass1VertPosition);
            glBindVertexArray(0);
            
            glGenVertexArrays(1, &amp;vaoPass2);
            glBindVertexArray(vaoPass2);
            glBindBuffer(GL_ARRAY_BUFFER, bufferPass2);
            glVertexAttribIPointer(attribPass2Triangle, 1, GL_INT, 0, (void*)0);
            glBindBuffer(GL_ARRAY_BUFFER, 0);
            glEnableVertexAttribArray(attribPass2Triangle);
            glBindVertexArray(0);
            
            glGenQueries(1, &amp;queryNumTriangles);
        }
        
        void MarchingCubesDoublePass::Register(Genesis::ServiceProvider* svc, Genesis::Entity* ent) {
            this-&gt;svc = svc;
            this-&gt;ent = ent;
            svc-&gt;scene-&gt;RegisterEntity(ent);
            
            InitShaders();
            InitTextures();
            InitBuffers();
        }
        
        void MarchingCubesDoublePass::Unregister() {
            if (!ent-&gt;GetBehavior&lt;Genesis::Render&gt;()) {
                svc-&gt;scene-&gt;UnregisterEntity(ent);
            }
        }
        
        void MarchingCubesDoublePass::RenderPass1() {
            glEnable(GL_RASTERIZER_DISCARD);
            
            glUseProgram(shaderPass1);
            glActiveTexture(GL_TEXTURE0);
            glBindTexture(GL_TEXTURE_3D, densityTex);
            glActiveTexture(GL_TEXTURE1);
            glBindTexture(GL_TEXTURE_RECTANGLE, triTableTex);
            glUniform1i(uniPass1DensityMap, 0);
            glUniform1i(uniPass1TriTable, 1);
            glUniform1i(uniPass1Size, SECTOR_SIZE);
            
            glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, bufferPass2);
            
            glBindVertexArray(vaoPass2);
            glBeginQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN, queryNumTriangles);
            glBeginTransformFeedback(GL_POINTS);
                GLenum error = glGetError();
                glDrawArrays(GL_POINTS, 0, SECTOR_SIZE_CUBED);
                error = glGetError();
            glEndTransformFeedback();
            glEndQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN);
            glBindVertexArray(0);
            
            glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, 0);
            
            glUseProgram(0);
            
            glDisable(GL_RASTERIZER_DISCARD);
            
            glGetQueryObjectuiv(queryNumTriangles, GL_QUERY_RESULT, &amp;numTriangles);
        }
        
        void MarchingCubesDoublePass::RenderPass2(Matrix mat) {
            glUseProgram(shaderPass2);
            
            glActiveTexture(GL_TEXTURE0);
            glBindTexture(GL_TEXTURE_3D, densityTex);
            
            glUniform1i(uniPass2DensityMap, 0);
            glUniform1i(uniPass2Size, SECTOR_SIZE);
            glUniform3f(uniPass2Offset, 0, 0, 0);
            mat.UniformMatrix(uniPass2Matrix);
            
            glBindVertexArray(vaoPass2);
            glDrawArrays(GL_POINTS, 0, numTriangles);
            glBindVertexArray(0);
            
            glUseProgram(0);
        }
        
        void MarchingCubesDoublePass::OnRender(Matrix mat) {
            RenderPass1();
            RenderPass2(mat);
        }

The actual error is the call to `glDrawArrays` in `RenderPass1`. Worth noting that if I comment out the calls to `glBeginTransformFeedback` and `glEndTransformFeedback`, then `glDrawArrays` stops generating the error. So whatever&#39;s wrong, it&#39;s probably somehow related to transform feedback.

**Edit 8/18/12, 9 PM:**

I just found the NVIDIA GLExpert feature in gDEBugger, which I wasn&#39;t previously familiar with. When I turned this on, it gave somewhat more substantial information on the `GL_INVALID_OPERATION`, specifically `The current operation is illegal in the current state:  Buffer is mapped.`. So I&#39;m running into point 1, above. Though I have no idea how.

I have no calls to `glMapBuffer`, or any related function, anywhere in my code. I set gDEBugger to break on any calls to `glMapBuffer`, `glMapBufferARB`, `glMapBufferRange`, `glUnmapBuffer` and `glUnmapBufferARB`, and it didn&#39;t break anywhere. Then I added code to the start of `RenderPass1` to explicitly unmap bother buffers. Not only did the error not go away, but calls to `glUnmapBuffer` now both generate `The current operation is illegal in the current state:  Buffer is unbound or is already unmapped.`. So if neither of the buffers I&#39;m using are mapped, where is the error coming from?

**Edit 8/19/12, 12 AM:**

Based on the error messages I&#39;m getting out of GLExpert in gDEBugger, it appears that calling `glBeginTransformFeedback` is causing the buffer bound to `GL_TRANSFORM_FEEDBACK_BUFFER` to become mapped. Specifically, when I click on the buffer in &quot;Textures, Buffers and Images Viewer&quot; it outputs the message `The current operation is illegal in the current state:  Buffer must be bound and not mapped.`. However, if I add this between `glBeginTransformFeedback` and `glEndTransformFeedback`:

    int bufferBinding;
    glGetBufferParameteriv(GL_TRANSFORM_FEEDBACK_BUFFER, GL_BUFFER_MAPPED, &amp;bufferBinding);
    printf(&quot;Transform feedback buffer binding: %d\n&quot;, bufferBinding);

it outputs 0, which would indicate that `GL_TRANSFORM_FEEDBACK_BUFFER` is not mapped. If this buffer is mapped on another binding point, would this still return 0? Why would `glBeginTransformFeedback` map the buffer, thus rendering it unusable for transform feedback?

The more I learn here, the more confused I&#39;m becoming.

**Edit 10/10/12:**

As indicated in my reply below to Nicol Bolas&#39; solution, I found the problem, and it&#39;s the same one he found: Due to a stupid typo, I was binding the same buffer to both the input and output binding points.

I found it probably two weeks after posting the question. I&#39;d given up in frustration for a time, and eventually came back and basically re-implemented the whole thing from scratch, regularly comparing bits and pieces the older, non-working one. When I was done, the new version worked, and it was when I searched out the differences that I discovered I&#39;d been binding the wrong buffer.

What can cause glDrawArrays to generate a GL_INVALID_OPERATION error?

Should I prefer to calculate matrices on the CPU or GPU? 

Let&#39;s say I have the following matrices `P * V * M` , should I calculate them on the CPU so that I can send the final matrix to the GPU (GLSL) or should I send those three matrices separately to the GPU so that GLSL can calculate the final matrix?

I mean in this case GLSL would have to calculate the MVP matrix for every vertex, so it is probably faster to precompute it on the CPU. 

But let&#39;s say that GLSL only has to calculate he MVP matrix once, would the GPU calculate the final matrix faster than the CPU?

Should I calculate matrices on the GPU or on the CPU?

I need to debug a GLSL program but I don&#39;t know how to output intermediate result.
Is it possible to make some debug traces (like with printf) with GLSL ?


How to debug a GLSL shader?

As the GPU driver vendors don&#39;t usually bother to implement `noiseX` in GLSL, I&#39;m looking for a *&quot;graphics randomization swiss army knife&quot;* utility function set, preferably optimised to use within GPU shaders. I prefer GLSL, but code any language will do for me, I&#39;m ok with translating it on my own to GLSL.

Specifically, I&#39;d expect:

a) **Pseudo-random functions** - N-dimensional, uniform distribution over [-1,1] or over [0,1], calculated from M-dimensional seed (ideally being any value, but I&#39;m OK with having the seed restrained to, say, 0..1 for uniform result distribution). Something like:

    float random  (T seed);
    vec2  random2 (T seed);
    vec3  random3 (T seed);
    vec4  random4 (T seed);
    // T being either float, vec2, vec3, vec4 - ideally.

b) **Continous noise** like Perlin Noise - again, N-dimensional, +- uniform distribution, with constrained set of values and, well, looking good (some options to configure the appearance like Perlin levels could be useful too). I&#39;d expect signatures like:

    float noise  (T coord, TT seed);
    vec2  noise2 (T coord, TT seed);
    // ...

I&#39;m not very much into random number generation theory, so I&#39;d most eagerly go for a **pre-made solution**, but I&#39;d also appreciate answers like *&quot;here&#39;s a very good, efficient 1D rand(), and let me explain you how to make a good N-dimensional rand() on top of it...&quot;* .

Random / noise functions for GLSL

There are already a number of questions about text rendering in OpenGL, such as:

* https://stackoverflow.com/questions/2071621/opengl-live-text-rendering

But mostly what is discussed is rendering textured quads using the fixed-function pipeline.  Surely shaders must make a better way.

I&#39;m not really concerned about internationalization, most of my strings will be plot tick labels (date and time or purely numeric).  But the plots will be re-rendered at the screen refresh rate and there could be quite a bit of text (not more than a few thousand glyphs on-screen, but enough that hardware accelerated layout would be nice).

What is the recommended approach for text-rendering using modern OpenGL?  (Citing existing software using the approach is good evidence that it works well)

* Geometry shaders that accept e.g. position and orientation and a character sequence and emit textured quads
* Geometry shaders that render vector fonts
* As above, but using tessellation shaders instead
* A compute shader to do font rasterization


What is state-of-the-art for text rendering in OpenGL as of version 4.1?

I&#39;m learning glsl shading and I&#39;ve come across different file formats. I&#39;ve seen people giving their vertex and fragment shaders `.vert` and `.frag` extensions. But I&#39;ve also seen `.vsh` and `.fsh` extensions, and even both shaders together in a single `.glsl` file. So I&#39;m wondering if there is a standard file format, or which way is the &#39;correct&#39; one?

What is the correct file extension for GLSL shaders?

I&#39;ve seen this pseudo-random number generator for use in shaders referred to [here and there around the web][1]:

    float rand(vec2 co){
      return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
    }


It&#39;s variously called &quot;canonical&quot;, or &quot;a one-liner I found on the web somewhere&quot;.

What&#39;s the origin of this function? Are the constant values as arbitrary as they seem or is there some art to their selection? Is there any discussion of the merits of this function?

EDIT: The oldest reference to this function that I&#39;ve come across is [this archive from Feb &#39;08][2], the original page now being gone from the web. But there&#39;s no more discussion of it there than anywhere else.


  [1]: https://www.google.com/search?q=fract%28sin%28dot%28co.xy%20,vec2%2812.9898,78.233%29%29%29%20*%2043758.5453%29&amp;rlz=1C1CHFA_enUS484US484&amp;oq=fract%28sin%28dot%28co.xy%20,vec2%2812.9898,78.233%29%29%29%20*%2043758.5453%29&amp;sugexp=chrome,mod=9&amp;sourceid=chrome&amp;ie=UTF-8
  [2]: http://web.archive.org/web/20080211204527/http://lumina.sourceforge.net/Tutorials/Noise.html

What&#39;s the origin of this GLSL rand() one-liner?

I want to know if &quot;if-statements&quot; inside shaders (vertex / fragment / pixel...) are really slowing down the shader performance. For example:

Is it better to use this:

    vec3 output;
    output = input*enable + input2*(1-enable);
instead of using this:

    vec3 output;
    if(enable == 1)
    {
        output = input;
    }
    else
    {
        output = input2;
    }

in another forum there was a talk about that (2013): http://answers.unity3d.com/questions/442688/shader-if-else-performance.html
Here the guys are saying, that the If-statements are really bad for the performance of the shader.

Also here they are talking about how much is inside the if/else statements (2012):
https://www.opengl.org/discussion_boards/showthread.php/177762-Performance-alternative-for-if-(-)

maybe the hardware or the shadercompiler are better now and they fix somehow this (maybe not existing) performance issue.

EDIT:

What is with this case, here lets say enable is a uniform variable and it is always set to 0:

    if(enable == 1) //never happens
    {
        output = vec4(0,0,0,0);
    }
    else  //always happens
    {
        output = calcPhong(normal, lightDir);
    }

I think here we have a branch inside the shader which slows the shader down. Is that correct?

Does it make more sense to make 2 different shaders like one for the else and the other for the if part?

Do conditional statements slow down shaders?

I see a lot of different fragment shaders,


    #version 130
    
    out vec4 flatColor;
    
    void main(void)
    {
        flatColor = vec4(0.0,1.0,0.0,0.5);
    }

And they all use a different variable for the &quot;out color&quot; (in this case `flatColor`). So how does OpenGL know what you&#39;re trying to do?

I&#39;m guessing this works because `flatColor` is the only variable defined as `out`, but you&#39;re allowed to add more `out` variables aren&#39;t you? Or would that just crash?

---

Actually, as a test, I just ran this:

    #version 330
    
    in vec2 TexCoord0;
    
    uniform sampler2D TexSampler;
    
    out vec4 x;
    out vec4 y;
    
    void main()
    {
        y = texture2D(TexSampler, TexCoord0.xy);
    }

It worked fine whether I used `x` or `y`.

(answer: the compiler is optimizing out the unused var, so the remaining var is assigned to location 0)

---

Furthermore, we have a predefined `gl_FragColor`. What&#39;s the difference, and why do people usually insist on using their own variables?

How does the fragment shader know what variable to use for the color of a pixel?

I want to send a list of values into a fragment shader. It is a possibly large (couple of thousand items long) list of single precision floats. The fragment shader needs random access to this list and I want to refresh the values from the CPU on each frame.

I&#39;m considering my options on how this could be done:

1. As a uniform variable of array type (&quot;uniform float x[10];&quot;). But there seems to be limits here, on my GPU sending more than a few hundred values is very slow and also I&#39;d have to hard-code the upper limit in the shader when I&#39;d rather would like to change that in runtime.

2. As a texture with height 1 and width of my list, then refresh the data using glCopyTexSubImage2D.

3. Other methods? I haven&#39;t kept up with all the changes in the GL-specification lately, perhaps there is some other method that is specifically designed for this purpose?


Passing a list of values to fragment shader

I would like to leave OpenGL&#39;s lights and make my own.
I would like my shaders to allow for a variable number of lights.

Can we declare an array of uniforms in GLSL shaders?
If so, how would we set the values of those uniforms?

Creating a GLSL Arrays of Uniforms?

I am trying to understand the `dFdx()` and `dFdy()` functions in GLSL.

I understand the following:

1. The derivative is the rate of change
2. The partial derivative of a function with two parameters is when you differentiate the function while keeping one of the parameters constant.
3. `dFdx()` and `dFdy()` find the rate that a value changes between the current fragment and a neighboring fragment.

I don&#39;t understand what the rate of change is referring to. Is it the rate of change of fragment coordinates?

Could it possibly be that you can find the rate of change of an **arbitrary variable** between two invocations of the fragment shader? Are the shader invocations &quot;reading&quot; variables from neighboring invocations? For a (simplistic) example:

    // invocation for fragment 1
    float x = 1.0;
    float d = dFdx(x);

    // invocation for fragment next to fragment 1 along the x axis.
    float x = 2.0;
    float d = dFdx(x);

Would `d` be -1.0 and 1.0 respectively?

Explanation of dFdx

Is it possible to access the individual elements of a glsl mat4 type matrix? How?

How do you access the individual elements of a glsl mat4?

I&#39;ve been knocking around Shadertoy - https://www.shadertoy.com/ - recently, in an effort to learn more about OpenGL and GLSL in particular. 

From what I understand so far, the OpenGL user first has to prepare all the geometry to be used and configure the OpenGL server (number of lights allowed, texture storage, etc). Once that&#39;s done, the user then has to provide at least one vertex shader program, and one fragment shader program before an OpenGL program compiles.

However, when I look at the code samples on Shadertoy, I only ever see one shader program, and most of the geometry used appears to be written directly into the GLSL code.

How does that work?

My guess is that a vertex shader is already prepared upfront, and that the editable/sample shader is only a fragment shader. But then that doesn&#39;t explain the geometry in some of the more complex examples...

Can anyone explain how Shadertoy works?



WebGL/GLSL - How does a ShaderToy work?

During OpenGL initialization, the program is supposed to do something like:

&lt;!-- language: lang-none --&gt;

	&lt;Get Shader Source Code&gt;
	&lt;Create Shader&gt;
	&lt;Attach Source Code To Shader&gt;
	&lt;Compile Shader&gt;

Getting source code could be as simple as putting it in a string like:
(Example taken from [**SuperBible, 6th Edition**][1])

&lt;!-- language: lang-cxx --&gt;

	static const char * vs_source[] =
	{
		&quot;#version 420 core                             \n&quot;
		&quot;                                              \n&quot;
		&quot;void main(void)                               \n&quot;
		&quot;{                                             \n&quot;
		&quot;    gl_Position = vec4(0.0, 0.0, 0.0, 1.0);   \n&quot;
		&quot;}                                             \n&quot;
	};

The problem is that it is hard to edit, debug and maintain GLSL shaders directly in a string. So getting the source code in a string from a file is easier for development:

&lt;!-- language: lang-cxx --&gt;

	std::ifstream vertexShaderFile(&quot;vertex.glsl&quot;);
	std::ostringstream vertexBuffer;
	vertexBuffer &lt;&lt; vertexShaderFile.rdbuf();
	std::string vertexBufferStr = vertexBuffer.str();
	// Warning: safe only until vertexBufferStr is destroyed or modified
	const GLchar *vertexSource = vertexBufferStr.c_str();

The problem now is how to ship the shaders with your program? Indeed, shipping source code with your application may be a problem. OpenGL supports &quot;pre-compiled binary shaders&quot; but the [**Open Wiki**][2] states that:

&gt; Program binary formats are not intended to be
&gt; transmitted. It is not reasonable to expect different hardware vendors
&gt; to accept the same binary formats. It is not reasonable to expect
&gt; different hardware from the same vendor to accept the same binary
&gt; formats. [...]

**How to practically ship GLSL shaders with your C++ software?**


  [1]: http://www.openglsuperbible.com/
  [2]: http://www.opengl.org/wiki/Shader_Compilation#Binary_limitations

How to Practically Ship GLSL Shaders with your C++ Software

I&#39;m tinkering with Joost van Dongen&#39;s[ Interior mapping shader]( http://interiormapping.oogst3d.net/) and I&#39;m trying to implement self-shadowing. Still I couldn&#39;t quite figure out what coordinates shadow casting light vectors need to be in. You can see somewhat working demo [at here][1]   I&#39;ve attached the light position with an offset to the camera position just to see whats happening but obviously it doesn&#39;t look right either.
Shader code is below. Look for SHADOWS DEV in fragment shader. Vectors in question are: **shad_E** and **shad_I**.

vertex shader:

    varying vec3 oP; // surface position in object space
    varying vec3 oE; // position of the eye in object space
    varying vec3 oI; // incident ray direction in object space
    
    varying vec3 shad_E; // shadow light position
    varying vec3 shad_I; // shadow direction
    
    uniform vec3 lightPosition;
    
    void main() {
    
    	// inverse veiw matrix
    	mat4 modelViewMatrixInverse = InverseMatrix( modelViewMatrix );
    
    	// surface position in object space
    	oP = position;
    
    	// position of the eye in object space
    	oE = modelViewMatrixInverse[3].xyz;
    
    	// incident ray direction in object space
    	oI = oP - oE; 
    
    	 // link the light position to camera for testing
    	 // need to find a way for world space directional light to work
    	shad_E = oE - lightPosition;
    
    	 // light vector
    	shad_I = oP - shad_E;
    
    	gl_Position = projectionMatrix * modelViewMatrix * vec4( position, 1.0 );
    }

fragment shader:

    varying vec3 oP; // surface position in object space
    varying vec3 oE; // position of the eye in object space
    varying vec3 oI; // incident ray direction in object space
    
    varying vec3 shad_E; // shadow light position
    varying vec3 shad_I; // shadow direction
    
    uniform vec3 wallFreq;
    
    uniform float wallsBias;
    
    uniform vec3 wallCeilingColor;
    uniform vec3 wallFloorColor;
    uniform vec3 wallXYColor;
    uniform vec3 wallZYColor;
    
    float checker(vec2 uv, float checkSize) {
      float fmodResult = mod( floor(checkSize * uv.x) + floor(checkSize * uv.y), 2.0);
    
      if (fmodResult &lt; 1.0) {
    	return 1.0;
      } else {
    	return 0.85;
      }
    }
    
    void main() {
    
    	// INTERIOR MAPPING by Joost van Dongen
    	// http://interiormapping.oogst3d.net/
    	// email: joost@ronimo-games.com
    	// Twitter: @JoostDevBlog
    	
    	vec3 wallFrequencies = wallFreq / 2.0 - wallsBias;
    
    	//calculate wall locations
    	vec3 walls = ( floor( oP * wallFrequencies) + step( vec3( 0.0 ), oI )) / wallFrequencies;
    
    	//how much of the ray is needed to get from the oE to each of the walls
    	vec3 rayFractions = ( walls - oE) / oI;
    
    	//texture-coordinates of intersections
    	vec2 intersectionXY = (oE + rayFractions.z * oI).xy;
    	vec2 intersectionXZ = (oE + rayFractions.y * oI).xz;
    	vec2 intersectionZY = (oE + rayFractions.x * oI).zy;
    
    	//use the intersection as the texture coordinates for the ceiling
    	vec3 ceilingColour = wallCeilingColor * checker( intersectionXZ, 2.0 );
    	vec3 floorColour = wallFloorColor * checker( intersectionXZ, 2.0 );
    	vec3 verticalColour = mix(floorColour, ceilingColour, step(0.0, oI.y));
    	vec3 wallXYColour = wallXYColor * checker( intersectionXY, 2.0 );
    	vec3 wallZYColour = wallZYColor * checker( intersectionZY, 2.0 );
    
    	// SHADOWS DEV // SHADOWS DEV // SHADOWS DEV // SHADOWS DEV //
    
    	vec3 shad_P = oP;  // just surface position in object space
    	vec3 shad_walls = ( floor( shad_P * wallFrequencies) + step( vec3( 0.0 ), shad_I )) / wallFrequencies;
    	vec3 shad_rayFr = ( shad_walls - shad_E ) / shad_I;
    
    	// Cast shadow from ceiling planes (intersectionXZ)
    
    	wallZYColour *= mix( 0.3, 1.0, step( shad_rayFr.x, shad_rayFr.y ));
    	verticalColour *= mix( 0.3, 1.0, step( rayFractions.y, shad_rayFr.y ));
   		wallXYColour *= mix( 0.3, 1.0, step( shad_rayFr.z, shad_rayFr.y ));
    
   		// SHADOWS DEV // SHADOWS DEV // SHADOWS DEV // SHADOWS DEV //
    
    	// intersect walls
    	float xVSz = step(rayFractions.x, rayFractions.z);
    	vec3 interiorColour = mix(wallXYColour, wallZYColour, xVSz);
    	float rayFraction_xVSz = mix(rayFractions.z, rayFractions.x, xVSz);
    	float xzVSy = step(rayFraction_xVSz, rayFractions.y);
    
    	interiorColour = mix(verticalColour, interiorColour, xzVSy);
    
    	gl_FragColor.xyz = interiorColour;	
    
    }


  [1]: http://www.vill.ee/interior/

Interior Mapping shader self shadowing

Does the variable that you&#39;re stuffing values into dictate what precision you&#39;re working with, to the right of the equals sign?

For example, is there any difference, of meaning, to the precision specifier here:

    gl_FragColor = lowp vec4(1);

Here&#39;s another example:

    lowp float floaty = 1. * 2.;
    floaty = lowp 1. * lowp 2.;

And if you take some floats, and create a vector or matrix from them, will that vector or matrix take on the precision of the values you stuff it with, or will those values transform into another precision level?

I think optimizing this would best answer the question:

    dot(gl_LightSource[0].position.xyz, gl_NormalMatrix * gl_Normal)

I mean, does it need to go this far, if you want it as fast as possible, or is some of it useless?

    lowp dot(lowp gl_LightSource[0].position.xyz, lowp gl_NormalMatrix * lowp gl_Normal)

I know you can define the default precision for float, and that this supposedly is used for vectors and matrices afterwards.  Assume for the purpose of education, that we had defined this previously:

    precision highp float;

All Glsl Solutions on Gang of Coders

Total of 22 Glsl Solutions