[GEM-dev] automated drawing in gem?

[cyrille henry]

hello,


B. Bogart a écrit :
> Indeed it does,
> 
> I find this thread interesting because of the drawing I've been doing
> has been with stuff like texture feedback and repeat.
> 
> I started doing stuff with the gl headers, but what was missing (I
> realized) was the ability to create open-ended objects. Like a spline
> that gets longer and longer over time.
> 
> This means there would need to be more and more vertex() functions
> between glbegin() and glend() per frame.

on the Lsystem exemple, i use a message box to store a list of data to be draw at each frame.
it's easy to add data to this list.

you can also use the same technic between gl_begin and gl_end with textfile.


resulting somthing like : 

gemhead
|
t a a a
 | | |
 | | GEMglbegin
 | |
 | repeat
 | |
 | t a b
 | |   |
 | |  textfile
 | |    |
 | GEMglvertex
 |  
 GEMglend


increasing the repeat value when adding value to the textfile.


> 
> Using the wrappers it means that a gemchain would get longer and longer
> over time, and have to be dynamically built. Possible, but certainly
> irritating.
> 
> The best "drawing" solution I can think of is an object that has an
> internal display list that operations (function calls) can be added to
> and removed from (like a linklist maybe). for example:
> 
> [12<
>  |
> [until]
>  |
> [t f f]
>  |   |
>  |  [random] # abstraction that sends 3 random numbers in a list
>  |   | | |
> [pack f f f f]
>  |
> [add $1 vertex $2 $3 $4] # $1 is the index of this entry
>  |
> [glDraw] (has glBegin and glEnd
> 

the last Lsystem exemple is a simple implmentation of this.

cyrille


> You could set some of those wrapper flags (like GL_LINE_STRIP) via
> messages to glDraw, and a "add" message or something would add something
> to the linked list, that gets sorted and executed between glBegin and
> glEnd for *each* render cycle.
> 
> So the patch above would create a static 12 vertex structure where the
> vertex's are random, but not moving. You could add another vertex to it
> by doing "remove 11" (where 11 would be the last index of the last
> entry.) Insert could get ugly for managing the indexes...
> 
> Of course the number of vertexes would not be limitless, but it could do
> a pretty nice job...
> 
> Perhaps the arguments to "add" would be something different than GL, so
> each entry could be a vertex with all its attributes, rather than having
> to have a separate entry for the vertex, and its colour.
> 
> Just thinking aloud...
> 
> B.
> 
> 
> chris clepper wrote:
>> On 9/19/07, *Frank Barknecht* <fbar at footils.org
>> <mailto:fbar at footils.org>> wrote:
>>
>>     This works?! Amazing. I just recently jumped onto the Lua train a
>>     bit. I see that there are several GL-bindings for Lua. Is luagl the
>>     one to use?
>>
>>
>> Doesn't Python also have GL?
>>
>> http://pyopengl.sourceforge.net/
>>
>> Not sure if the calls require any special context to be created, but
>> most things between glBegin() and glEnd() should work, albeit in a
>> slightly dumb way.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
> 
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> 
>