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@iem.at http://lists.puredata.info/listinfo/gem-dev