How shaders work in my program?

do I need to write them in my program once and forget about them?

If your current shaders do what you expect them to do, you do not need to modify them. If you need new functionality, you need to modify them. Just like any other code.

I have looked at so many tutorials but its really hard for me to understand them.

Without specific questions it's a bit difficult to give any answers. What exactly is causing you troubles?

Why people write their vertex shader and fragment shader in txt file?

OpenGL shaders are handed as text to the driver. How you get that text is completely up to you. Having them as text files in the application's data directory can be convenient because you can modify them without having to recompile the executable.

and why when I write #version 150 in my code it just mark it in red zigzag.

You will have to clear that up with whatever text editor or IDE you are using. Possibly it's just the spellchecker.

Hey LiziPizi,

Just regarding your post, From what i can see, you are unsure how to actually get the shader to run- And i think this is backed up by your red line mentioned above.

What i am assuming is that you are writing this is if it was normal code onto the screen - But the shader code itself is actually meant to be in a string, and this string is then compiled/whatever. People add them to txt files, as it keeps your source code from getting cluttered.

Im only looking at opengl3 now myself, so i cant really help anymore with this - but i found this site to be a great place to start : http://www.arcsynthesis.org/gltut/

TLDR; Wrap your shader code in quotes, and make it a string

Yes, it looks like you have added it to your project somehow, as if it was C/C++ code.

Shader code is either loaded from a file, or a multiline string http://stackoverflow.com/questions/20508534/c-multiline-string-raw-literal

Hi,

Shaders add enormous capability to improve the appearance of objects. For example, water in a game typically depends heavily on shaders to look, well, like water. Procedural shaders can be used to create realistic rock appearance of things such as mountains with fewer polygons and little or no UV mapping of texture files, which is a gigantic boost in game performance usually. Shine on metal, artificial texture of fabrics, and many other things can be emulated by using shaders. Most AAA popular 3D video games use shaders a lot and this is industry standard. Ever notice a realistic looking wood in a game? That might have been created with procedural shading. Other shaders are for the look of soil, debris, leaves on trees and other plants, and much more.

Speaking of standards, eventually you will be using the folder and file formats and/ or procedural algorithms which is common in the industry and/or the game engine that you will use in the future. This things have been developed with literally millions of hours of work to sort the issues and implement them in games.

These wheels called shaders have been invented already, but you can make your own custom shaders. There are SDKs which specialize in shader development. These can come as a plug-in for a 3D software such as 3ds Max or included in an SDK or IDE for creating the coding. Game engines sometimes come with shader SDK for you. Added to this, there are templates which can be taken and customized, which is a very time efficient way of creating shaders.

As a 3D graphics artist, I use a 3D modeling software to apply shaders to models in standard or game engine form. With a 3D object, the shader work that is done will be saved in a file which is created by the 3D software when the model changes are "saved" or exported with the model. Usually the shader file is in the 3D model folder but can be external when the game engine needs it to be more accessible. An example of this is when the 3D model folder is encrypted but the game designer needs to be able to make changes to the shader file later, in such case it might be an external file.

It is possible to reinvent the wheel and make all shading in your game from pure game source code, but this is much more work in the long term. For a hobby, this is no problem because it is for fun! If you want to work with shaders long term as something you need to do as a professional then you need to learn the industry or game engine standard methods of creating shaders.

first thing you should get clear yourself with on your path to understand shaders is to (first) know what they ask from application to render right. And this is far from trivial, it is actualy thing that will get you knowing them very advanced.

So, the data for the pepilne of vertex/pixel shader is:

1-) uniform variables - it is data that stays constant during entire shader, wheather pixel or vertex (matrix that transforms constant verticies in stream during the draw and so on)

2-) attribute stream - this is volatile input to vertex shader , the actual verticies with attributes (position, texture coordinate..), it is a different data for every vertex function execution (unlike uniforms) , you should learn how to provide them. Do not confuse with the fact the stream is constant in GPU memory , provided once by CPU (preferably)

3-) varying variable - this is not computed by CPU (you) but by the vertex shader and it travels to pixel shader. Pixel shader computes the pixels on the triangle by the help of interpolating those vertex shader outputs. (do not think that result of vertex shader stays constant for pixel triangle, it varies acros its surface upon barycentric interpolation of fragment position in triangle).

4-) result of pixel shader is written to target, the 4 component vector (color usualy).

To summarize, vertex shader needs uniforms and stream, and pixel shader needs uniforms and varying input from vertex shader.

Since, this is quite restrictive model of pipeline, it is very native to GPUs. But this does not describe exactly geometry/vertex/pixel shader approach of newer dx and opengl libraries they brought offering.