thanks for your time, tanya and andy…
After reading your comments on that issue, and also looking at the COLLADAFX output of FeelingSoftware’s Maya-Plugin and NVIDIA’s FXC2 Alpha, I concluded the following:
the <newparam> array defines some kind of an interface to shader variables (whatever scope), that exist in the runtime. It’s possible to have
1.) newparam’s defined which might not occur in the referenced code
as well as
2.) variables defined in the shader-code that are not exposed via the newparam array.
If you want the user of the effects to manipulate certain parameters, then you definitely should expose them via newparam.
For case 1.) the Cg API offers the cgCreateEffectParameter, in GLSL however it’s not possible to create parameters “on the fly” (except maybe generating source-code, and additionally linking it with the current program)
As GLSL has no effect-type, my converter is creating for each referenced-source/entry_name - pair it’s own <include>/<code> - element Fortunately the Cg-compiler picks out all necessary variables of the Cg/CGFX-file for compilation. So case 2.) won’t ever get any problem.
However, for Case 1.) I would have to create the Effect-Parameter, before compiling into GLSL, so we have that required reference in the GLSL-code. Until now, I just use normal Cg-programs which are built from any referenced Cg-source code and get built into GLSL afterwards. - note the referenced code could also be a CGFX file, it generates no error, the CGFX-stuff like techniques, etc… is simply ignored - in the end it’s the same compiler) But for correctly handling Case 1, I need to create a CGEffect, and not just a CGProgram, for being able to use the cgCreateEffectParameter to create the missing parameter reference.
I understand that the first COLLADAFX was written to be used next to the CGFX-runtime. That actually creates some way of redundancy in the effect definition, because the definition of an effect shouldn’t be a matter of the runtime itself anymore, but rather of the COLLADAFX.
Now I was just browsing through the output of NVIDIA’s FXC 2 Alpha and when converting to COLLADAFX-format they strip all of their CGFX-stuff in the source-reference before…resulting in clean Cg-Code. I hope I don’t break any NDA-agreements by posting this
The output of the COLLADAMAYA-plugin is directly referencing a cgfx file, but that reference is more or less just a container of source-code. The Vertex and Fragment Shader used in COLLADAFX are just referenced with the correct entry-function to this Cg-“container”
Both Apps expose all of their shader variables via the newparam-array, and bind them via the <bind>-array for each shader.
I think that’s the least confusing way of using COLLADAFX. You use the <bind>-array for each shader as the only connecting interface between the variables in you shader-src/runtime and the variable in your COLLADAFX-“runtime”. That’s the way I thought you should use COLLADAFX in first place…
So for now I implement the converter expecting the COLLADAFX to be used like COLLADAMAYA and FXC2 does. But I will additionally check for any “unbalances” between the setparam, newparam and the shader variables…
I’m really looking forward to the next FXC2-release, as this is by far the most complex app using COLLADAFX. When more people outside the walls of the big game companies start using COLLADAFX, things will get really interesting, and I guess with more mature COLLADAFX-examples, we will see how you conveniently expose your shaders via COLLADAFX…