Color Input For Multiple Attached Fragment Shaders - OpenGL 1.2

I want to attached a second fragment shader to an OpenGL 1.2 shader program that gets its input from a fragment shader that writes to glFragColor. This is all implemented on FBO's with render-to-texture.

What is the correct syntax to access the RGBA pixel colors from the output of the first shader? The only variables I see in the orange book are glFrontColor and glBackColor, which I assume are for screen rendering, and not FBO rendering.prog

FYI- My first fragment shader accesses a 16 bit float texture from a film scan, so I don't want to lose the color precision.

Don't think of it as "attaching a second fragment shader to an OpenGL 1.2 shader program that gets its input from a fragment shader that writes to glFragColor." That's only confusing yourself. Think of it as exactly what it is:

1: render color values to a texture.
2: make a second rendering using that texture as source input.

Step 2 is no different from any other shader that accesses a texture. Therefore, the precision of Step 2 is based entirely on the precision of the texture.

If you need 16-bit floating-point precision for inputs to step 2, the step 1 needs to write to a 16-bit floating-point texture (which step 2 will read).

Alfonse:

Thanks for your advice. I thought I replied to your message last night, but I don't see the post. I guess I must have dreamed it.

I'd rather not create an extra drawing procedure unless necessary. I'm already taking too long to process film scans at 24fps. I've been Googling multiple shader attachments and it seems that it's done with attaching multiple code fragments that are assembled as one shader with a single main() and output. Is that correct?

Is it possible to declare uniform variables inside the main() body of a fragment shader? I've always declared them in the global variable space before main() executes. But if I can declare the uniforms that are accessed in each code fragment, I can split up some very long and complicated fragment shaders into fragment shader code sections. I could create a vec4 variable that holds the current color ouput, and just keep operating on it on each fragment.

What do you think?

Quote:

---

that it's done with attaching multiple code fragments that are assembled as one shader with a single main() and output.

---

Now we're talking about something else. Now you're talking about one fragment program with a single path of execution that comes from two shader objects. There's no FBO, no render-to-texture. It's all within a single program object.

It doesn't work the way you think. If you link two shader objects together, you get a single program. But only one of them can have `main`. The system doesn't merge their `main` functions.

The only reason to link multiple shader objects in the same stage together like this is for doing library stuff. That is, one of them defines one or more functions that are used by the other one. You can't use it to daisy-chain shaders. Well, not automatically; you can have one shader object's main function call a shader object's function, passing it whatever value it would have written. But that's up to you.

Dang this is confusing.

If you can only have one shader with a main function, how does the other shader compile successfully?

What would happen if I put the first half of a complete fragment shader text into one shader object, and the second half into another shader object. Would they conpile and assemble correctly into a program?

Does the shader compiler look for a complete main function, or does it just compile any code with legal syntax, like a c++ compiler would. Please don't ask me why I want to do this, becasue I don't have a good answer.

Quote:

---

If you can only have one shader with a main function, how does the other shader compile successfully?

---

The same way source files in C and C++ compile without having `main` in them. Shader objects are like object files in C/C++; you can't use them until you link them into a program.

You should read up on this on the wiki.

That was good reading. I think I'll work up somecode and post it to see what you think.

But first, can you please tell me if it is permissable to declare uniform variables inside the Main() procedure body?

Thanks.

Quote:

---

But first, can you please tell me if it is permissable to declare uniform variables inside the Main() procedure body?

---

What would it matter if you could? They're still set by the outside world. They're still queryable by the outside world. They still can't have in-shader values initialized to them outside of link-time initialization. They still can't be changed by the shader program (ie: they must be uniform). In short, if you could, you wouldn't *gain* anything by being able to do so.

Which is one of the reasons why you can't.

I feel like I'm in one of my therapy session from the 1990's, except for the $75/hour outlay. So you're saying that I can put the uniform variables inside the partial fragment shaders, but I can't set their values from the outside world (i.e. from the host application). So what the hell is the point of having mutiple shader attachments????? AAAAArrrrghhh!!!!!!!

Quote:

---

So you're saying that I can put the uniform variables inside the partial fragment shaders, but I can't set their values from the outside world (i.e. from the host application). So what the hell is the point of having mutiple shader attachments?????

---

No. I was talking about uniform variables in functions, which is what you asked about.

There is a difference between "functions" and "shader objects." Shader objects may many functions, or they may have none. Functions have to go inside shader objects, but that has no bearing on what other things (like input definitions, uniform definitions, structs, etc) may also go inside shader objects.

The "Main() procedure body" is a function, not a shader object. Therefore, you asked if you can put uniforms in a function. Which you can't, and it wouldn't make sense if you could.

You're really confusing yourself with the whole multiple shader objects thing. Here's a hint: don't use it. Put all of your vertex shader code in one shader object, put all your fragment shader code in another, and link them together. This is how it is done 99% of the time.

That's not to say that it isn't useful. Sometimes. On occasion. During a solar and lunar eclipse. Possibly. But regardless, you're obviously perplexed by it, so there's not much point in trying to take advantage of it.

Also, I never said uniforms couldn't be changed from the "outside world (i.e. from the host application)". Indeed, I specifically said that they could, in my second sentence: "They're still set by the outside world."