[GEM-dev] Re: GEM shader usage

IOhannes m zmoelnig zmoelnig at iem.at
Tue Oct 18 18:48:03 CEST 2005


james tittle wrote:
> 
> ...so, I think this means we should just have one [shader_program]  that 
> can accept one or two names as arguments (vertex shader followed  by 
> fragment?), but we would then need some mechanism to determine  which 
> one is the vertex or fragment shader...so, I've been just going  ahead 
> with making it a message based object, such that you send a  [vertex 
> nameOfVertexShader< and/or [fragment nameOfFragShader< to the  
> [shader_program]...then the shader_program will try to link together  
> whatever it has, report what happens, and go on from there...

but does this mean that we can only have 1 fragment-object and 1 
vertex-object, while GLSL would support multiples of both (the only 
restriction ist that there must be one and only one main() routing in 
both fragment and vertex sets)

so i was thinking of having 3 objects: vertex- and fragment-shader 
loaders ("compilers") and a linker-object.

does this make the patches unnaturally bloated ?

it would look like

|
[GLSL_vertex vertex_main.glsl]
|
[GLSL_vertex vertex_sub1.glsl]
|
[GLSL_fragment fragment_main.glsl]
|
[GLSL]
|

(the object-names just came to my mind while typing, so i don't care 
about them)

and both [GLSL_vertex] and [GLSL_fragment] would have one additional 
inlet/outlet so you could share shader-objects.


otoh, i am not sure what's the fuzz about all those different compiled 
shader-objects.
one thing is that you can keep your (shading) code cleaner and re-use it 
(as a programmer i mean); so it wouldn't be _that_ bad, if you had to 
copy everything to one file before loading it into [shader_program].
the more serious question is, whether you can use more distinct complex 
shaders, if they share modules(==shader objects).
so if 2 shaders share 50% of the code and loading both totally 
separately would exceed the maximum number of instructions, you might be 
able to load both with the share objects (only 75% (compared to the 
other option) has to be loaded)
is this assumption correct ?
should it bother us ?


mf.adsr.
IOhannes




> 
> ...how's this sound?
> 
> jamie
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev





More information about the GEM-dev mailing list