GLSL Syntax Error in CelShadingSample

Jun 25, 2012 at 12:58 PM

I'm trying to gain some insight into GLSL by running the CelShadingSample in the WPF Samples.  Stepping through the code in the MainWindow code behind, when either of the shaders try to compile (e.g., line 101: vertexShader.Compile();) the compile fails with a syntax error in the InfoLog:

ERROR:1:1: ":syntax error #version\n\n"

Note that (as far as I can tell) this isn't an error about the version number.  If I change the version number in the included glsl file (say, change the first line from "#version 130" to "#version 330") then I can get an additional error noting that the version is unsupported (while STILL getting the above syntax error).

I'm at a loss.  A google search found a StackOverflow question about the same error, and the resolution was as follows:

"Solved! It had nothing to do with OpenGL. My file reader code was dropping all line breaks. This was fine in the body of the shader, which had semicolons. But the preprocessor directive had no semicolon to protect it from this error.

So for anyone with this problem, make sure the code you're actually passing to glShaderSource still has its line breaks."

I'm brand new to glsl, and I don't know how to address this issue in the CelShadingSample.  Do others find this same problem?  Is there a fix?


Jun 25, 2012 at 6:51 PM


Trying this on another machine yielded a different compile error.  I don't have access to the first machine I used (I will this evening) but on this second machine it complained of an invalid token ("<null atom>") and an uunexpected $end token.

I can get the glsl to compile on this second machine (thanks to a friend whose GoogleFu is much better than mine) by changing the way the SharpGL Shader sends lines from a file to the ShaderSource call:

In Shader.cs, the LoadSoruce method reads all the lines from a filel path and sends them in one string to SetSource.  SetSource takes a string source and (after ensuring that "\r" and "\t" characters are removed) splits it using newline marks (\n) into an array of lines.  It then sends that array to the ShaderSoruce call, which puts a null character at the end of each line in the array, notes the final length of each line in a "lengths" array, and sends all the pertinent data to the glShaderSource.

At least with my current hardware, the glShaderSource's resulting concatenation of the string arrays (each ending in a null character) seems to cause a problem.  However, if I modify the SetSource call to take the input string, remove "\r" and "\t" characters, puts the entire string as the only entry in a string array (e.g., string[] sourceParam = string[]{ source };) and then send that single-line array to the ShaderSource, THEN compling works!  It seems that the compiler isn't happy after concatenating the lines it receives from the glShaderSource; however, there doesn't seem to be a compelling reason for splitting the string across lines (and if you do, you have to make sure that when the are concatenated back together, they mantain newline characters).

So, I got the compiling to work, but I ended up with a blank black screen.  It turns out that in the main OpenGLDraw method in the sample, the projection, modelView, and normalMatrix variables (which are sent to the shader) are never set.  I can set them to 1's on the diagonal and I get _something_, but I'm still working on seeing something that makes sense.

SO, Looks like the CelShadingSample might have a few issues that need to be corrected.  I'll post again if I discover anything new.

Jul 17, 2012 at 12:13 PM

I can compile it fine (at least, VS doesn't complain about anything), but I see some kind of jagged black-and-white pattern.  Is this what I'm supposed to see? 


I'm also having problems with my own custom shaders, written with GLSL version 4.00 and loaded with File.ReadAllLines traditional OpenGL methods, not the Scenegraph ones.  The vertex shader works fine, but the shape is always a solid red, no matter what I pass to my fragment shader.  Is there a problem with the way SharpGL handles passing shader data, or is the problem with File.ReadAllLines or something else on my end, like a driver, maybe? 

Aug 5, 2012 at 11:46 PM

After a bit more testing, I'm beginning to think the vertex shader doesn't work either.  The shader is:

#version 400

layout(location=0) in vec4 in_Position;
layout(location=1) in vec4 in_Color;
out vec4 ex_Color;

void main(void)
	vec4 a = in_Position;
	a.z = a.z * 10.0;
	gl_Position = gl_ModelViewProjectionMatrix * a;
	ex_Color = in_Color;


Which is supposed to stretch any shapes along the z-axisby a factor of 10, but I can see no difference.  Does anyone have any ideas what might be wrong? 

Jan 28, 2013 at 11:50 AM

Some issue in this area have now been resolved, this should work from SGL 2.1 onwards, which will be released very shortly.

Jan 30, 2013 at 10:27 PM
OK, SGL 2.1 is out now, I've done some improvements with the shaders but STILL can't get the cel-shader to work properly, however, I cannot let it block the release any longer. I'm working on it again now. In the cel-shader it seems to me that actually the shader is working properly, however I don't think the geometry in the vertex/normal/index buffers is rendered correctly (rendering the trefoil without the shader and buffers works fine, with the buffers it shows very distorted geometry, with the shaders and buffers it shows very distorted geometry with a hint of cel shading).

So I'm going to investigate the sample further, I'll keep this thread up to date with the progress.