Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualZouflain

Posted 09 September 2012 - 06:00 AM

@GeneralQuery yes, it compiles and links correctly with no errors. I have turned this into a pass through shader, and it does not fail to validate. It only fails to validate if the fragment shader makes direct reference to ex_Biom or ex_Elevation. In general, the method you describe is my default goto method for solving things like this (I am a very awful GLSL coder). Any other legitimate GLSL seems to work, but it must not use either input variable. OTHER shaders that work just fine use input and output variables without issue.

I can post the shader loading code if you honestly believe that will help, but it's a very basic read to buffer, pass to OpenGL, compile, link, and validate. It works fine for other shaders, so it seems very doubtful to be the loading code. Again, the problem ONLY occurs when voronoi.frag refers to ex_Biom or ex_Elevation.

(Given that the GPU will optimize out any variables it establishes have no impact on the output, I suspect voronoi.vert's use of in_/ex_<Val> is simply being optimized out, which explains why it does not matter what happens there and the program validates without changing the vertex shader. Since other shaders only pass varying (as opposed to flat) vecNs, I suspect something about the format of the variables is at issue.)

@Kaptein thank you for the link, but it didn't exactly help. Other shaders are validated before and after this one without issue, and there is no change in OpenGL's state between them.

#2Zouflain

Posted 09 September 2012 - 05:59 AM

@GeneralQuery yes, it compiles and links correctly with no errors. I have turned this into a pass through shader, and it does not fail to validate. It only fails to validate if the fragment shader makes direct reference to ex_Biom or ex_Elevation. In general, the method you describe is my default goto method for solving things like this (I am a very awful GLSL coder). Any other legitimate GLSL seems to work, but it must not use either input variable. OTHER shaders that work just fine use input and output variables without issue.

I can post the shader loading code if you honestly believe that will help, but it's a very basic read to buffer, pass to OpenGL, compile, link, and validate. It works fine for other shaders, so it seems very doubtful to be the loading code. Again, the problem ONLY occurs when voronoi.frag refers to ex_Biom or ex_Elevation.

(Given that the GPU will optimize out any variables it establishes have no impact on the output, I suspect voronoi.vert's use of in_/ex_<Val> is simply being optimized out, which explains why it does not matter what happens there and the program validates without changing the vertex shader. Since other shaders only pass varying (as opposed to flat) vecNs, I suspect something about the format of the variables is at issue.)

#1Zouflain

Posted 09 September 2012 - 05:56 AM

@GeneralQuery yes, it compiles and links correctly with no errors. I have turned this into a pass through shader, and it does not fail to validate. It only fails to validate if the fragment shader makes direct reference to ex_Biom or ex_Elevation. In general, the method you describe is my default goto method for solving things like this (I am a very awful GLSL coder). Any other legitimate GLSL seems to work, but it must not use either input variable. OTHER shaders that work just fine use input and output variables without issue.

I can post the shader loading code if you honestly believe that will help, but it's a very basic read to buffer, pass to OpenGL, compile, link, and validate. It works fine for other shaders, so it seems very doubtful to be the loading code. Again, the problem ONLY occurs when voronoi.frag refers to ex_Biom or ex_Elevation

PARTNERS