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@footils.org mailto:fbar@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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev