[GEM-dev] [glsl_program] getVariables() prob

[zmoelnig at iem.at]

Quoting james tittle <tigital at mac.com>:
>
> ...yeh, I fixed that in my previous commit (ie. from "<=" to "<"),  
> but I guess my over-free()-ing was a problem:  typical problem of  
> changing too many things at the same time?

i am not sure. a diff between the 2 last versions did not show up the 
change i made (though i noticed that you did change one "<=" to "<") - 
probably there were 2 of them...

>
>> i did a lot of other changes which shouldn't affect the behaviour.
>> now it works for me (i just committed it)
>
> ...my modem access atm doesn't allow me to get thru to cvs.sf.net  
> (?), but I looked at your diff and see a variable m_wantLink(0) which 
>  I don't have:  are we in sync on this file?

well, i moved the actual LinkProgram() to be called from within 
render() and not directly from the linkMess(). the linkMess() just 
tells the [glsl_program], that at the next render cycle the objects 
should be linked.
probably this does not matter, however i wanted to be sure, that we 
have a valid GL-context; the only moment we can be sure that there is a 
valid GL-context is during one of the render()-function calls (this 
includes postrender(), startRender() and so on)

>
> ...also, good call on dropping m_name[]:  I didn't realize we were  
> actually comparing paramMess()'s to m_symname[]!
>
>> one last question:
>> when loading the "Toon"-shader (dunno who sent it, i guess jamie),  i get
>> active uniform variables like "gl_ModelViewProjectionMatrix" (apart  from
>> the valid "Phong"); i have no idea where this comes from; anyone...?
>
> ...aha, at least something I can answer ;-)  On the one hand, the  
> toon shader in cvs is an arb_program, not glsl...but you could do it

oh, i am not using the toon.vp and toon.fp shaders (which are ARB), but 
some others, which i am quite sure that they are GLSL.
probably i found them somewhere "at the internet".

> easily in glsl, and it would likely have  
> "gl_ModelViewProjectionMatrix" as an active uniform:  this is usually

are there implicit active uniforms (which i don't have to declare as such) ?


>  set up in the vertex shader and passed into the fragment  
> shader...there are actually a whole host of built-in active uniform  
> variables that have to do with different parts of gl's pipeline:   
> check out the spec, the new red book covering 2.0, or the orange book 
>  for more info...I don't think these are designed to be manipulated 
> by  the user, but they could be...
>

yes, i really have to get the orange book (and open my copy of the red 
book once in a while ;-))


mfg,.adsr.
IOhannes


PS: ben, the patch is really the one, jamie sent some weeks ago on this list.
however, i can send it tomorrow.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 1718 bytes
Desc: PGP Public Key
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060228/272b5db6/attachment.key>