-3

I'm a newbie.. trying to learn shaders. I feel like its not that easy to code and debug it. Examples and tutorials I see on internet allows to code them in text files and read them as char pointer to pass them to shader compiler. Is there any best practices for coding - with intellisence , compiling , debugging ( printing the value some where in console atleast? ) And how to maintain and organise multiple shaders in a giant source code?

I'm using visual studio. Is there any tools or extensions for it to support opengl shaders?

If not is there any dedicated IDE only for opengl shaders? - if so how to organise them with other c++ source files in visual studio?.

How do they actually do it?

Thanks.

S.Frank Richarrd
  • 488
  • 1
  • 3
  • 15
  • 1
    If there are, I have yet to find one that makes much of a difference. If you're compiling the shaders with your C++ program, just be sure to alert the user of any errors using `glGetShaderInfoLog`. I've been working with them like this for a few years and have had no problems just writing them with a text editor. – TheTrueJard Jul 12 '18 at 05:14
  • Will that method provide debug information? Means printing a value in console ? – S.Frank Richarrd Jul 12 '18 at 05:16
  • Depends on what you're referring to. Shaders run on the GPU so there's no reliable way (that I know of) to get the same information as your average debugger such as keeping track of variables, following control paths etc. (though control path optimization doesn't even work because of parallelization on the GPU.) But it will still alert you of things you'd get from a console while compiling, like syntax errors with the line and column, and optionally warnings as well. – TheTrueJard Jul 12 '18 at 05:21
  • 1
    When I used to code some simple shaders, I remember that to debug them, I was for example assigning the value I wanted to observe to a color, so looking a the screen would tell me what the value was. – Olivier Sohn Jul 12 '18 at 05:49
  • @downvoters Why exactly is this a bad question? – MivVG Jul 12 '18 at 13:33
  • @MivVG mainly for two reasons: 1. asking for SW recomendation is off topic (there are different sites for those) 2. "best practice" is opinion based which is also off topic. Both reasons generate a lot of comment noise (that is why they are off-topic) and prohibits to be answerable (there is always something better, and better according to who/what/when?) I answered anyway as the text in form of comment would be not readable and I taught rookies should read it (risking downvotes). I tried to avoid any SW recommendations and concentrate more eon the coding/debugging techniques instead. – Spektre Jul 12 '18 at 14:35
  • Makes sense, thanks for clarifying – MivVG Jul 12 '18 at 16:23
  • @Spektre can u please let me know on which sites I can ask such type of questions? – S.Frank Richarrd Jul 12 '18 at 21:28
  • @S.FrankRicharrd I think [SE: Software recomendations](https://softwarerecs.stackexchange.com/) is the one. asking for GLSL IDE or debugger or something like that – Spektre Jul 12 '18 at 22:55

2 Answers2

2

The absolute minimum is to have access to GLSL compile and link logs here example:

For really hard stuff its best to write your shader as CPU side C++ code and when fully debugged then run it as shader. But for that you would need to write some kind of framework that would emulate shaders. For starters you need 1/2/3/4D vector and matrix arithmetics from GLSL. It is not that easy to code it but there are also another options like GLM. I am using my template but just to enable vec datatypes its around 228 KByte of hideous code due to its getters setters for more info look here:

And another absolute minimum is handling input and output. As the fun part is usually located in fragment itst often enough to process only fragment shader this way so you need just 2 nested loops looping through test image calling your shader main function and setting the pixel according to its result. I usually place #define texture(...)... to emulate texture access and that is in nutshell all. For example these shaders I would not be possible to debug otherwise:

As was mentioned in comments for simpler shaders you can write them in any C++ IDE to enable syntax highlight. But its a good idea to write/debug the stuff in your target App where you simply add some subwindow where you render the GLSL info logs as opening text file after each compilation is a dull click work.

When I started coding shaders I was tired of such and write my own IDE for shaders. Its buggy and far from perfect but it fulfills my needs. It looks like this:

GLSL IDE preview

Link to it is in (edit3) here:

There are some similar tools out there but having my own with source code allows a whole lot of stuff like using targets app CPU side code etc ...

Another very useful thing is to be able to print some variable value from fragment shader. Exactly that I was able to do like this:

you just need to decide correct conditions for entire area of the print (so the value you are printing is the same while printing all its pixels). This help me a lot especially to use 3D textures and geometry encoded in textures for the first time...

However in most cases you can use color output instead of debug prints but having the ability to print actual numbers can save you a lot of time.

Community
  • 1
  • 1
Spektre
  • 49,595
  • 11
  • 110
  • 380
0

I'm using visual studio. Is there any tools or extensions for it to support opengl shaders?

There is a GLSL Integration at Visual Studio Marketplace. I generally make a separate folder for shaders to organize them.

Its a bit hard and frustrating to debug shader code, but with practice and multiple iterations of debugging sessions it becomes more natural. I have started to experiment with my shaders at Shadertoy before porting them back at GLSL, which is surprisingly trivial.

Having said that, there are some cool tools you can use to debug your graphics, namely RenderDoc or AMD CodeXL

A friend suggested that I add vogl to the list of debuggers too. I have not used it, but heard good praises.

xsnk
  • 43
  • 4