I thought this might be worthy of its own thread:
http://www.khronos.org/developers/library/gdc_2007/News//Introducing-glFX.pdf
This is very exciting news.
Is there a preliminary effect grammar available for viewing? I see that a draft is slated for discussion at SIGGRAPH '07, so it could be that we have to wait till then…
Cheers
I’m pretty much “eh” about it.
Sure, on the one hand, it’s something that tons of people have been wanting basically forever.
On the other hand, I haven’t. It’s something that I would pretty much never use. The way I look at shaders and rendering is pretty strongly opposed to any FX-style functionality. And my blind, unreasoning hatred of anything multipass makes the general FX ideal of automated multipass unacceptable.
And that’s not to say that I don’t understand why its there or I don’t think it should be. It’s just that it does nothing for me personally.
I see that a draft is slated for discussion at SIGGRAPH '07, so it could be that we have to wait till then…
Isn’t the grammar simply Collada FX, which already exists? It seems to me that the actual glFX is simply the library that uses ColladaFX and appropriate GL objects for meshes and textures to render the scene.
The API itself will have to wait for Longs Peak; I seriously doubt they’d bother to make a 2.1 compatible API, especially since the LP API, with it’s Vertex Array Object, seems especially suited to its needs.
I’d much rather have full control over how any multipass stuff gets set up… Especially where there are effects that can be 4+ passes, being able to manually tweak those is great. When it comes to a high-performance graphics pipeline, having a black-box Fx engine right smack in the middle seems… counter-intuitive.
I feel the same. I write my shaders as classes that load source code from text files, implement bind/draw methods etc. During an update traversal concrete shaders are assembled from these shader ‘fragments’. That way I have full control over what happens, and the power of C/C++ to do anything I want. If I want to be able to dynamically add new shaders without re-compiling the source I simply write an object factory DLL and drop it in to the bin directory.
So this whole fx file system is just alien and fundamentally useless for me.
I can only imagine it being useful for previewing some particular shader effect in Max or something - but even then, I can’t imagine I’d ever be bothered to build the fx file just for my artist to see how it might look in his Max viewport. He could just export the model and material file directly into my preview renderer.
Originally posted by Korval:
The API itself will have to wait for Longs Peak; I seriously doubt they’d bother to make a 2.1 compatible API
They’re focusing on OpenGL ES first, to support getting content from DCC tools into mobile platforms. Stuff done for OpenGL ES will be usable with OpenGL 2.1 with minor tweaks, and the ARB will make sure we represent desktop OpenGL interests to the glFX working group discussions…
That isn’t to say that some things couldn’t be done more efficiently in Longs Peak, particularly things involving state changes, but it isn’t the low-hanging fruit.
Originally posted by Korval:
Isn’t the grammar simply Collada FX, which already exists?
Yes, I think you’re right. I’m not very familiar with Collada, but it does clearly have an FX grammar component already in place. The bit that threw me a little was the bullet point “Will be fully compatible with the Collada FX data model”, which suggested to me that there might be some differences.
So in sum it appears that glFX simply provides the framework that brings all the constituent pieces together: the (existing) Collada FX grammar, and an API designed to simplify FX creation and provide control over the runtime environment (while seamlessly targeting both OpenGL and ES).
BTW, can we expect to see glFX progress updates in the pipeline newsletter, for example? Or should this be considered more of a “Collada thing”. I’m wondering where exactly glFX fits into the OpenGL scheme of things.
For anyone else interested, here’s the latest Collada (FX) specification:
http://www.khronos.org/files/collada_spec_1_4.pdf
Cheers
Originally posted by Flavious:
BTW, can we expect to see glFX progress updates in the pipeline newsletter, for example? Or should this be considered more of a “Collada thing”. I’m wondering where exactly glFX fits into the OpenGL scheme of things.
It is a “glFX thing” - it has its own, independent Khronos Working Group. People from the COLLADA, OpenGL ES, and OpenGL ARB Working Groups are all involved in the glFX WG, since all of them are critical elements.
Edit to add: Khronos will be doing either a bigger newsletter of which Pipeline is a part, or multiple newsletters for different WGs, in the future. So there will be progress reports one way or another.
“glFX thing” it is, then 
Thank you for the clarification.
FWIW, I really like the idea of multiple newsletters for the different WGs.
Cheers