profile_GLSL

[m-7761]

Let me try again. Browser prematurely submitted this post while editing the subject :(

[m-7761]

I've been worrying about this. And I guess there's no answer. In this example below, the "varying" variables are not referenced by the document at all.

https://www.khronos.org/collada/wiki/GLSL_Example_Effect_(COLLADA_1.4.1)

I guess that means that all GLSL varying (in/out) variables must be named as if they are a "semantic". For example, there's no way to know what ViewDirection and LightDirection are, never mind that these don't really use the scene graph. (The example doesn't require a model-view matrix. Not in the normal way.) And so "Texcoord" we can assume uses the TEXCOORD semantic. I don't like this.

There is a disconnect between the Cg and GLSL profiles because GLSL effects must be written with semantics built into their variable names. There's no binding to these variables in <shader> and even if binding inside of <instance_material> is feasible--which is yet to be seen--it's a lot of fuss to go to to instance a material.

[m-7761]

It occurred to me that the "ViewDirection" is a "varying" parameter and so might not have a <newparam> to initialize it.

But I remembered <modifier> and now I wonder if the "varying" parameters should be included among the <newparam> parameters, and if they are flagged with <modifier>VARYING</modifier> or just if they can be located with glGetAttribLocation as a fallback, but I cannot see a way to do it without having a name to go by.

Even with glGetActiveAttrib it does not get a semantic. And it's strange because this is shader specific, but <newparam> is at the effect or technique level. (Or profile in 1.5.0.)

Strikeout: see new comment.

[m-7761]

I was only recently relearning GLSL when I made the last comment. I was confused about various things. Because 1) I didn't realize the old "attribute" qualifier existed, and 2) The code in the link describes what must be the fragment shader as the "vertex shader" or that is its name/id.

<code sid="Vertex_Program_E0_P0_VP"> uniform vec4 fvSpecular; uniform vec4 fvDiffuse; uniform float fSpecularPower; uniform sampler2D baseMap; uniform sampler2D bumpMap; varying vec2 Texcoord; varying vec3 ViewDirection; varying vec3 LightDirection; void main( void ) { vec3 fvLightDirection = normalize( LightDirection ); vec3 fvNormal = normalize( ( texture2D( bumpMap, Texcoord ).xyz * 2.0 ) - 1.0 ); float fNDotL = dot( fvNormal, fvLightDirection ); vec3 fvReflection = normalize( ( ( 2.0 * fvNormal ) * fNDotL ) - fvLightDirection ); vec3 fvViewDirection = normalize( ViewDirection ); float fRDotV = max( 0.0, dot( fvReflection, fvViewDirection ) ); vec4 fvBaseColor = texture2D( baseMap, Texcoord ); vec4 fvTotalAmbient = fvAmbient * fvBaseColor; vec4 fvTotalDiffuse = fvDiffuse * fNDotL * fvBaseColor; vec4 fvTotalSpecular = fvSpecular * ( pow( fRDotV, fSpecularPower ) ); gl_FragColor = ( fvTotalAmbient + fvTotalDiffuse + fvTotalSpecular ); } </code>

I had also forgotten about gl_Normal and gl_MultiTexCoord0 and friends, which may not have been deprecated in COLLADA's early days. They would've made an easy case for not describing vertex program inputs in the document. <modifier> doesn't have anything for IN or ATTRIBUTE. It's a quirk that Cg provides an API for querying these I think, that should not have been relied on I think. Semantics are precisely the things that the technology is free of; that documents must communicate.

It seems as if the only sane way to use GLSL is to insist on the deprecated glNormal and friends, or their equivalents by way of dropping the "gl" parts.