[GEM-dev] Re: GEM shader usage

[IOhannes m zmoelnig]

james tittle wrote:

> ...this sounds fine, but could also just be done with one object that  
> can be created with multiple names, like you did with  fragment_program 
> inheriting from vertex_program:  the only difference  in vertex/fragment 
> shader object creation is what is passed to  glCreateShaderObject():  
> GL_VERTEX_SHADER or  GL_FRAGMENT_SHADER...chris had actually suggest the 

yes, i just think that from a pd-patcher's side of view, it is easier if 
we have 2 distinct objects. (on the C++ die of things they really are 
the same object with a different "skin")

> 
> ...then I agree we should have a GLSL_link/bind/program that would be  
> like the soon-to-be-CVSed pix_multitexture, in that it'll accept  shader 
> object ID's...the thing here is that I haven't seen examples  where more 
> than one of each shader is bound together in one program  (not to say 
> that "I've seen it all")...I have seen header files for  shaders that 
> include common lists of uniform variables, so I guess  these would have 
> to be included somewhere along the line...

i thought the "#include" directive is not supported by GLSL. (but my 
brains might have gone astray)
but since the linking multiple shader-objects is such a prominent 
feature in the documentation, it really would be a shame if we would 
just ignore that.

>> should it bother us ?
> 
> 
> ...yeh, I think it's good to stop and try to get it correct the first  
> time, which is why I didn't just do a similar set of object like the  
> ARB stuff...

yes, i also started to just add GLSL-support to the ARB-shader-objects 
and noticed that it is kind of different...

> 
> ...one thing that I REALLY want to add to this (and possibly the ARB  
> program objects) is a way to edit the programs without using an  
> external editor, and this'll be pretty easy to do with the tcl text  
> widget, I'd imagine...then we have a really cool system for playing  
> with GPU programming!

well, that would be rather simple.
we just add a method to give the program-string (ye, we should really 
try to get a string-type into pd!!), like [program "!!ARBvp1.0..."( 
instead of the normal [open shader.vp(

and once there is a string type in pd, pd would of course also need a 
string-editor; so it is not a problem directly related to Gem (but 
nevertheless a cool feature)

> 
> jamie
> 
> ps:  do your current gl drivers include support for pixel buffer  
> objects and framebuffer objects?  If so, I had a crazy idea for  
> multiple_windows where we could just render things to framebuffer  
> objects and then use those for our different windows...

glewinfo gives me:

glBindFramebufferEXT:        OK
GL_EXT_framebuffer_object:   MISSING [OK]
GL_ARB_pixel_buffer_object:  MISSING
GL_EXT_pixel_buffer_object:  OK


if have no idea what the "MISSING [OK]" means.


mfg.afd- da
IOhannes