[GEM-dev] automated drawing in gem?

[marius schebella]

I don't know if it it works out of the box??? I just saw how this is 
done with jit.gl.lua. I am in a class with all Max users... but I don't 
care, do all my assignments in Pd. and I learn a lot!
I do the vertex and fragment shader with the [glsl_vertex], 
[glsl_fragment], [glsl_program] and the rest with the GEMgl... objects. 
almost all gl commants exist as a GEM object. I also figured out how to 
do textures (finally), even multiple. still, scripting would be really 
good to have.
marius.


Alexandre Quessy wrote:
> Hi,
> I think such a scripting possibility is a must.
> 
> Shaders are very - very- nice. They can allow you to modify the
> vertices (vertex shader) and textures (fragment shader) you send it.
> Furthermore, you can make it compute stuff, such as even physical
> simulation, on the GPU. What we need is an extendable way to create
> those vertices, and to choose the texture we put on it. By etendable,
> I mean that using a lot of [coll], [list] or so, and then [unpack]ing
> them is not so scalable. When you have something like 15 parameters on
> a sprite (a geo with a texture on it), you need something like a
> scripting language to keep track of the states, variables, changes,
> and such.
> 
> Now, if we call the void gl_lua::render(GemState *state) method of a
> gl_lua Gem object, and then call a lua function that draws vertices
> with a texture id (according to the GemState object attributes we pass
> it, I guess), would the result be drawn in the Gem window ?
> 
> I mean using the http://luagl.wikidot.com/ functions. I wonder if
> calling those :
> """
> gl.Begin("LINES")
> gl.Color(1, 1, 0)
> gl.Vertex(0, 0)
> gl.Vertex(1, 1)
> gl.End()
> """"
> ... would work out-of-the-box. Would it ?
> If so, that worth it. :)
> 
> a
> 
> 
> 2007/9/16, marius schebella <marius.schebella at gmail.com>:
>> alexandre,
>> at exactly this minute I was looking at exactly the same stuff, you just
>> posted...
>> a jit.gl.lua for gem (gl) would be cool. or python, but some scripting
>> for gl would be cool. I still did not look into the shader language,
>> maybe I will do this now...
>> marius.
>>
>> Alexandre Quessy wrote:
>>> Hi!
>>> Otherwise, use pix_set, or so. Of course, there could be some kind of
>>> QuickDraw-like (tm Apple computer) commands in an object, or an object
>>> to which we can send OpenGL-like commands, such as Jitter's
>>> http://www.cycling74.com/documentation/jit.gl.sketch ... I might be
>>> interested on making one some day. We will see if I get some free
>>> time... :)
>>>
>>> Actually, I am more interested in a Lua wrapper, from which we could
>>> use the OpenGL functions which would be rendered in the same render
>>> context than Gem's. Would it be easy? ClaudiusMaximus has started a
>>> wrapper for Lua, and I wonder if that would be easy to do. Wesley
>>> Smith has done the jit.gl.lua external ( see
>>> http://www.cycling74.com/twiki/bin/view/Share/WesleySmith ) which
>>> extends really well Jitter. It is not free (neither is Jitter), but it
>>> is a proof that adding some script language to a dataflow software
>>> makes things way easier when trying to make complex animations !!
>>> Calling OpenGL functions in text is nice, you know ! Way faster than
>>> using pd messages.
>>>
>>> See : http://luagl.wikidot.com/
>>>
>>> a
>>>
>>>
>>
> 
>