glsl

GLSL has a full C-style preprocessor. The only thing that does not work is #include. One of the great features is that that you can used #ifdef to comment out functions and thus create one shader that can be thinned out if certain features are not used. My Question is: Is there a way to define a macro from C code? There seems no way to do that with the openGL interface. The quick hack is to prepend a few lines with #define FOO before the code loaded form file. But it seems kind of backwards. You don't really need to prepend it to the code you loaded. That's why there are multiple strings in

I recently started programming with openGL. I've done code creating basic primitives and have used shaders in webGL. I've googled the subject extensively but it's still not that clear to me. Basically, here's what I want to know. Is there anything that can be done in GLSL that can't be done in plain openGL, or does GLSL just do things more efficiently? The short version is: OpenGL is an API for rendering graphics, while GLSL (which stands for GL shading language) is a language that gives programmers the ability to modify pipeline shaders. To put it another way, GLSL is a (small) part of the

Two questions really... Is GLSL ES 2 a totally separate language, or a special version of GLSL? What are the differences between them, in terms of "standard library" functions, syntax and capabilities? I am writing shaders for an application targeted at Windows, Mac and iPad and I would prefer not to have to add more versions of each shader - well simpler shaders anyway. Is GLSL ES 2 a totally separate language, or a special version of GLSL? Every version of GLSL is ultimately a "totally separate language;" some aren't even backwards compatible with previous versions. However, the ES variation

I'm trying to implement a 2D outline shader in OpenGL ES2.0 for iOS. It is insanely slow. As in 5fps slow. I've tracked it down to the texture2D() calls. However, without those any convolution shader is undoable. I've tried using lowp instead of mediump, but with that everything is just black, although it does give another 5fps, but it's still unusable. Here is my fragment shader. varying mediump vec4 colorVarying; varying mediump vec2 texCoord; uniform bool enableTexture; uniform sampler2D texture; uniform mediump float k; void main() { const mediump float step_w = 3.0/128.0; const mediump

Are point sprites the best choice to build a particle system? Are point sprites present in the newer versions of OpenGL and drivers of the latest graphics cards? Or should I do it using vbo and glsl? Point sprites are indeed well suited for particle systems. But they don't have anything to do with VBOs and GLSL, meaning they are a completely orthogonal feature. No matter if you use point sprites or not, you always have to use VBOs for uploading the geometry, be they just points, pre-made sprites or whatever, and you always have to put this geometry through a set of shaders (in modern OpenGL of

When you are learning 3D programming, you are taught that it's easiest think in terms of 3 transformation matrices: 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. "The Model Matrix transforms model coordinates to world coordinates". 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 "camera position". If you imaging that the 3D scene is filmed by a

Which is better ? To have one shader program with a lot of uniforms specifying lights to use, or mappings to do (e.g. I need one mesh to be parallax mapped, and another one parallax/specular mapped). I'd make a cached list of uniforms for lazy transfers, and just change a couple of uniforms for every next mesh if it needs to do so. To have a lot of shader programs for every needed case, each one with small amount of uniforms, and do the lazy bind with glUseProgram for every mesh if it needs to do so. Here I assume that meshes are properly batched, to avoid redundant switches. Most modern

I have some trouble with my normal matrix. vs.glsl #version 440 in vec3 vPosition; in vec3 vNormal; out vec4 eyeCordFs; out vec4 eyeNormalFs; uniform mat4 model; uniform mat4 view; uniform mat4 proj; void main() { mat4 modelView = view * model; mat4 normalMatrix = view * transpose(inverse(model)); vec4 eyeNorm = normalize(normalMatrix * vec4(vNormal, 0.0)); vec4 eyeCord= modelView * vec4(vPosition, 1.0); eyeCordFs = eyeCord; eyeNormalFs = eyeNorm; gl_Position = proj * modelView * vec4( vPosition,1.0); } fs.glsl #version 440 in vec4 eyeCordFs; in vec4 eyeNormalFs; out vec3 outputColor; uniform

I'm wondering if anyone has complete, working, and efficient code to do bicubic texture filtering in glsl. There is this: http://www.codeproject.com/Articles/236394/Bi-Cubic-and-Bi-Linear-Interpolation-with-GLSL or https://github.com/visionworkbench/visionworkbench/blob/master/src/vw/GPU/Shaders/Interp/interpolation-bicubic.glsl but both do 16 texture reads where only 4 are necessary: https://groups.google.com/forum/#!topic/comp.graphics.api.opengl/kqrujgJfTxo However the method above uses a missing "cubic()" function that I don't know what it is supposed to do, and also takes an unexplained