GLSL Varying Variables In QC 4

sample composition or it didn't happen. ;)

but more seriously: I've seen this on rare occasions in QC3 (normally when I'm rewriting a shader, or mismatching vertex and fragment shaders, such that the vertex shader is computing varyings that the fragment shader doesn't make use of).

There might be some trickery here because of how shadows work in QC4 (they use a custom GLSL shader, and might have changed the internals, such that it's executing your vertex shader but with their fragment shader, causing inactive varyings) -- without a sample compo, it's impossible to tell.

Off the top of my head, I've had that happen in Leopard a couple of times when putting shader examples into the GLSL patch.... I remember this happening to me in QC3 with a varying light parameter. I don't know if that was the case with all varying variables, but I was under the impression it was. It could have been the situation Chris describes, because I didn't investigate it too hard... the original code could have been messed up.

Good point, cwright.

The composition I posted here http://kineme.net/Discussion/DevelopingCompositions/OpenCLRayTracedQuate... seems to suffer from this issue. The varying is definitely written in the VS, and read (and used) in the FS. It doesn't look like the varying is being properly passed though, as when you rotate the texture coords (to rotate the rendered Julia Set), the position of the virtual camera should also be moved, via a varying called 'eyePos'- and it doesn't look like it is, to me.

a|x

Incidentally, your spam-catcher seems to be a bit over-zealous these days. Everything I've posted today has been suspected of being spam, apparently.

interesting -- I'll try to take a look when I have a moment (thanks for the composition).

regarding the spam catcher; we recently installed a new spam catcher (the incidence of spam has been increasing, and we were missing it for progressively longer and longer periods of time), so we're still configuring it. If it flags something as spam, please email info@kineme.net so we're aware of the issue (formally) and can look at fine-tuning it. (Ideally, we hope to have it be much smarter and not make these kinds of mistakes). Sorry for the additional overhead :/

Playing with this for a bit, and I think the issue is how QC parses the GLSL. If you move all of the uniform and varying declarations to the top before the function declarations before main, the error goes away. I also removed some comments that had odd characters in it, and the error no longer appears. All of the code (including comments) is passed to the GLSL compiler. Typically I would keep it as strict/safe ascii only, upper, lower and comment chars, and not use odd things like bullet points. GLSL in the QC Macro is already touchy enough as it is :)

Hiya vade.

That could be it... I guess it's probably bad practice to declare variables in different places in the code, rather than all at the top. I've tended to do that in the past just to try and keep vars with the functions they relate to, to try and keep things a bit more modular. Maybe not a good idea though.

The weird characters may have come from the original HLSL/Cg. I've had weirdness copy-pasting code from webpages in the past, so that also could be an issue with the other shader that was giving the same error.

a|x