by the way, there is an amazing code to calculate raytraced quaternion julia sets on the GPU. you need a PS 3.0 card (nvidia 6200 or higher) to get it to run.
i rendered this video in only 2 hours on a nvidia 6800 card: http://vvvv.meso.net/tiki-index.php?page=TonfilmsPatches
a nice detail: http://vvvv.meso.net/tiki-browse_image.php?imageId=1511
and from somebody else a pic: http://vvvv.meso.net/tiki-browse_image.php?imageId=1509
the code can be found here: http://graphics.cs.uiuc.edu/svn/kcrane/web/project_qjulia.html
keep on codin'
tebjan
...picking up this thread again:
...I've now got [glsl_vertex] & [glsl_fragment] working (ie. loading and compiling), but am temporarily stuck at how to pass on the GLhandleARB (which is actually a void*) to [glsl_program]? In [pix_multitexture] I just used outlets with casts to t_float for the texture ID's, but I'm not sure how we should just pass a pointer to an opaque driver object (guess I need to re-consult IO's "how to write and external")...? Should it be auto-paired with a message, like [vertex GLhandleARB< ? This then would trigger an auto- registration of compiled shader objects in a kind of hash table, which would then be linked if something changed...then if linking goes ok, it would auto-discover the active Attrib and Uniform variables, and output a list of them to console (to remind the user/ programmer), but also set up named/numerical messages to accept...
...I figured this method would work better than trying to add some kind of stuff to GemState, because we'd be true to glsl's flexibility in linking...
...how's this sound?
james
james tittle wrote:
...picking up this thread again:
...I've now got [glsl_vertex] & [glsl_fragment] working (ie. loading and compiling), but am temporarily stuck at how to pass on the GLhandleARB (which is actually a void*) to [glsl_program]? In
hmm. looking in my glext.h and glew.h it says: typedef unsigned int GLhandleARB; /* shader object handle */
which would be very simple to handle (just like in [pix_multitexture]).
[pix_multitexture] I just used outlets with casts to t_float for the texture ID's, but I'm not sure how we should just pass a pointer to an opaque driver object (guess I need to re-consult IO's "how to write and external")...? Should it be auto-paired with a message, like [vertex GLhandleARB< ? This then would trigger an auto- registration of compiled shader objects in a kind of hash table, which would then be linked if something changed...then if linking goes ok, it would auto-discover the active Attrib and Uniform variables, and output a list of them to console (to remind the user/ programmer), but also set up named/numerical messages to accept...
yes, that sounds ok..
as for linking of the shaders (just an idea): how about sending 2 lists [vertexProg <v1> <v2> ...( and [fragmentProg <f1> ...( to the [glsl_program]; in the next render-cycle, the so changed program would automagically get recompiled and used (until someone sends other fragment/vertex-modules to the object)
if GLhandleARB is really a pointer, we could also abuse the "gpointer"-type (like the GemState-passing); however if the types are different on the platforms (which i doubt), a registration mechanism that can be called with symbolic id's would really be better.
...I figured this method would work better than trying to add some kind of stuff to GemState, because we'd be true to glsl's flexibility in linking...
yes, i agree that it would be better to _not_ add these programs to the GemState (it's already crowded, and it is hard to exchange data between gemchains)
mfg.asdr. IOhannes
On Nov 22, 2005, at 5:12 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
...picking up this thread again: ...I've now got [glsl_vertex] & [glsl_fragment] working (ie. loading and compiling), but am temporarily stuck at how to pass on the GLhandleARB (which is actually a void*) to [glsl_program]? In
hmm. looking in my glext.h and glew.h it says: typedef unsigned int GLhandleARB; /* shader object handle */
which would be very simple to handle (just like in [pix_multitexture]).
...grrr...well, this platform gl discrepancy is a first for me! But, it seems to work if I do:
outlet_float(m_outShaderID, (t_float)(unsigned int)m_shader);
...so we'll go with that until something breaks ;-)
as for linking of the shaders (just an idea): how about sending 2 lists [vertexProg <v1> <v2> ...( and [fragmentProg <f1> ...( to the [glsl_program]; in the next render- cycle, the so changed program would automagically get recompiled and used (until someone sends other fragment/vertex-modules to the object)
...yeh, that's kind of what I was thinking, tho I was thinking of using a [link< to indicate that it needs re-linking, because I assume that creating/destroying a compiled shader object will just recycle the same ID/GLhandleARB, and that'd be hard to detect if one changed...
...so, I'm not really familiar with dismantling a list programmatically, so can you point me to some example code? I bet it's easy, and even tells ya how long the list is n'stuff ;-) Even better, we don't need to have seperate vertex/fragment inputs to the linker, since they'll already be compiled; all glsl_program will need to do is attach them to a program object, then link that object...so, I guess the message would better be [shader $1 ... $n<
...maybe I can get this going today?!?
james
james tittle wrote:
hmm. looking in my glext.h and glew.h it says: typedef unsigned int GLhandleARB; /* shader object handle */
which would be very simple to handle (just like in [pix_multitexture]).
...grrr...well, this platform gl discrepancy is a first for me! But,
actually i don't think that this should ever happen. after all openGL is cross-platform per se.
it seems to work if I do:
outlet_float(m_outShaderID, (t_float)(unsigned int)m_shader);
...so we'll go with that until something breaks ;-)
;-)
as for linking of the shaders (just an idea): how about sending 2 lists [vertexProg <v1> <v2> ...( and [fragmentProg <f1> ...( to the [glsl_program]; in the next render- cycle, the so changed program would automagically get recompiled and used (until someone sends other fragment/vertex-modules to the object)
...yeh, that's kind of what I was thinking, tho I was thinking of using a [link< to indicate that it needs re-linking, because I assume that creating/destroying a compiled shader object will just recycle the same ID/GLhandleARB, and that'd be hard to detect if one changed...
i thought it more simpler: whenever the [glsl_program] receives a list of modules, it will recompile (but only in the next render-cycle, in order to be able to get a "full" program into it, before attempting to compile)
...so, I'm not really familiar with dismantling a list programmatically, so can you point me to some example code? I bet it's easy, and even tells ya how long the list is n'stuff ;-) Even better,
yes of course: a method for elements of type A_GIMME calls a function like glsl_program::vertexPrograms(t_symbol*, int argc, t_atom* argv); you can savely ignore the "t_symbol*" (it is just "vert_program" or whatever the method was); argv points to an array of #argc atoms; and you get the numbers out of each atom by atom_getint()
we don't need to have seperate vertex/fragment inputs to the linker, since they'll already be compiled; all glsl_program will need to do is
oh, i thought that fragment and vertex-shaders are linked differently into the program; but now i see that both just call glAttachObjectARB()...
attach them to a program object, then link that object...so, I guess the message would better be [shader $1 ... $n<
so that is fine!
...maybe I can get this going today?!?
probably (but i'll have to go to a concert right now)
mfg.asdr. IOhannes
-
IOhannes m zmoelnig -
james tittle -
Tebjan Halm