On 5/21/06, <b class="gmail_sendername">sven</b> &lt;<a href="mailto:ml.sven@subscience.de">ml.sven@subscience.de</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 21:30 21.05.2006, geadsch wrote:<br>&gt;hi!<br>&gt;<br>&gt;i am using [pix_snap2tex] to take a snapshot of the gem-window and<br>&gt;texture it on a object.<br>&gt;<br>&gt;the current render buffer is textured immediately.
<br>&gt;<br>&gt;is there a way to delay the texturing?<br>&gt;like delaying the gem-list somehow?<br><br>you can't delay the gem-list the way you can delay normal messages.<br>have a look at [pix_buffer], [pix_buffer_write], [pix_buffer_read] - that
<br>will help for what you want to do.</blockquote><div><br>Those objects won't work with pix_snap2tex but they will work with pix_snap.&nbsp; pix_snap is not a high performance object since it reads back from the graphics card - an expensive operation on commodity hardware.
<br><br>There is no way to delay the texturing of pix_snap2tex since that object is a wrapper for an OpenGL texturing call.&nbsp; There is a way to copy to a texture unit and not immediately display the results, but it is not as simple to do in the Pd patcher as we (the GEM devs) would like.
<br><br>Anyone interested in going beyond the usual drawing objects and pixel filters in GEM is highly encouraged to pick up a copy of the OpenGL 'Redbook' to learn more about how GEM really works.<br></div></div><br>