• Forum
  • Lounge
  • What all can you do with shaders in Open

What all can you do with shaders in OpenGL?

What does this mean?

I know shaders are pretty powerful, and I've seen some of the cool shader packs for Minecraft, but I haven't messed much with OpenGL and I don't really know how shaders work or what they are. Are they just a sort of portable scripting language for OpenGL? Could you actually make an entire game (or just its render engine) with just shaders?
He probably meant he's going to use OpenGL 3.3, since it forces you to use shaders for everything, even the most basic geometric shape.
This means he could even use more complex shaders like water reflections/refractions and so on.
You don't need 3.3 to use shaders. It's especially inconvenient if you have a codebase using <3.3.
It's not a scripting language. It's compiled and then loaded into your gpu's memory. It
s sort of like c for your GPU. You can't make a whole game with it. It runs on the GPU, and is suited for things like matrix and vector operations, but not things like conditionals, branching, etc. It is designed specifically for the programmable pipeline ( see fixed vs programmable pipeline ).


Last edited on
Obligatory link for people wanting to learn more about OpenGL:


I don't really know how shaders work or what they are. Are they just a sort of portable scripting language for OpenGL?

Kind of, yeah. OpenGL is given various information (like vertex positions and whatnot)... and shaders tell it what to do with that information.

Fragment shaders effectively give you pixel-level control over a polygon. This allows for all sorts of stuff. Lighting effects, normal mapping, texture animations, color cycling, etc, etc, etc.
I generally think of it like: OpenGL is given various amounts of information and OpenGL asks the shaders what to do with it.
@NoXzema: You may not need 3.3 to use shaders, but in 3.3 VBOs are core (which means, requesting a 3.3 context MUST give back VBO functionalities).
Right now Minecraft uses glVertex* (probably under the form of glCallList) which is incredibly slower than VBOs.
You can create cool effects using shaders. They are little programs used to manipulate the OpenGL pipeline, so they are part of a modern game not the total game. You can make effects like realistic water, moving flags etc

See: http://talkera.org/opengl
Last edited on
One thing worth mentioning that I haven't seen yet (though Disch alluded to it for fragments) is that shaders typically come in two forms (though there are more): vertex and fragment shaders.

Vertex shaders perform per-vertex operations. That is, ever vertex you pass to OpenGL will run through your vertex shader code.

Fragment shaders perform per-pixel operations, as Disch said.

As many have mentioned, these run on your GPU, not your CPU like regular code. These operations are typically faster on GPU, the above per-vertex/per-fragment mindset should be observed. For example, I've seen a few shaders that perform the M * V * P calc shader-side, meaning it's calc'd for every vertex. If your model has, say, 16,000 vertices, that's a lot of calculations given that you can calculate it once on the CPU and pass over the resulting matrix.

Also, I think it's worth mentioning that shaders aren't just for 'x' effect. They're integral to OpenGL now, for even the most basic rendering. If you're not using a simple pass-through shader for OpenGL then you're already about 11 years behind.

Lots of good links knocking about and the arcsynthesis link that Disch posted is a regular go-to (no bad code pun intended) for me.
Last edited on
I've been learning how to use shaders with the thought of using them for matrix manipulation in a neural net
Why not simply use OpenCL or CUDA?
Why not simply use OpenCL or CUDA?

For funsies, mostly.
Just to give a layman's idea of the use of shaders, Skyrim can be run with them turned off. The result is a completely white screen.

I have a couple quick questions about shaders. They basically stem from the fact that we are dealing with ids in our code:
GLuint program_id = glCreateProgram();
GLuint shader_id = glCreateShader( type );
// set source and compile shader
glAttachShader( program_id, shader_id );
glUseProgram( program_id );

To me, this implies that OpenGL allows us to use more than one glProgram, and thus create more than one shader file ( glsl code ) that contains a main() function. Is this true? Is more than one of these items a reasonable thing for our program to contain?

To me, this implies that OpenGL allows us to use more than one glProgram, and thus create more than one shader file ( glsl code ) that contains a main() function. Is this true?


Is more than one of these items a reasonable thing for our program to contain?


Different shaders can have vastly different effects. Remember the shader basically is a program that tells OpenGL how to draw the image. So different shaders can let you draw things in different ways.
Would we use a different shader for every material?
Probably not. You could just change some parameters for different materials.
glUseProgram(program_id); // -> Set this program as the currently active one
glUniform[Matrix][1234][ifd ui](...); // -> Send some informations to Uniform variables
// (Only for the currently active program)
// (Uniform variables can change at most once for each draw call.
// Their value cannot change from one vertex to another.
// You use vertex attributes for that, following the texture coordinates path,
// using an unique attribute ID.)
glBindVertexArray(vertex_array_id); // -> Bind this vertex array (in poor words, set this model as current model for drawing commands)
glDrawArrays/glDrawElements(...); // -> Draw this vertex array with program_id->main(),
// using the uniform variables set from glUniform, and the model chosen from BindVertexArray. 

Anyways, checking his profile, I saw this:
Mo' vertex buffers, mo' problems.

Taking into consideration Vertex buffers is the short for VBOs, I feel I'm right.
Also, skeletal animations...
With skeletal animations, I feel like we'll be needing slightly more VRAM than usual.
Based on the amount of bones, we will probably need 16 floats for each bone (a mat4) plus a uint (or multiple uint-float couples for bone weighting, probably not happening for a game like Minecraft anyways) each model vertex on the VRAM side (which is not a lot these days).

Since Minecraft's issue is not the VRAM itself (if developed correctly enough, sharing blocks can save a lot of video memory) sounds like a good step forward.
That is, unless they choose to use buffer uniforms to store the map.
That requires a lot more thinking to be done correctly.

I think they want an optimized gl3/4~ engine by version 2.
If the shaders aren't kept hidden enough, wallhacks will be easier than usual to do. Since an optimal texturing means passing the texture id via uniforms, It's enough to check the texture id in the shader, and reject the fragment drawing if it's a regular block.
Note: These details are based on how Minecraft works.
Most games have a different texture for each object.
As long as Minecraft doesn't work this way, the above note stays alive.
Glad to see that openGL guide is still spreading, seriously one of the best tutorials I've ever read for anything related to programming.
I remember making a thread on here a few years back recommending it.
Topic archived. No new replies allowed.