[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