Why not - if the operation is well-defined? It is even another case if implementing such a function - just read on.


No, no, no. You don't understand me. That would save me work!


Maybe,...

This comes back to the initial issue: One can write a simple pre-processor that takes a source-file, seaches for include-statements and generates a shader by using multiple source-buffers when...

Take a look here http://www.cl.cam.ac.uk/~cs448/git/trunk/src/docs/glfbdev-driver.html
or just Google for framebuffer and mesa.

The lack of a specific sense of humor aside, a compelling use-case is hard to find. It is not that lists could not be kept by the application. It is not that the gl could not be defined to make them...

That mainly cites the state as it is - but why should that be that way? There must be a reasoning behind the decision NOT to expose that information. That information has to be present in the library...

Though one of course knows what was loaded, the information gets copied into the gl no matter what. Why should that information not be made accessible? If writing a module concerned with shader stuff...

On a second thought the extension should also introduce SHADER_SOURCE as type to make a distinction easier if the named string is actually to be compiled. That would make list-keeping of...

I must say I was not aware of that extension.
What seems missing though is the possibility to enumerate the named strings, so that an application does not have to keep it's own list of sources that...

Right - and when source-buffers can be named that way, maybe there is a way to keep them in memory by user request.
That would be a way to realize #include-statements despite of the fact that there...

glsl should provide for means to Name source buffers either inside a given source or provide another mechanism to Name source-buffers, so that source-names can be shown in shader-info-logs instead of...

Which is a good Thing as using the old crap makes learning OpenGL quite a lot easier. And as you say the principles stay roughly the same. For my taste the compatibility spec goes not far enough to...

The statement "are gone" is somewhat misleading. The learning/optimization curve of OpenGL is not to be cut any soon. I prefer things to be quickly codeable first and quickly to execute later on.

...

You need to formulate the plane-equatation for the plane.
This can be done using
ab=B-A
ac=C-A
Which leads to the plane equotation
P= a + S*ab + T*ac, for S and T in R
...

That is it - it would make things slower if one did not care instead of impossible. That's what I want.

I do not understand what you mean with 'height on the triangle'. Do you mean the distance of the point projected onto the triangle from the nearest edge or do you mean the distance to the plane the...

Or, to put it another way, what is the compelling use case for this feature besides "I want to do it?"
I had to look this up. Of course there is none. I'm a user of OpenGL - not am implementor, But...

The point is a use case where the performance-hit due to a readback would be neglicable. That is where the ease of use and genericity would have priority. For example if initializing all...

You take my wording. Legacy-OpenGL will surely not go away. It is too easy to reformulate the functionality using the core-profile functions. The work-shift for doing so towards the implementors of...

As I understand the spec blockBindings say:Get the data from that buffer if needed. So - if a block-binding gets established after the first code-fragment, it can be checked if the block contains...

I would be pretty sure about that as OpenGL is the de-facto standard on pretty much every platform except ms-windows when it comes to writing 3d-apps.That is the useage-profile of opengl is far...

! ........

I do not think I've missed the Point. I just don't care about implementation-issues that come up when making decisions about how I think the spec should look like.
All that ever again is come up...

I still do not get the Point. There is a finite set of API-commands that Change the data inside a uniform-block. There is a finite set of commands that change buffer-data. One could easily prevent...

And why aren't those tracked for compatibility?

I do not get the Point.
void glBufferData(...) {
if(bufferBlockBinding()) {
if(opaquesInBlock()) setupStuff();
}
copyToGPU(bufferdata);
}
The gl-implementation certainly keeps track...