[sharing is fun: new toys] OpenGL preview

Aug 13, 2006 at 3:11am

[sharing is fun: new toys] OpenGL preview

If you have Jitter 1.6, there are some new features that aren’t
entirely obvious. One of them is shared contexts for texture memory
on the GPU in order to make an OpenGL preview window. If you’re doing
a performance and the projection screen is behind or otherwise outside
of your field of vision, you can now make a fully hardware accelerated
copy of what’s being projected in a preview window for yourself.

In Jitter 1.6, jit.gl.render has some new attributes, among them are
@copy_texture and @shared_context. @copy texture designates a named
texture to for jit.gl.render to copy each frame into and
@shared_context designates a second OpenGL context to share resources
with. Put these 2 attributes together and you have an OpenGL preview
window. This works with both jit.window and jit.pwindow. Obviously
this doesn’t come without some kind of performance hit, but if your
resolution isn’t massive, it should be tolerable. The patch is below.

best,
wes

#P window setfont “Sans Serif” 14.;
#P window linecount 1;
#P comment 513 43 133 196622 jit.window context;
#P comment 524 266 145 196622 jit.pwindow context;
#P window setfont “Sans Serif” 9.;
#P newex 622 313 48 196617 loadbang;
#P toggle 622 334 15 0;
#P newex 622 353 57 196617 qmetro 60;
#P newex 622 374 50 196617 t b erase;
#P newex 622 399 94 196617 jit.gl.render pprev;
#P comment 249 212 106 196617 preview in pwindow;
#P comment 249 192 106 196617 no preview;
#P newex 431 270 48 196617 loadbang;
#P message 30 212 212 196617 shared_context pprev , copy_texture pwatch;
#P message 431 291 62 196617 name pprev;
#P newex 66 309 236 196617 jit.gl.texture pprev @name pwatch @dim 160 120;
#P newex 66 333 264 196617 jit.gl.videoplane pprev @scale 1.333 1
@texture pwatch;
#P comment 66 291 330 196617 texture can belong to either pprev or
main context if sharing is enabled;
#P message 30 192 103 196617 shared_context none;
#P message 30 172 202 196617 shared_context prev , copy_texture watch;
#P user umenu 66 356 100 196647 1 64 372 1;
#X add none;
#X add watch;
#P newex 66 378 82 196617 prepend capture;
#P window linecount 2;
#P newex 66 401 225 196617 jit.gl.gridshape main @shape torus @color
0.8 0.1 0.1 0.8 @lighting_enable 1 @blend_enable 1;
#P window linecount 1;
#P newex 490 95 226 196617 jit.gl.texture prev @name watch @dim 160 120;
#P newex 490 119 254 196617 jit.gl.videoplane prev @scale 1.333 1
@texture watch;
#P newex 395 54 48 196617 loadbang;
#P toggle 395 75 15 0;
#P newex 395 94 57 196617 qmetro 60;
#P newex 395 115 50 196617 t b erase;
#P toggle 115 56 15 0;
#P message 115 76 68 196617 fullscreen $1;
#N vpatcher 30 89 166 253;
#P window setfont “Sans Serif” 9.;
#P newex 50 71 35 196617 sel 27;
#P newex 50 50 40 196617 key;
#P outlet 50 93 15 0;
#P connect 1 0 2 0;
#P connect 2 0 0 0;
#P pop;
#P newobj 115 36 33 196617 p Esc;
#P newex 13 54 48 196617 loadbang;
#P message 76 94 34 196617 reset;
#P newex 76 115 189 196617 jit.gl.handle main @inherit_transform 1;
#P toggle 13 75 15 0;
#P newex 13 94 57 196617 qmetro 33;
#P newex 13 115 50 196617 t b erase;
#P newex 13 140 367 196617 jit.gl.render main @camera 0 0 4
@copy_texture watch @shared_context prev;
#P comment 490 77 323 196617 texture can belong to either prev or main
context if sharing is enabled;
#P newex 395 140 89 196617 jit.gl.render prev;
#P newex 115 94 216 196617 jit.window main @depthbuffer 1 @pos 10 200;
#P newex 490 140 281 196617 jit.window prev @depthbuffer 1 @size 160
120 @pos 10 50;
#P user jit.pwindow 430 312 162 122 0 1 0 0 1 0;
#X name pprev;
#P comment 249 172 106 196617 preview in jit.window;
#P window setfont “Sans Serif” 14.;
#P comment 176 43 100 196622 Main Context;
#P connect 13 0 10 0;
#P connect 10 0 9 0;
#P connect 9 0 8 0;
#P connect 32 0 7 0;
#P connect 27 0 7 0;
#P connect 26 0 7 0;
#P fasten 11 0 7 0 81 136 18 136;
#P fasten 8 0 7 0 18 136 18 136;
#P fasten 8 1 7 0 58 136 18 136;
#P fasten 25 1 24 0 161 375 71 375;
#P connect 24 0 23 0;
#P connect 12 0 11 0;
#P connect 14 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 4 0;
#P connect 20 0 19 0;
#P connect 19 0 18 0;
#P connect 18 0 17 0;
#P fasten 17 0 5 0 400 136 400 136;
#P fasten 17 1 5 0 440 136 400 136;
#P connect 33 0 31 0;
#P connect 31 0 2 0;
#P connect 40 0 39 0;
#P connect 39 0 38 0;
#P connect 38 0 37 0;
#P fasten 37 0 36 0 627 395 627 395;
#P fasten 37 1 36 0 667 395 627 395;
#P window clipboard copycount 43;

#27139
Aug 15, 2006 at 6:11pm

do you find this faster than the previous method of doing a preview window using texture readback? This is what I”m using now, and it works pretty well on my machine with a PCIe graphics card, even if my 2nd monitor is 1024×768, but AGP cards seem to suffer from this with a 1024×768 output.
I look forward to trying this in 1.6, esp when 1.6 is on XP.

#81848
Aug 15, 2006 at 6:57pm

I was using your exact method, and switched to the preview method Wes
showed us. I dont notice any real speed difference, it just seems a
little more elegant (the new method), as it gets the whole context,
not just the texture (should you for example want to tint/color,
change the geometry that the texture is being drawn on).

v a d e //

http://www.vade.info
abstrakt.vade.info

On Aug 15, 2006, at 2:11 PM, pnyboer wrote:

>
> do you find this faster than the previous method of doing a preview
> window using texture readback? This is what I”m using now, and it
> works pretty well on my machine with a PCIe graphics card, even if
> my 2nd monitor is 1024×768, but AGP cards seem to suffer from this
> with a 1024×768 output.
> I look forward to trying this in 1.6, esp when 1.6 is on XP.
> –
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||

#81849
Aug 15, 2006 at 7:02pm

good to know….i am hoping the elegance is increased by not having to create a separate jit.gl.texture object for each possible res of the 2nd monitor for the readback (currently, I have 3: 1024, 800, and 640, and have to do a res-detect before readback) becuase you can’t change the dim of the texture dynamically for this.

#81850
Aug 15, 2006 at 7:10pm

Hey Peter,
This was fixed as well in 1.6. If your jit.gl.texture object is given
@adapt 1, it will automatically adapt to the context size when rendering
to texture.

Andrew B.

#81851
Aug 15, 2006 at 7:14pm

jitter 1.6 fixes this as well, with @adapt 1 for the texture
destination dim as well. (iirc, ymmv, etc etc). So yeah, with 1.6,
using texture preview, I only had one target texture and it worked
fine with resizing. Wes was kind enough to show me the OGL preview at
siggraph, and while I didnt see any speed difference, it just like a
better solution.

ive been using 1.6 for a while now, with my thesis codebase, and its
really a nice update for most of these things, and surprisingly
stable as well.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Aug 15, 2006, at 3:02 PM, pnyboer wrote:

>
> good to know….i am hoping the elegance is increased by not having
> to create a separate jit.gl.texture object for each possible res of
> the 2nd monitor for the readback (currently, I have 3: 1024, 800,
> and 640, and have to do a res-detect before readback) becuase you
> can’t change the dim of the texture dynamically for this.
> –
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||

#81852
Aug 15, 2006 at 7:16pm

This is one of the things I worked around in render_node, through
dynamically creating new textures with JS. So there’s a workaround
if you want one. But I don’t think it should be needed anymore–
some issues with texture resizing were fixed in 1.6.

best,
Randy

On Aug 15, 2006, at 12:02 PM, pnyboer wrote:

>
> good to know….i am hoping the elegance is increased by not having
> to create a separate jit.gl.texture object for each possible res of
> the 2nd monitor for the readback (currently, I have 3: 1024, 800,
> and 640, and have to do a res-detect before readback) becuase you
> can’t change the dim of the texture dynamically for this.
> –
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||
>

#81853
Sep 6, 2006 at 11:59pm

Fantastic! I’ve been waiting for this for quite a while!

But I’m not sure I understand the behavior of the shared_context flag. It looks as though a named texture which is used with capture is available to all other render contexts by default (demonstrated in the patch below.) I like this behavior just fine since it allows a preview or output to be attached to any stage of a filter graph. And this seems more efficient since a copy isn’t required. But is that how it’s supposed to work?

- Paul

max v2;
#N vpatcher 259 289 1047 692;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 108 95 189 196617 jit.gl.handle main @inherit_transform 1;
#P newex 56 144 82 196617 jit.window main;
#P newex 400 311 193 196617 jit.gl.videoplane prev_2 @texture watch;
#P newex 400 203 48 196617 loadbang;
#P toggle 400 224 15 0;
#P newex 400 243 57 196617 qmetro 60;
#P newex 400 264 50 196617 t b erase;
#P newex 400 289 101 196617 jit.gl.render prev_2;
#P newex 400 332 94 196617 jit.window prev_2;
#P newex 56 163 157 196617 jit.gl.texture main @name watch;
#P newex 401 152 193 196617 jit.gl.videoplane prev_1 @texture watch;
#P newex 401 44 48 196617 loadbang;
#P toggle 401 65 15 0;
#P newex 401 84 57 196617 qmetro 60;
#P newex 401 105 50 196617 t b erase;
#P newex 401 130 101 196617 jit.gl.render prev_1;
#P newex 401 173 94 196617 jit.window prev_1;
#P newex 56 34 48 196617 loadbang;
#P toggle 56 55 15 0;
#P newex 56 74 57 196617 qmetro 33;
#P newex 56 95 50 196617 t b erase;
#P newex 56 120 89 196617 jit.gl.render main;
#P user umenu 48 259 100 196647 1 64 275 1;
#X add none;
#X add watch;
#P newex 48 281 82 196617 prepend capture;
#P newex 48 304 248 196617 jit.gl.gridshape main @shape sphere @poly_mode 1 1;
#P fasten 2 1 1 0 143 278 53 278;
#P connect 1 0 0 0;
#P connect 7 0 6 0;
#P connect 6 0 5 0;
#P connect 5 0 4 0;
#P fasten 4 0 3 0 61 116 61 116;
#P fasten 4 1 3 0 101 116 61 116;
#P connect 24 0 3 0;
#P connect 21 0 20 0;
#P connect 20 0 19 0;
#P connect 19 0 18 0;
#P fasten 18 0 17 0 405 285 405 285;
#P fasten 18 1 17 0 445 285 405 285;
#P connect 13 0 12 0;
#P connect 12 0 11 0;
#P connect 11 0 10 0;
#P fasten 10 1 9 0 446 126 406 126;
#P fasten 10 0 9 0 406 126 406 126;
#P pop;

#81854
Sep 7, 2006 at 12:41am

jit.gl.render @shared_context will call the OS specific function for
sharing resources across OpenGL contexts. It works a bit differently
from OSX to windows. On OSX, the aglCreateContext (or something like
that) function can take an optional paraemter specifying a context
with which displaylists, textures, and the like are shared. On
Windows, the function is instead wglShareLists. On OSX, the texture
can be in any context that is shared and be accessible. On Windows,
things choke a bit if you share things and then recreate the main
context, so make sure the textures and such are in the main context.
Otherwise, your shared texture may become all white. This is not
really a limitation, just something to be aware of.

The reason your patch works is that these @capture textures are using
pbuffers which have their own context independent of the opengl
context, which is why they can naturally be shared between contexts.

Setting @shared_context gives a bit more flexibility in texture
sharing. THe patch below shows what I’m talking about. Incidentally,
in making this patch, a few issues have come up that need to be fixed.
It seems that there’s an order of operations thing going on here that
needs to be addressed. In any case, texture sharing does work with
@shared_context, but at some point if it doesn’t seem to be doing its
thing the right way, reinstantiate the texture and that should fix
things.

wes

#P window setfont “Sans Serif” 9.;
#P user umenu 112 83 100 196647 1 64 99 1;
#X add none;
#X add prev_1;
#X add prev_2;
#P window linecount 1;
#P newex 110 104 118 196617 prepend shared_context;
#P button 32 248 15 0;
#P newex 32 268 48 196617 loadbang;
#P newex 32 291 121 196617 jit.noise 4 char 100 100;
#P newex 32 319 153 196617 jit.gl.texture main @name noise;
#P newex 30 212 177 196617 jit.gl.videoplane main @texture noise;
#P newex 32 152 138 196617 jit.window main @pos 40 70;
#P newex 257 307 189 196617 jit.gl.videoplane prev_2 @texture noise;
#P newex 257 199 48 196617 loadbang;
#P toggle 257 220 15 0;
#P newex 257 239 57 196617 qmetro 60;
#P newex 257 260 50 196617 t b erase;
#P newex 257 285 101 196617 jit.gl.render prev_2;
#P newex 257 328 156 196617 jit.window prev_2 @pos 40 610;
#P newex 258 148 189 196617 jit.gl.videoplane prev_1 @texture noise;
#P newex 258 40 48 196617 loadbang;
#P toggle 258 61 15 0;
#P newex 258 80 57 196617 qmetro 60;
#P newex 258 101 50 196617 t b erase;
#P newex 258 126 101 196617 jit.gl.render prev_1;
#P newex 258 169 156 196617 jit.window prev_1 @pos 40 340;
#P newex 32 42 48 196617 loadbang;
#P toggle 32 63 15 0;
#P newex 32 82 57 196617 qmetro 33;
#P newex 32 103 50 196617 t b erase;
#P newex 32 132 206 196617 jit.gl.render main @shared_context prev_1;
#P connect 22 0 21 0;
#P connect 8 0 7 0;
#P connect 2 0 1 0;
#P fasten 7 1 6 0 303 122 263 122;
#P fasten 7 0 6 0 263 122 263 122;
#P connect 9 0 8 0;
#P connect 10 0 9 0;
#P fasten 14 0 13 0 262 281 262 281;
#P fasten 14 1 13 0 302 281 262 281;
#P connect 15 0 14 0;
#P connect 16 0 15 0;
#P connect 17 0 16 0;
#P fasten 26 1 25 0 207 101 115 101;
#P connect 23 0 22 0;
#P connect 24 0 23 0;
#P fasten 25 0 0 0 115 126 37 126;
#P fasten 1 0 0 0 37 124 37 124;
#P fasten 1 1 0 0 77 124 37 124;
#P connect 3 0 2 0;
#P connect 4 0 3 0;
#P window clipboard copycount 27;

On 9/6/06, Paul Greyson

wrote:
>
> Fantastic! I’ve been waiting for this for quite a while!
>
> But I’m not sure I understand the behavior of the shared_context flag. It looks as though a named texture which is used with capture is available to all other render contexts by default (demonstrated in the patch below.) I like this behavior just fine since it allows a preview or output to be attached to any stage of a filter graph. And this seems more efficient since a copy isn’t required. But is that how it’s supposed to work?
>
> – Paul
>
> max v2;
> #N vpatcher 259 289 1047 692;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 108 95 189 196617 jit.gl.handle main @inherit_transform 1;
> #P newex 56 144 82 196617 jit.window main;
> #P newex 400 311 193 196617 jit.gl.videoplane prev_2 @texture watch;
> #P newex 400 203 48 196617 loadbang;
> #P toggle 400 224 15 0;
> #P newex 400 243 57 196617 qmetro 60;
> #P newex 400 264 50 196617 t b erase;
> #P newex 400 289 101 196617 jit.gl.render prev_2;
> #P newex 400 332 94 196617 jit.window prev_2;
> #P newex 56 163 157 196617 jit.gl.texture main @name watch;
> #P newex 401 152 193 196617 jit.gl.videoplane prev_1 @texture watch;
> #P newex 401 44 48 196617 loadbang;
> #P toggle 401 65 15 0;
> #P newex 401 84 57 196617 qmetro 60;
> #P newex 401 105 50 196617 t b erase;
> #P newex 401 130 101 196617 jit.gl.render prev_1;
> #P newex 401 173 94 196617 jit.window prev_1;
> #P newex 56 34 48 196617 loadbang;
> #P toggle 56 55 15 0;
> #P newex 56 74 57 196617 qmetro 33;
> #P newex 56 95 50 196617 t b erase;
> #P newex 56 120 89 196617 jit.gl.render main;
> #P user umenu 48 259 100 196647 1 64 275 1;
> #X add none;
> #X add watch;
> #P newex 48 281 82 196617 prepend capture;
> #P newex 48 304 248 196617 jit.gl.gridshape main @shape sphere @poly_mode 1 1;
> #P fasten 2 1 1 0 143 278 53 278;
> #P connect 1 0 0 0;
> #P connect 7 0 6 0;
> #P connect 6 0 5 0;
> #P connect 5 0 4 0;
> #P fasten 4 0 3 0 61 116 61 116;
> #P fasten 4 1 3 0 101 116 61 116;
> #P connect 24 0 3 0;
> #P connect 21 0 20 0;
> #P connect 20 0 19 0;
> #P connect 19 0 18 0;
> #P fasten 18 0 17 0 405 285 405 285;
> #P fasten 18 1 17 0 445 285 405 285;
> #P connect 13 0 12 0;
> #P connect 12 0 11 0;
> #P connect 11 0 10 0;
> #P fasten 10 1 9 0 446 126 406 126;
> #P fasten 10 0 9 0 406 126 406 126;
> #P pop;
>
>

#81855
Sep 7, 2006 at 12:58am

>>>
Setting @shared_context gives a bit more flexibility in texture
sharing.
< <<
So I guess the flexibility you’re referring to is the ability to fill the texture using something other than capture/obj3d?

#81856
Sep 7, 2006 at 1:26am

Yes. Plus the ability to take the framebuffer at the end of rendering
and copy it to a texture for use in a different context of which a
preview window is on special case.

wes

On 9/6/06, Paul Greyson

wrote:
>
> >>>
> Setting @shared_context gives a bit more flexibility in texture
> sharing.
> < <<
> So I guess the flexibility you’re referring to is the ability to fill the texture using something other than capture/obj3d?
>

#81857
Sep 7, 2006 at 4:35am

>>>
Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.
< <<

Can’t that also be done with capture? How is the capture pbuffer different than a texture that’s copied from a render context?

#81858
Sep 7, 2006 at 4:35am

>>>
Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.
< <<

Can’t that also be done with capture? How is the capture pbuffer different than a texture that’s copied from a render context?

#81859
Sep 7, 2006 at 4:52am

If you capture < > to the pbuffer, it’s no different. If
you don’t want the hassle of doing this or can’t afford a 1280×1024
size texture, then it’s probably better.

wes

On 9/6/06, Paul Greyson

wrote:
>
> >>>
> Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.
> < <<
>
> Can’t that also be done with capture? How is the capture pbuffer different than a texture that’s copied from a render context?
>

#81860
Sep 7, 2006 at 5:32am

>>>
If you capture *everything* to the pbuffer, it’s no different
< <<
Sorry, I don’t understand. It should be possible to have multiple obj3d’s in the same render context each rendering to a different pbuffer, no? If that’s the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)

#81861
Sep 7, 2006 at 5:49am

> Sorry, I don’t understand. It should be possible to have multiple obj3d’s in the same render context each rendering to a different pbuffer, no? If that’s the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)
>

Ok, here’s the deal. Let’s say I’m rendering a gridshape with alpha
0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the
middle of the gridshape. If you render both things to different
pbuffers and then blen the textures together, it ain’t gonna look
right as compared to just rendering everything normally. In addition,
if I have depth testing enabled, it also won’t look right because some
parts of the mesh will be covered by the gridshape and vice-verse.

To capture what you would see in the framebuffer to a pbuffer, you
have to do something like jit.gl.render @capture tex_pbuff. This will
capture *everything*…meaning the gridshape and the mesh properly
blended together. Make sense?

wes

#81862
Sep 7, 2006 at 1:00pm

One method I worked out, to allow multiple objects to be all captured
together, but still allow for separate scenes, is to do this

Say you want to have 2 groups of objects, that you can crossfade and
blend between, but which will render correctly when you are in
‘channel a’ or channel b’ ( ie: dont have the issues Wes’ described)

make two textures, tex1 and tex2

set up all of your ob3Ds with automatic 0, @name ,
and DONT hook them up to anything. Nothing will render.

make a jit.gl.sketch @capture texture1 @automatic 0 and a
jit.gl.sketch @capture texture2 @automatic 0

tell the jit.gl.sketch objects to [drawobject ] and your
ob3D object will pop onto the texture that is capturing the sketch
object.

Do that for multiple objects, and you can control the scene. Throw in
a few slabs, and a videoplane to texture on, and you are all set (as
long as your render order for the sketches, and video plane is
correct ;)

Ive got an example patch, but Im about to run off to work. Let me
know if you want it. it works quite well.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Sep 7, 2006, at 1:49 AM, Wesley Smith wrote:

>> Sorry, I don’t understand. It should be possible to have multiple
>> obj3d’s in the same render context each rendering to a different
>> pbuffer, no? If that’s the case, then it seems that anything that
>> can be done with shared textures can also be done with capture/
>> pbuffers (with the exception of the matrix->texture type stuff you
>> mentioned.)
>>
>
> Ok, here’s the deal. Let’s say I’m rendering a gridshape with alpha
> 0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the
> middle of the gridshape. If you render both things to different
> pbuffers and then blen the textures together, it ain’t gonna look
> right as compared to just rendering everything normally. In addition,
> if I have depth testing enabled, it also won’t look right because some
> parts of the mesh will be covered by the gridshape and vice-verse.
>
> To capture what you would see in the framebuffer to a pbuffer, you
> have to do something like jit.gl.render @capture tex_pbuff. This will
> capture *everything*…meaning the gridshape and the mesh properly
> blended together. Make sense?
>
> wes

#81863
Sep 7, 2006 at 5:42pm

>>>
If you render both things to different
pbuffers and then blen the textures together, it ain’t gonna look
right as compared to just rendering everything normally.
< <<

Ah right. I see your point.

In my application I do all 3d rendering for each layer of the mix in a single external so I think pbuffers will be a better solution for me.

Thanks for the insights.

#81864
Sep 7, 2006 at 5:50pm

>>>
tell the jit.gl.sketch objects to [drawobject ] and your
ob3D object will pop onto the texture that is capturing the sketch
object.
< <<

Cool! I didn’t know you can do that.

So it looks like I can have the best of both worlds by aggregating obj3d’s using sketch and compositing layers using capture.

#81865
Sep 7, 2006 at 6:08pm

yeah, it works pretty well, and its super sexy to use imageunits to
work with photoshop style blend modes on the geometry. Of course,
only using a spinning torus if you are truly hardcore, right greg?

v a d e //

http://www.vade.info
abstrakt.vade.info

On Sep 7, 2006, at 1:50 PM, Paul Greyson wrote:

>
>>>>
> tell the jit.gl.sketch objects to [drawobject ] and your
> ob3D object will pop onto the texture that is capturing the sketch
> object.
> < <<
>
> Cool! I didn’t know you can do that.
>
> So it looks like I can have the best of both worlds by aggregating
> obj3d’s using sketch and compositing layers using capture.

#81866
Sep 8, 2006 at 1:05am

On Sep 7, 2006, at 2:08 PM, vade wrote:

> yeah, it works pretty well, and its super sexy to use imageunits to
> work with photoshop style blend modes on the geometry. Of course,
> only using a spinning torus if you are truly hardcore, right greg?

Yessirree! Thanks for bringing it up. Spinning is
marginally less “so last Tuesday” in comparison
to throbbing, but all the cool kids are doing spectrally
derived flocking, which looks positively fine for
works as widely disparate as Todd Rundgren’s
“Born to Synthesize,” selections from Todd Dockstader’s
“Aerial 3,” and Busted’s “The Year 3000.”

greetings from Toronto,
gregory

#81867
Sep 8, 2006 at 9:40pm

I would love to take a look at this patch. I haven’t been able to solve these problems on my own. Thanks!

Quote: vade wrote on Thu, 07 September 2006 06:00
—————————————————-
> One method I worked out, to allow multiple objects to be all captured
> together, but still allow for separate scenes, is to do this
>
> Say you want to have 2 groups of objects, that you can crossfade and
> blend between, but which will render correctly when you are in
> ‘channel a’ or channel b’ ( ie: dont have the issues Wes’ described)
>
> make two textures, tex1 and tex2
>
> set up all of your ob3Ds with automatic 0, @name ,
> and DONT hook them up to anything. Nothing will render.
>
> make a jit.gl.sketch @capture texture1 @automatic 0 and a
> jit.gl.sketch @capture texture2 @automatic 0
>
> tell the jit.gl.sketch objects to [drawobject ] and your
> ob3D object will pop onto the texture that is capturing the sketch
> object.
>
> Do that for multiple objects, and you can control the scene. Throw in
> a few slabs, and a videoplane to texture on, and you are all set (as
> long as your render order for the sketches, and video plane is
> correct ;)
>
> Ive got an example patch, but Im about to run off to work. Let me
> know if you want it. it works quite well.
>
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>
> On Sep 7, 2006, at 1:49 AM, Wesley Smith wrote:
>
> >> Sorry, I don’t understand. It should be possible to have multiple
> >> obj3d’s in the same render context each rendering to a different
> >> pbuffer, no? If that’s the case, then it seems that anything that
> >> can be done with shared textures can also be done with capture/
> >> pbuffers (with the exception of the matrix->texture type stuff you
> >> mentioned.)
> >>
> >
> > Ok, here’s the deal. Let’s say I’m rendering a gridshape with alpha
> > 0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the
> > middle of the gridshape. If you render both things to different
> > pbuffers and then blen the textures together, it ain’t gonna look
> > right as compared to just rendering everything normally. In addition,
> > if I have depth testing enabled, it also won’t look right because some
> > parts of the mesh will be covered by the gridshape and vice-verse.
> >
> > To capture what you would see in the framebuffer to a pbuffer, you
> > have to do something like jit.gl.render @capture tex_pbuff. This will
> > capture *everything*…meaning the gridshape and the mesh properly
> > blended together. Make sense?
> >
> > wes
>
>
—————————————————-

#81868
Sep 8, 2006 at 10:16pm

Try this (nice technique Vade BTW):

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P hidden newex 265 162 45 9109513 loadbang;
#P newex 380 105 56 9109513 loadmess 2;
#P newex 482 190 152 9109513 jit.gl.slab cap @file co.additive.jxs;
#P newex 614 98 100 9109513 sprintf read co.%s.jxs;
#P user ubumenu 569 77 100 9109513 0 1 1 0;
#X add additive;
#X add average;
#X add brightlight;
#X add burn;
#X add darken;
#X add difference;
#X add dodge;
#X add exclude;
#X add freeze;
#X add glow;
#X add hardlight;
#X add heat;
#X add inverse;
#X add lighten;
#X add multiply;
#X add negate;
#X add overlay;
#X add reflect;
#X add screen;
#X add softlight;
#X add stamp;
#X add subtractive;
#X prefix_set 0 0 0;
#X pattrmode 1;
#P newex 380 191 27 9109513 + 1;
#P user radiogroup 380 139 18 48;
#X size 3;
#X offset 16;
#X inactive 0;
#X itemtype 0;
#X flagmode 0;
#X set 2;
#X done;
#P newex 440 220 53 9109513 switch 3 1;
#P newex 321 88 40 9109513 t b b b;
#P newex 321 65 33 9109513 r draw;
#P message 37 232 209 9109513 reset , drawobject cube2 0 ,
drawobject sphere2 0;
#P newex 26 256 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
group2 @automatic 0;
#P comment 164 443 100 9109513 group2;
#P window linecount 2;
#P newex 73 511 374 9109513 jit.gl.gridshape cap @shape sphere @color
0.2 1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
@automatic 0 @name sphere2 @depth_enable 0;
#P window linecount 3;
#P newex 73 462 303 9109513 jit.gl.gridshape cap @shape cube @color 1
0.5 0.5 0.2 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
@automatic 0 @name cube2 @depth_enable 1 @scale 0.5 1 0.5 @blend_mode
1 6;
#P window linecount 2;
#P newex 73 388 368 9109513 jit.gl.gridshape cap @shape plane @color 1
1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
@automatic 0 @name plane1 @depth_enable 0;
#P window linecount 1;
#P message 37 174 204 9109513 reset , drawobject plane1 0 ,
drawobject torus1 0;
#P newex 27 198 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
group1 @automatic 0;
#N vpatcher 25 70 242 240;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 71 97 35 9109513 s draw;
#P window linecount 1;
#P newex 50 50 53 9109513 t b b erase;
#P inlet 50 30 15 0;
#P outlet 92 74 15 0;
#P outlet 50 74 15 0;
#P connect 2 0 3 0;
#P connect 3 0 0 0;
#P connect 3 1 4 0;
#P connect 3 2 1 0;
#P pop;
#P newobj 29 84 37 9109513 p Draw;
#P window linecount 2;
#P newex 73 350 367 9109513 jit.gl.gridshape cap @shape torus @color 1
0 0.5 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
@automatic 0 @name torus1 @depth_enable 1;
#P window linecount 1;
#P newex 440 262 154 9109513 jit.gl.videoplane cap @scale 2.66 2;
#P newex 624 153 141 9109513 jit.gl.texture cap @name group2;
#P newex 454 153 141 9109513 jit.gl.texture cap @name group1;
#P newex 96 84 65 9109513 jit.window cap;
#P toggle 29 36 15 0;
#P newex 29 114 139 9109513 jit.gl.render cap @camera 0 0 4;
#P newex 29 60 50 9109513 qmetro 30;
#P comment 161 329 100 9109513 group1;
#P fasten 6 0 20 2 629 177 473 177;
#P connect 6 0 25 1;
#P fasten 19 0 5 0 326 130 459 130;
#P fasten 19 0 6 0 326 130 629 130;
#P connect 23 1 24 0;
#P connect 25 0 20 3;
#P fasten 24 0 25 0 619 182 487 182;
#P connect 5 0 20 1;
#P fasten 5 0 25 0 459 182 487 182;
#P connect 20 0 7 0;
#P fasten 22 0 20 0 385 214 445 214;
#P connect 21 0 22 0;
#P connect 26 0 21 0;
#P connect 18 0 19 0;
#P hidden connect 27 0 17 0;
#P hidden connect 27 0 11 0;
#P fasten 9 1 2 0 61 108 34 108;
#P connect 9 0 2 0;
#P connect 1 0 9 0;
#P connect 3 0 1 0;
#P fasten 19 1 10 0 341 152 32 152;
#P connect 11 0 10 0;
#P fasten 19 2 16 0 356 225 31 225;
#P connect 17 0 16 0;
#P window clipboard copycount 28;

#81869
Sep 8, 2006 at 11:37pm

hi,

Anybody knows a way to ‘close the recorder’ with jit.qt.record or jit.qt.grab so it’s not
necessary to quite max before erasing them totaly.
I know I saw that option somewhere but I can’t find it now.
maybe it was in softVNS.
If i m not wrong and it is not possible yet in Jitter, it would be great to see this implemented
in the future.
it really bugs me to have to close max and I went crasy trying to understand why I had some
incredible results looking for the position of the first attack in the sound track of a movie file
I just recorded with jit.qt.grab.
I found out after a bunch of hours that max was opening a file with the same name from the trash.
weird, han?

//yac

#81870
Sep 9, 2006 at 1:29am

Typically, the message is “stop”. However, I honestly have no idea
what you’re talking about. I would appreciate it if you could please
take a few moments and let your thoughts coalesce into a very
concrete form. Something like this…

BUG REPORTING GUIDELINES

Please report any problems you experience with clear and complete
information, including steps to reproduce, software and system
information, and where possible, an isolated example patch and crash
log. Something like the following would be ideal. This makes it
easier for us to find and fix the problems you experience. Without
such clear and complete information, it is less likely we will be
able to.

Summary:
Provide a descriptive summary of the issue.

Steps to Reproduce:
In numbered format, detail the exact steps taken to produce the bug.

Expected Results:
Describe what you expected to happen when you executed the steps above.

Actual Results:
Please explain what actually occurred when steps above are executed.

Regression:
Describe circumstances where the problem occurs or does not occur,
such as software versions and/or hardware configurations.

Notes:
Provide additional information, such as references to related
problems, workarounds and relevant attachments.

jb

Am 09.09.2006 um 01:37 schrieb Yacine Sebti:

> hi,
>
> Anybody knows a way to ‘close the recorder’ with jit.qt.record or
> jit.qt.grab so it’s not
> necessary to quite max before erasing them totaly.
> I know I saw that option somewhere but I can’t find it now.
> maybe it was in softVNS.
> If i m not wrong and it is not possible yet in Jitter, it would be
> great to see this implemented
> in the future.
> it really bugs me to have to close max and I went crasy trying to
> understand why I had some
> incredible results looking for the position of the first attack in
> the sound track of a movie file
> I just recorded with jit.qt.grab.
> I found out after a bunch of hours that max was opening a file with
> the same name from the trash.
> weird, han?
>
>
> //yac

#81871
Sep 9, 2006 at 8:08am

> Typically, the message is “stop”. However, I honestly have no idea
> what you’re talking about. I would appreciate it if you could please
> take a few moments and let your thoughts coalesce into a very
> concrete form. Something like this…

hi Jeremy,

ok, sorry my description was indeed messy, I was on a late night patching shift.
it wasn’t jit.qt.grab which caused my bug but buffer~.
it looks like when you import a movie into it, you can’t erase the movie anymore.
so it’s not the recorder but the ‘importer’ which is left open.
here’s a patch with steps to reproduce.

cheers
//yac

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 237 399 116 9109513 try to erase the fille;
#P comment 222 399 13 9109513 8;
#P comment 100 291 13 9109513 7;
#P comment 146 378 13 9109513 6;
#P comment 164 22 13 9109513 5;
#P comment 68 23 13 9109513 4;
#P comment 26 22 13 9109513 3;
#P comment 317 90 13 9109513 2;
#P user ezdac~ 100 376 144 409 0;
#P message 100 308 74 9109513 0 , 3000 3000;
#P newex 100 327 32 9109513 line~;
#P newex 100 347 85 9109513 play~ beep_sync;
#P window linecount 5;
#P comment 466 94 170 9109513 once hello.mov is imported into the buffer~ there is no way to erase
totally from the trash or write a new hello.mov that replaces the first except quiting max;
#P window linecount 1;
#P newex 376 311 62 9109513 prepend set;
#P message 376 332 284 9109513 hello.mov;
#P newex 174 168 62 9109513 route write;
#P newex 285 285 105 9109513 info~ beep_sync;
#P newex 174 262 121 9109513 buffer~ beep_sync 3000;
#P newex 174 237 78 9109513 prepend import;
#P toggle 9 21 15 0;
#P newex 9 39 57 9109513 qmetro 40;
#P message 164 39 29 9109513 stop;
#P message 276 39 33 9109513 close;
#P message 245 39 30 9109513 open;
#P user jit.pwindow 67 173 82 62 0 1 0 0 1 0;
#P message 332 90 79 9109513 write_audio 1;
#P newex 68 135 56 9109513 jit.qt.grab;
#P message 68 39 81 9109513 write hello.mov;
#P comment 466 75 100 9109513 watch this;
#P comment 231 40 13 9109513 1;
#P window linecount 4;
#P comment 466 162 169 9109513 if I just put it in the trash , I can record a new hello.mov but
the buffer~ imports the sound of the one in the trash;
#P user panel 456 64 188 167;
#X brgb 191 191 191;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 12 0 11 0;
#P connect 6 0 5 0;
#P connect 4 0 5 0;
#P connect 10 0 5 0;
#P connect 8 0 5 0;
#P connect 9 0 5 0;
#P connect 11 0 5 0;
#P connect 5 0 7 0;
#P connect 22 0 21 0;
#P connect 21 0 20 0;
#P connect 20 0 23 0;
#P connect 20 0 23 1;
#P fasten 5 1 16 0 119 160 179 160;
#P connect 16 0 13 0;
#P connect 13 0 14 0;
#P connect 14 1 15 0;
#P connect 15 7 18 0;
#P connect 18 0 17 0;
#P window clipboard copycount 32;

#81872
Sep 9, 2006 at 9:00am

is this patch jitter 1.6 only?
i get these errors when running it (after each single bang):

jit.gl.pbuffer: error setting target context: GL Error: Stack overflow
jit_gl_begin_capture: GL Error: Stack overflow
jit_gl_end_capture: GL Error: Stack underflow
ob3d_draw_end popmatrix: GL Error: Stack underflow
jit.gl.pbuffer: error setting target context: GL Error: Stack overflow
jit_gl_begin_capture: GL Error: Stack overflow
jit_gl_end_capture: GL Error: Stack underflow
ob3d_draw_end popmatrix: GL Error: Stack underflow

On Sep 8, 2006, at 11:16 PM, Wesley Smith wrote:

> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P hidden newex 265 162 45 9109513 loadbang;
> #P newex 380 105 56 9109513 loadmess 2;
> #P newex 482 190 152 9109513 jit.gl.slab cap @file co.additive.jxs;
> #P newex 614 98 100 9109513 sprintf read co.%s.jxs;
> #P user ubumenu 569 77 100 9109513 0 1 1 0;
> #X add additive;
> #X add average;
> #X add brightlight;
> #X add burn;
> #X add darken;
> #X add difference;
> #X add dodge;
> #X add exclude;
> #X add freeze;
> #X add glow;
> #X add hardlight;
> #X add heat;
> #X add inverse;
> #X add lighten;
> #X add multiply;
> #X add negate;
> #X add overlay;
> #X add reflect;
> #X add screen;
> #X add softlight;
> #X add stamp;
> #X add subtractive;
> #X prefix_set 0 0 0;
> #X pattrmode 1;
> #P newex 380 191 27 9109513 + 1;
> #P user radiogroup 380 139 18 48;
> #X size 3;
> #X offset 16;
> #X inactive 0;
> #X itemtype 0;
> #X flagmode 0;
> #X set 2;
> #X done;
> #P newex 440 220 53 9109513 switch 3 1;
> #P newex 321 88 40 9109513 t b b b;
> #P newex 321 65 33 9109513 r draw;
> #P message 37 232 209 9109513 reset , drawobject cube2 0 ,
> drawobject sphere2 0;
> #P newex 26 256 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
> group2 @automatic 0;
> #P comment 164 443 100 9109513 group2;
> #P window linecount 2;
> #P newex 73 511 374 9109513 jit.gl.gridshape cap @shape sphere @color
> 0.2 1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> @automatic 0 @name sphere2 @depth_enable 0;
> #P window linecount 3;
> #P newex 73 462 303 9109513 jit.gl.gridshape cap @shape cube @color 1
> 0.5 0.5 0.2 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> @automatic 0 @name cube2 @depth_enable 1 @scale 0.5 1 0.5 @blend_mode
> 1 6;
> #P window linecount 2;
> #P newex 73 388 368 9109513 jit.gl.gridshape cap @shape plane @color 1
> 1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> @automatic 0 @name plane1 @depth_enable 0;
> #P window linecount 1;
> #P message 37 174 204 9109513 reset , drawobject plane1 0 ,
> drawobject torus1 0;
> #P newex 27 198 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
> group1 @automatic 0;
> #N vpatcher 25 70 242 240;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 0;
> #P newex 71 97 35 9109513 s draw;
> #P window linecount 1;
> #P newex 50 50 53 9109513 t b b erase;
> #P inlet 50 30 15 0;
> #P outlet 92 74 15 0;
> #P outlet 50 74 15 0;
> #P connect 2 0 3 0;
> #P connect 3 0 0 0;
> #P connect 3 1 4 0;
> #P connect 3 2 1 0;
> #P pop;
> #P newobj 29 84 37 9109513 p Draw;
> #P window linecount 2;
> #P newex 73 350 367 9109513 jit.gl.gridshape cap @shape torus @color 1
> 0 0.5 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> @automatic 0 @name torus1 @depth_enable 1;
> #P window linecount 1;
> #P newex 440 262 154 9109513 jit.gl.videoplane cap @scale 2.66 2;
> #P newex 624 153 141 9109513 jit.gl.texture cap @name group2;
> #P newex 454 153 141 9109513 jit.gl.texture cap @name group1;
> #P newex 96 84 65 9109513 jit.window cap;
> #P toggle 29 36 15 0;
> #P newex 29 114 139 9109513 jit.gl.render cap @camera 0 0 4;
> #P newex 29 60 50 9109513 qmetro 30;
> #P comment 161 329 100 9109513 group1;
> #P fasten 6 0 20 2 629 177 473 177;
> #P connect 6 0 25 1;
> #P fasten 19 0 5 0 326 130 459 130;
> #P fasten 19 0 6 0 326 130 629 130;
> #P connect 23 1 24 0;
> #P connect 25 0 20 3;
> #P fasten 24 0 25 0 619 182 487 182;
> #P connect 5 0 20 1;
> #P fasten 5 0 25 0 459 182 487 182;
> #P connect 20 0 7 0;
> #P fasten 22 0 20 0 385 214 445 214;
> #P connect 21 0 22 0;
> #P connect 26 0 21 0;
> #P connect 18 0 19 0;
> #P hidden connect 27 0 17 0;
> #P hidden connect 27 0 11 0;
> #P fasten 9 1 2 0 61 108 34 108;
> #P connect 9 0 2 0;
> #P connect 1 0 9 0;
> #P connect 3 0 1 0;
> #P fasten 19 1 10 0 341 152 32 152;
> #P connect 11 0 10 0;
> #P fasten 19 2 16 0 356 225 31 225;
> #P connect 17 0 16 0;
> #P window clipboard copycount 28;

#81873
Sep 9, 2006 at 11:01am

Theoretically it shouldn’t be, but it looks like it might be. It’ll
probably work with Jitter 1.5.3 on PPC as well.

wes

On 9/9/06, evan.raskob [lists]

wrote:
> is this patch jitter 1.6 only?
> i get these errors when running it (after each single bang):
>
> jit.gl.pbuffer: error setting target context: GL Error: Stack overflow
> jit_gl_begin_capture: GL Error: Stack overflow
> jit_gl_end_capture: GL Error: Stack underflow
> ob3d_draw_end popmatrix: GL Error: Stack underflow
> jit.gl.pbuffer: error setting target context: GL Error: Stack overflow
> jit_gl_begin_capture: GL Error: Stack overflow
> jit_gl_end_capture: GL Error: Stack underflow
> ob3d_draw_end popmatrix: GL Error: Stack underflow
>
>
>
> On Sep 8, 2006, at 11:16 PM, Wesley Smith wrote:
>
> > #P window setfont “Sans Serif” 9.;
> > #P window linecount 1;
> > #P hidden newex 265 162 45 9109513 loadbang;
> > #P newex 380 105 56 9109513 loadmess 2;
> > #P newex 482 190 152 9109513 jit.gl.slab cap @file co.additive.jxs;
> > #P newex 614 98 100 9109513 sprintf read co.%s.jxs;
> > #P user ubumenu 569 77 100 9109513 0 1 1 0;
> > #X add additive;
> > #X add average;
> > #X add brightlight;
> > #X add burn;
> > #X add darken;
> > #X add difference;
> > #X add dodge;
> > #X add exclude;
> > #X add freeze;
> > #X add glow;
> > #X add hardlight;
> > #X add heat;
> > #X add inverse;
> > #X add lighten;
> > #X add multiply;
> > #X add negate;
> > #X add overlay;
> > #X add reflect;
> > #X add screen;
> > #X add softlight;
> > #X add stamp;
> > #X add subtractive;
> > #X prefix_set 0 0 0;
> > #X pattrmode 1;
> > #P newex 380 191 27 9109513 + 1;
> > #P user radiogroup 380 139 18 48;
> > #X size 3;
> > #X offset 16;
> > #X inactive 0;
> > #X itemtype 0;
> > #X flagmode 0;
> > #X set 2;
> > #X done;
> > #P newex 440 220 53 9109513 switch 3 1;
> > #P newex 321 88 40 9109513 t b b b;
> > #P newex 321 65 33 9109513 r draw;
> > #P message 37 232 209 9109513 reset , drawobject cube2 0 ,
> > drawobject sphere2 0;
> > #P newex 26 256 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
> > group2 @automatic 0;
> > #P comment 164 443 100 9109513 group2;
> > #P window linecount 2;
> > #P newex 73 511 374 9109513 jit.gl.gridshape cap @shape sphere @color
> > 0.2 1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> > @automatic 0 @name sphere2 @depth_enable 0;
> > #P window linecount 3;
> > #P newex 73 462 303 9109513 jit.gl.gridshape cap @shape cube @color 1
> > 0.5 0.5 0.2 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> > @automatic 0 @name cube2 @depth_enable 1 @scale 0.5 1 0.5 @blend_mode
> > 1 6;
> > #P window linecount 2;
> > #P newex 73 388 368 9109513 jit.gl.gridshape cap @shape plane @color 1
> > 1 0. 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> > @automatic 0 @name plane1 @depth_enable 0;
> > #P window linecount 1;
> > #P message 37 174 204 9109513 reset , drawobject plane1 0 ,
> > drawobject torus1 0;
> > #P newex 27 198 283 9109513 jit.gl.sketch cap @blend_enable 1 @capture
> > group1 @automatic 0;
> > #N vpatcher 25 70 242 240;
> > #P window setfont “Sans Serif” 9.;
> > #P window linecount 0;
> > #P newex 71 97 35 9109513 s draw;
> > #P window linecount 1;
> > #P newex 50 50 53 9109513 t b b erase;
> > #P inlet 50 30 15 0;
> > #P outlet 92 74 15 0;
> > #P outlet 50 74 15 0;
> > #P connect 2 0 3 0;
> > #P connect 3 0 0 0;
> > #P connect 3 1 4 0;
> > #P connect 3 2 1 0;
> > #P pop;
> > #P newobj 29 84 37 9109513 p Draw;
> > #P window linecount 2;
> > #P newex 73 350 367 9109513 jit.gl.gridshape cap @shape torus @color 1
> > 0 0.5 0.6 @lighting_enable 1 @blend_enable 1 @smooth_shading 1
> > @automatic 0 @name torus1 @depth_enable 1;
> > #P window linecount 1;
> > #P newex 440 262 154 9109513 jit.gl.videoplane cap @scale 2.66 2;
> > #P newex 624 153 141 9109513 jit.gl.texture cap @name group2;
> > #P newex 454 153 141 9109513 jit.gl.texture cap @name group1;
> > #P newex 96 84 65 9109513 jit.window cap;
> > #P toggle 29 36 15 0;
> > #P newex 29 114 139 9109513 jit.gl.render cap @camera 0 0 4;
> > #P newex 29 60 50 9109513 qmetro 30;
> > #P comment 161 329 100 9109513 group1;
> > #P fasten 6 0 20 2 629 177 473 177;
> > #P connect 6 0 25 1;
> > #P fasten 19 0 5 0 326 130 459 130;
> > #P fasten 19 0 6 0 326 130 629 130;
> > #P connect 23 1 24 0;
> > #P connect 25 0 20 3;
> > #P fasten 24 0 25 0 619 182 487 182;
> > #P connect 5 0 20 1;
> > #P fasten 5 0 25 0 459 182 487 182;
> > #P connect 20 0 7 0;
> > #P fasten 22 0 20 0 385 214 445 214;
> > #P connect 21 0 22 0;
> > #P connect 26 0 21 0;
> > #P connect 18 0 19 0;
> > #P hidden connect 27 0 17 0;
> > #P hidden connect 27 0 11 0;
> > #P fasten 9 1 2 0 61 108 34 108;
> > #P connect 9 0 2 0;
> > #P connect 1 0 9 0;
> > #P connect 3 0 1 0;
> > #P fasten 19 1 10 0 341 152 32 152;
> > #P connect 11 0 10 0;
> > #P fasten 19 2 16 0 356 225 31 225;
> > #P connect 17 0 16 0;
> > #P window clipboard copycount 28;
>
>
>

#81874
Sep 9, 2006 at 2:32pm

#81875

You must be logged in to reply to this topic.