Hi Frank (and anyone else who was used the OpenGL/Lua/GEM triumvirate, I'm working on a Lua module for doing Textures, Slabs, Shaders, eventually Meshes, basically things that allocate resources within an OpenGL context and need to clean house when the context goes away. The module has a message passing system built inside it for signaling particular external conditions about contexts etc. and I'm working out how exactly it will interface into all of the potential environments Lua/OpenGL can be used in. So, for GEM:
1) How is a Lua script associated with an OpenGL context within GEM? 2) How do Lua scripts get notifications about the opening/closing/modification of OpenGL contexts within GEM? 3) Are there Lua functions or C functions for these signals?
thanks, wes
On Sun, Jan 13, 2008 at 11:18:26AM -0800, Wesley Smith wrote:
- How is a Lua script associated with an OpenGL context within GEM?
- How do Lua scripts get notifications about the
opening/closing/modification of OpenGL contexts within GEM? 3) Are there Lua functions or C functions for these signals?
I might be wrong, but my impression is that this is all to do with order of execution (which is why Gem can't really be considered 'dataflow'). You need to use [t a a ...] objects to specify where in the chain your lua script is executed, and that will be your context.
Best,
Chris.
------------------- http://mccormick.cx
I might be wrong, but my impression is that this is all to do with order of execution (which is why Gem can't really be considered 'dataflow'). You need to use [t a a ...] objects to specify where in the chain your lua script is executed, and that will be your context.
Hi Chris, Thanks for the response. So then how does one get any kind of notification if the context goes away? Is this something the user making the patch would have to take care of? For example, let's say I had a shader in a Lua script. When the context the shader is compiled and allocated in goes away, I'd like to be able to free its resources just before it is deallocated. Is there a way to do this?
thanks, wes
On Tue, Jan 15, 2008 at 05:21:34PM -0800, Wesley Smith wrote:
I might be wrong, but my impression is that this is all to do with order of execution (which is why Gem can't really be considered 'dataflow'). You need to use [t a a ...] objects to specify where in the chain your lua script is executed, and that will be your context.
Hi Chris, Thanks for the response. So then how does one get any kind of notification if the context goes away? Is this something the user making the patch would have to take care of? For example, let's say I had a shader in a Lua script. When the context the shader is compiled and allocated in goes away, I'd like to be able to free its resources just before it is deallocated. Is there a way to do this?
I don't know that much about shaders in Gem (my copy of Gem doesn't have the glsl stuff) , but I think I get what you're saying. So you are:
1. Compiling and allocating a shader in the LUA script. 2. Using that shader outside the lua script in some Gem stuff. 3. Finished with the shader, but you don't know how to free it's resources.
If that's the case I guess you could just put a second lua script later in the chain (e.g. further left on the [t a a ...]) that frees the resources?
I'm a bit out of my depth here. What is it that makes the shader context "go away"?
Chris.
------------------- http://mccormick.cx
I don't know that much about shaders in Gem (my copy of Gem doesn't have the glsl stuff) , but I think I get what you're saying. So you are:
- Compiling and allocating a shader in the LUA script.
- Using that shader outside the lua script in some Gem stuff.
- Finished with the shader, but you don't know how to free it's
resources.
close but not quite 1. Compiling and allocating a shader in the LUA script. 2. Using that shader _inside_ the lua script 3. Finished with the shader, but you don't know how to free it's resources (this happens when the render window goes away ... I want that notification)
wes
hi, the timing and erasing is usually done by the gemwin. afaik there is no way to get the erase trigger and the render trigger as two separate events from gemwin. what you probably have to do is erase the rendercontext manually by setting gemwin to singlebuffer(?) and then erasing the "window" with a bang to gemwin. I'm am just guessing here, but maybe do a [t b b b]: 1) bang to gemwin (erase old context) 2) bang to lua (free resources and then draw new) 3) bang to the gemhead for the gem renderchain do you have a working luagl version for os x? do you also have the problem that the gemwin doesnot come to the foreground? are you on mac at all? marius.
Wesley Smith wrote:
I don't know that much about shaders in Gem (my copy of Gem doesn't have the glsl stuff) , but I think I get what you're saying. So you are:
- Compiling and allocating a shader in the LUA script.
- Using that shader outside the lua script in some Gem stuff.
- Finished with the shader, but you don't know how to free it's
resources.
close but not quite
- Compiling and allocating a shader in the LUA script.
- Using that shader _inside_ the lua script
- Finished with the shader, but you don't know how to free it's
resources (this happens when the render window goes away ... I want that notification)
wes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Jan 15, 2008 7:53 PM, marius schebella marius.schebella@gmail.com wrote:
hi, the timing and erasing is usually done by the gemwin. afaik there is no way to get the erase trigger and the render trigger as two separate events from gemwin.
Ok, I'm actually not trying to get the render trigger. I'm looking for an event like dest_closed where dest would be the window and the window is closing. How does, for example, a texture in GEM deallocate its resources properly? I'll take a look at the source and see.
do you have a working luagl version for os x?
Yes
do you also have the problem that the gemwin doesnot come to the foreground? are you on mac at all?
I actually don't have pd and GEM installed. I'm simply building a Lua module called glo (GL Objects) that contains shaders, textures, slabs, etc. These things need events that indicate information about the context to properly manage opengl resources. With this thread, I was trying to find out if there was a simple way to plug into such events (if they even existed). I don't really plan on downloading GEM, I'm just trying to make sure the design of the glo Lua module is flexible enough to support a wide range of embedding contexts.
best, wes
This is basically what I was looking for although I still have to follow it to see where it keads,
1045 ///////////////////////////////////////////////////////// 1046 // stopRendering 1047 // 1048 ///////////////////////////////////////////////////////// 1049 void GemMan :: stopRendering() 1050 { 1051 if (!m_rendering) return; 1052 1053 m_rendering = 0; 1054 clock_unset(s_clock); 1055 s_hit = 1; 1056 1057 // clean out all of the gemheads 1058 gemheadLink *head = s_linkHead; 1059 while(head) 1060 { 1061 head->base->stopRendering(); 1062 head = head->next; 1063 } 1064 1065 post("GEM: Stop rendering"); 1066 } 1067
wes
I've only dabbled with GEM about 4 years ago, so please pardon my ignorance here. I found the signal for context destruction here:
void gemhead :: outputRenderOnOff(int state) 164 { 165 // continue sending out the cache message 166 t_atom ap[1]; 167 SETFLOAT(ap, state); 168 outlet_anything(this->m_out1, gensym("gem_state"), 1, ap); 169 } 170
What exactly happens in a patch when this executes? Does a "gem_state 0" message propagate through the gemhead chain to all objects connected? What is the normal message that passes through this chain?
thanks, wes
hi
sorry for not answering any earlier. i have been away...
Wesley Smith wrote:
I've only dabbled with GEM about 4 years ago, so please pardon my ignorance here. I found the signal for context destruction here:
void gemhead :: outputRenderOnOff(int state) 164 { 165 // continue sending out the cache message 166 t_atom ap[1]; 167 SETFLOAT(ap, state); 168 outlet_anything(this->m_out1, gensym("gem_state"), 1, ap); 169 } 170
What exactly happens in a patch when this executes? Does a "gem_state 0" message propagate through the gemhead chain to all objects
yes.
connected? What is the normal message that passes through this chain?
it's like this
"gem_state 1" is sent whenever the rendering is turned on and triggers the "startRendering"-method of each class. "gem_state (pointer) (pointer)" triggers the actual rendering in each cycle; the actual gemstate (image-data, texcoords,...) is available in the structure the pointer points to. "gem_state 0" is sent whenever the rendering is turned off.
all of the above messages propagate through all gem-objects. turning rendering on/off is not the same as creating/destroying the window (but probably you are fine with that)
i hope this helps.
mfga.sdr IOhannes
Thank you very much IOhannes. wes
On Jan 16, 2008 1:33 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
hi
sorry for not answering any earlier. i have been away...
Wesley Smith wrote:
I've only dabbled with GEM about 4 years ago, so please pardon my ignorance here. I found the signal for context destruction here:
void gemhead :: outputRenderOnOff(int state) 164 { 165 // continue sending out the cache message 166 t_atom ap[1]; 167 SETFLOAT(ap, state); 168 outlet_anything(this->m_out1, gensym("gem_state"), 1, ap); 169 } 170
What exactly happens in a patch when this executes? Does a "gem_state 0" message propagate through the gemhead chain to all objects
yes.
connected? What is the normal message that passes through this chain?
it's like this
"gem_state 1" is sent whenever the rendering is turned on and triggers the "startRendering"-method of each class. "gem_state (pointer) (pointer)" triggers the actual rendering in each cycle; the actual gemstate (image-data, texcoords,...) is available in the structure the pointer points to. "gem_state 0" is sent whenever the rendering is turned off.
all of the above messages propagate through all gem-objects. turning rendering on/off is not the same as creating/destroying the window (but probably you are fine with that)
i hope this helps.
mfga.sdr IOhannes
Would it be useful to put the context info into the gemstate? This would possibly allow another language object to attach things to the context if the pointer and data are properly handled. It would also help with updating some of the Quicktime code which can move textures into a context directly.
On Jan 16, 2008 3:33 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
it's like this
"gem_state 1" is sent whenever the rendering is turned on and triggers the "startRendering"-method of each class. "gem_state (pointer) (pointer)" triggers the actual rendering in each cycle; the actual gemstate (image-data, texcoords,...) is available in the structure the pointer points to. "gem_state 0" is sent whenever the rendering is turned off.
all of the above messages propagate through all gem-objects. turning rendering on/off is not the same as creating/destroying the window (but probably you are fine with that)
i hope this helps.
mfga.sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Jan 15, 2008, at 10:59 PM, Wesley Smith wrote:
On Jan 15, 2008 7:53 PM, marius schebella marius.schebella@gmail.com wrote:
hi, the timing and erasing is usually done by the gemwin. afaik there is no way to get the erase trigger and the render trigger as two separate events from gemwin.
Ok, I'm actually not trying to get the render trigger. I'm looking for an event like dest_closed where dest would be the window and the window is closing. How does, for example, a texture in GEM deallocate its resources properly? I'll take a look at the source and see.
do you have a working luagl version for os x?
Yes
do you also have the problem that the gemwin doesnot come to the foreground? are you on mac at all?
I actually don't have pd and GEM installed. I'm simply building a Lua module called glo (GL Objects) that contains shaders, textures, slabs, etc. These things need events that indicate information about the context to properly manage opengl resources. With this thread, I was trying to find out if there was a simple way to plug into such events (if they even existed). I don't really plan on downloading GEM, I'm just trying to make sure the design of the glo Lua module is flexible enough to support a wide range of embedding contexts.
FYI: Pd doesn't need to be installed. So if you want to test something, just download the dmg and double-click it to run it. It'll leave no trace on your computer, unless you click "save all settings" the preferences.
http://puredata.info/downloads
or for Leopard (test build):
http://autobuild.puredata.info/auto-build/2007-12-31/Pd-0.40.3- extended-20071231-macosx104-i386.dmg
.hc
best, wes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
-
chris clepper -
Chris McCormick -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella -
Wesley Smith