Frag / GLSL newbie questions

[Patryk Kizny]

I am trying to integrate imported camera movements into frag.
I am using array-structured data accessed via time variable. Seems easy.
Now I have a few newbie questions as I don't have any deeper GLSLS knowledge.

- I found that things which sit in #vertex section are somewhat isolated - i.e. If any variables are defined elsewhere I can't seem to be able to access it.  So it looks like there's a #vertex part and everything else. Can one let me know something more about it?

- Also it looks like I am unable to use #ifdef inside of #vertex. Can one explain?

- I'd like to understand more in what order the code executed and what are best places to put statements that I want to be executed on entering a new frame (that's what I need for camera and some other things). Is there any documentation for what is the order

→ when exactly are init() parts executed?
→ how often and when are main() executed?
→ when are unbound statements executed? I mean bits of code which are not sitting within any functions body? Like declaring a variable and assigning it a value.

How much of it is general GLSL and which are the parts that are specific to fragmentarium?

Finally, when I messed a bit with within the #vertex part in 3D.frag I am getting warnings that I have used too many temp constants and it may negatively affect performance.

If any of it is general GLSL that I can google for, please save your time and don't elaborate.

Thank you for your help.

[cKleinhuis]

So, for once, just google glsl tutorial and use the lighthouse3d tutorial

some hints:

vertex shader code is executed before pixel shader, there is some kind of mahic going on, because the vertex shader is just executed for every vertex, w.g. the four sides of a quad, everything that is returned is then beeing interpolated, e.g. the texture coordinates are different for every pixel

The main() function is the entry point for both, pixel and vertex

code is not executed, but calculated everything outside of functions is global and evaluated before the code is executed

uniform variables - if defined in both shaders -are accessible in not, uniforms are outside inputs to a shader

a varying variable can be used to communicate between vertex pixel shader

glsl has basic directives like define and ifdef

the include statement is provided by fragmentarium

[Patryk Kizny]

In general if I need to do a lot of calculations that I need to feed later to Vertex shader, how should I approach it?
Can I call functions outside of #vertex from inside? What would be a recommended workflow?
I already have a bit of overkill on the vertex side so wanted to optimize it as much as possible.

[Syntopia]

It is a good question - this has been discussed before, and I don't think there is an easy way. I'm actually surprised you could even store all the camera data in the vertex shader source. You could of course do calculations on the C++ side (or from the Qt JavaScript interface), and send them to shader using uniforms (or uniform buffers), but that is tedious, since you will miss the nice matrix/vector syntax in GLSL.

[Patryk Kizny]

Yeah, ideally would be on a C++ side, but I never coded in C++ and it would take me ages to learn it and learn how frag is written.
Ideally you'd load a text file into interface to grab the camera from it.

So probably I'll stick to #vertex consts (which DO NOT compile on some machines as reported above) or switch to JS.

[3dickulus]

all variables that get created in the fragment source that are also in the variable editor GUI like sliders etc. are available for reading and writing in Fragmentarium Qt Script a.k.a. "fqs", a hybrid of Qt + javascript + app functions