PDA

View Full Version : Geometry Shader pass through



Luecxjee
08-08-2016, 09:44 AM
Dear forum,

I got a problem i am not able to solve alone with my geometry shader.
I never really worked with them so i've read some tutorials but sadly, my code seems not to be working.
Below is my code of my vs, gs and fs. In the vs and fs i did not copy the whole code and calculation because i think, that i not needed for finding the problem due the fact
that my code is working perfectly without a geometry shader.

VS:



#version 400 core

in vec3 position;
in vec2 textureCoords;
in vec3 normal;
in vec3 tangent;

out vec2 pass_textureCoords;
out vec3 toLightVector[4];
out vec3 toCameraVector;
out float fogFactor;

uniform mat4 transformationMatrix;
uniform mat4 projectionMatrix;
uniform mat4 viewMatrix;
uniform vec3 lightPositionEyeSpace[4];
uniform float textureStretch;

uniform float fogGradient;
uniform float fogDensity;

void main(void) {........}



GS:


#version 150

layout(triangles) in;
layout (triangle_strip, max_vertices=6) out;

in VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexIn[3];

out VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexOut;

void main()
{
for(int i = 0; i < gl_in.length(); i++)
{
// copy attributes
gl_Position = gl_in[i].gl_Position;
VertexOut.pass_textureCoords = vec2(1,1);
VertexOut.toLightVector = VertexIn[i].toLightVector;
VertexOut.toCameraVector = VertexIn[i].toCameraVector;
VertexOut.fogFactor = VertexIn[i].fogFactor;


// done with the vertex
EmitVertex();
}
EndPrimitive();
}




And finally the FS:


#version 400 core

in vec3 toLightVector[4];
in vec2 pass_textureCoords;
in vec3 toCameraVector;
in float fogFactor;

out vec4 out_Color;

uniform sampler2D modelTexture;
uniform sampler2D normalMap;

uniform vec3 lightColour[4];
uniform vec3 attenuation[4];
uniform float shineDamper;
uniform float reflectivity;
uniform float useLighting;

uniform vec3 fogColor;
uniform float fog;

void main(void) {.......}



My render method looks like this:


GL11.glDrawElements(GL11.GL_TRIANGLES, model.getRawModel().getVertexCount(), GL11.GL_UNSIGNED_INT, 0);


Befor i load the uniform variables i call these methods:


GL11.glEnable (GL11.GL_BLEND);
GL11.glBlendFunc (GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);
GL11.glEnable(GL11.GL_DEPTH_TEST);



It would be great if someone could take his time and find my problem :)

Alfonse Reinheart
08-08-2016, 10:32 AM
You should always look at your compilation and linking errors (https://www.opengl.org/wiki/Shader_Compile_Error). I know you didn't, because they would otherwise have told you what I'm about to tell you.

Interface matching between stages (https://www.opengl.org/wiki/Interface_Matching) requires that, if you use an interface block on one side, you must use an identical interface block on the other side with the same name. Your GS uses input and ouptut interface blocks, but neither your vertex or fragment shaders use interface blocks at all.

Also, your GS version number should probably match that of your VS and FS. It's not required, but it's odd to do otherwise.

Luecxjee
08-08-2016, 10:45 AM
You should always look at your compilation and linking errors (https://www.opengl.org/wiki/Shader_Compile_Error). I know you didn't, because they would otherwise have told you what I'm about to tell you.

Interface matching between stages (https://www.opengl.org/wiki/Interface_Matching) requires that, if you use an interface block on one side, you must use an identical interface block on the other side with the same name. Your GS uses input and ouptut interface blocks, but neither your vertex or fragment shaders use interface blocks at all.

Also, your GS version number should probably match that of your VS and FS. It's not required, but it's odd to do otherwise.

Well that sounds logical, but how would i write it then ? Would it mean i need to write something like this ?:


in vec2 pass_textureCoords[3];
in vec3 toLightVector[4][3];
in vec3 toCameraVector[3];
in float fogFactor[3];

out vec2 pass_textureCoords[3];
out vec3 toLightVector[4][3];
out vec3 toCameraVector[3];
out float fogFactor[3];




Also... normally if there is a compile error its printed in the console.
This is not printing anything O.o

GClements
08-08-2016, 11:13 AM
Well that sounds logical, but how would i write it then ? Would it mean i need to write something like this ?:

You can't have inputs and outputs with the same names. You'd have to change one set, which means that you'd also have to change the names in the associated shader (i.e. if you rename the GS inputs, you'll also need to rename the VS outputs; if you rename the GS outputs, you'll need to rename the FS inputs). In turn, this means that you can't make the GS optional, as the VS outputs don't match the FS inputs.

All things considered, it's likely to be simpler to use interface blocks throughout (i.e. use interface blocks for the VS outputs and FS inputs as well as for the GS).



Also... normally if there is a compile error its printed in the console.

An implementation isn't required to report compilation and linking errors other than via glGetShaderInfoLog() and glGetProgramInfoLog(). An interface mismatch won't generate compilation errors but will generate linking errors.

Luecxjee
08-08-2016, 11:19 AM
You can't have inputs and outputs with the same names. You'd have to change one set, which means that you'd also have to change the names in the associated shader (i.e. if you rename the GS inputs, you'll also need to rename the VS outputs; if you rename the GS outputs, you'll need to rename the FS inputs). In turn, this means that you can't make the GS optional, as the VS outputs don't match the FS inputs.

All things considered, it's likely to be simpler to use interface blocks throughout (i.e. use interface blocks for the VS outputs and FS inputs as well as for the GS).


An implementation isn't required to report compilation and linking errors other than via glGetShaderInfoLog() and glGetProgramInfoLog(). An interface mismatch won't generate compilation errors but will generate linking errors.


Thank you very much ! :)

john_connor
08-08-2016, 11:24 AM
in your vertex shadder, add:


out VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexIn;

and in its main function, assign values to the block members:


void main(void) {
// ...

VertexIn.pass_textureCoords = textureCoords;
// etc pp
}


now the vertex shader passed the texture coords to the GS
afaik, the name "VertexIn" has to match the corresponding blocks instance name in GS

in you fragment shader, add:


in VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexOut;


again, "VertexOut" must match teh blocks instance name in FS

Alfonse Reinheart
08-08-2016, 12:21 PM
afaik, the name "VertexIn" has to match the corresponding blocks instance name in GS

That is incorrect. Interface block instance names don't have to match. So the VS does not have to use the instance name `VertexIn` on the interface block.

Now, the output interface block name `VertexData` does have to match with the next stage's input block. But the instance names don't have to match.

Same goes for the FS input block.

Luecxjee
08-08-2016, 12:37 PM
in your vertex shadder, add:


out VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexIn;

and in its main function, assign values to the block members:


void main(void) {
// ...

VertexIn.pass_textureCoords = textureCoords;
// etc pp
}


now the vertex shader passed the texture coords to the GS
afaik, the name "VertexIn" has to match the corresponding blocks instance name in GS

in you fragment shader, add:


in VertexData {
vec2 pass_textureCoords;
vec3 toLightVector[4];
vec3 toCameraVector;
float fogFactor;
} VertexOut;


again, "VertexOut" must match teh blocks instance name in FS



Perfect !!! :) Thank you very much :)

Luecxjee
08-08-2016, 03:00 PM
That is incorrect. Interface block instance names don't have to match. So the VS does not have to use the instance name `VertexIn` on the interface block.

Now, the output interface block name `VertexData` does have to match with the next stage's input block. But the instance names don't have to match.

Same goes for the FS input block.

Yeah, also figured out that. Was wondering why wierd stuff was displayed because i messed up with that one :)