hi all
it's a known trick to use [repeat] from zexy in a gem render chain to
produce funny effects and to multiply the rendering of the attached
objects.
the problem i have here, is that i use a [repeat] with a very high
iteration number (>1000). after the [repeat 1000] some stuff is
calculated and read from tables and then sent to gem-objects on each
iteration. this works well, but on each render-cycle i get a short
dropout. i use the default framerate of 20, that should make 50ms per
frame, but with [realtime] i measure around 70ms. i could live with
that, but i thought that this could be optimized.
it's the concept of pd, that when a message is triggered, it gets
completely processed in the same dsp-cycle. but when working with gem,
this makes absolutely no sense, since the time between each render cycle
is much higher (50ms in my case). that's why i wanted to build a slow
repeat with [until] and [list], so that i can spread the 1000 iterations
over the whole 50ms. unfortunately it is not possible to store a gem
pointer with [list]. when i connect a [gemhead] to the right inlet of a
[list] and turn rendering on, pd immediately crashes (at least here, i
didn't test on other computers).
i tried also to bang 'manually' the [gemhead] instead, but then the
iterations don't have any effect (no objects are multiplied).
is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash.
cyrille
Roman Haefeli a écrit :
hi all
it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (>1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers).
i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied).is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
___________________________________________________________ Der frÌhe Vogel fÀngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a]
| | |
| [del 10] |
| / /
[any ]
as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
roman
On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote:
to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash.
cyrille
Roman Haefeli a écrit :
hi all
it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (>1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers).
i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied).is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] |
| / / [any ]as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
this is not a question of the design of Gem but of openGL. for most objects (but the pix_ stuff), Gem directly communicates with the underlying openGL-infrastructure. for this to work, one must get hold of the openGL context. using delayed gem-messages, the openGL-context will most likely be grabbed by another application.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
on the long run i have plans to put the rendering into a separate thread. however, don't expect it too soon.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
2 ways:
- use longer audio buffers (e.g. 100ms)
- use 2 instances of pd: one for audio and one for video; one of them
(or a third one) is "master" and controls the rest.
mfg.asdr IOhannes
hi IOhannes
On Wed, 2007-02-28 at 14:46 +0100, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] |
| / / [any ]as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
this is not a question of the design of Gem but of openGL. for most objects (but the pix_ stuff), Gem directly communicates with the underlying openGL-infrastructure. for this to work, one must get hold of the openGL context. using delayed gem-messages, the openGL-context will most likely be grabbed by another application.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
on the long run i have plans to put the rendering into a separate thread. however, don't expect it too soon.
hm... i am bit unsure now. chris clepper said in his previous mail, that gem rendering is not bound to the dsp-ticks. but when you say, that threading would help in this case, does that mean, the rendering _is_ bound to the dsp-ticks? do i understand something wrong?
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
2 ways:
- use longer audio buffers (e.g. 100ms)
for some reason, it doesn't help here. it's not the audio i care about, but that timing is lost and the desired frameperiod grows to 70ms. and what is most surprising here, sometimes i close the patch i am working on and open it again and start rendering and for some unexplainable reason: frameperiod is 50ms. this is with the same patch with the same gem-objects in gemwin.
- use 2 instances of pd: one for audio and one for video; one of them
(or a third one) is "master" and controls the rest.
yeah, when i want to do audio at the same time, i'll do that.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hello,
One solution i see to this generic problem is to run 2 pd : 1 for audio and 1 for Gem. this "could" gives better result, but it will not be perfect. an other solution would be to wait until gem run in it's own thread, but i don't think this will be possible in a near future.
last thing i can see is to use buffer 0. you could then bang gemhead when you want. you can't use the any object to delay the end of a processing, but you can start a new one whenever you want. the new processing can continue an old process if you use gemlist info object (to recall last iteration position). (i should have an exemple somwhere if you wish). but with this technique, you will see the image while it's drawing. in order to clear the image, you will need to draw somthing black over the windows, and clear the Z buffer in order to be able to draw anything else (with GEMglClearDepth)
anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card.
don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
cyrille
Roman Haefeli a écrit :
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] |
| / / [any ]as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
roman
On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote:
to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash.
cyrille
Roman Haefeli a écrit :
hi all
it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (>1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers).
i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied).is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is interesting stuff about the innards of GEM.
the new processing can continue an old process if you use gemlist info object (to recall last iteration position). (i should have an exemple somwhere if you wish).
Cyrille, would you please send that patch? It would help my understanding of the discussion tremendously.
~Kyle
On 2/28/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello,
One solution i see to this generic problem is to run 2 pd : 1 for audio and 1 for Gem. this "could" gives better result, but it will not be perfect. an other solution would be to wait until gem run in it's own thread, but i don't think this will be possible in a near future.
last thing i can see is to use buffer 0. you could then bang gemhead when you want. you can't use the any object to delay the end of a processing, but you can start a new one whenever you want. the new processing can continue an old process if you use gemlist info object (to recall last iteration position). (i should have an exemple somwhere if you wish). but with this technique, you will see the image while it's drawing. in order to clear the image, you will need to draw somthing black over the windows, and clear the Z buffer in order to be able to draw anything else (with GEMglClearDepth)
anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card.
don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
cyrille
Roman Haefeli a écrit :
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] | | / / [any ]
as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
roman
On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote:
to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash.
cyrille
Roman Haefeli a écrit :
hi all
it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (>1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers). i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied).
is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
I've never hear of this optimization, do you have an example for it?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
This is an optimization if your geometry doesn't change. A display list loads all of the vertex, color, texcoord and normal data onto the card and then just tells the card to render it right from VRAM. The model object uses display lists for speed. If you need 10,000 cubes it would be faster to make a model of the cube and load it that way.
Cyrille's trick is to set up a render chain and render that once into the display list. After that only the gemhead feeding GEMglCallList is rendered every frame.
On 2/28/07, Frank Barknecht fbar@footils.org wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
don't forget you can optimized your patch with GEMglGenList /
GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
I've never hear of this optimization, do you have an example for it?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Frank Barknecht a écrit :
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
I've never hear of this optimization, do you have an example for it?
here is an exemple that iohannes send to the list time ago.
it should be use like a normal primitive.
cyrille
Ciao
#N canvas 232 98 791 542 10; #X obj 37 279 inlet gemlist; #X obj 37 384 outlet gemlist; #X obj 419 180 inlet size; #X obj 505 180 inlet slice; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f $1; #X obj 347 119 f $2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 37 246 disk 1; #X obj 37 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 173 translate 1 0 0 1; #X obj 37 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 > 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 > 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 2 0; #X connect 1 0 7 0; #X connect 2 0 15 0; #X connect 3 0 20 0; #X connect 4 0 24 0; #X connect 5 0 17 0; #X connect 6 0 21 0; #X connect 7 0 5 0; #X connect 7 1 6 0; #X connect 8 0 2 1; #X connect 8 1 9 0; #X connect 8 2 10 0; #X connect 9 0 15 1; #X connect 9 1 16 1; #X connect 10 0 12 1; #X connect 10 1 11 1; #X connect 12 0 16 0; #X connect 13 0 12 2; #X connect 13 1 11 2; #X connect 14 0 2 2; #X connect 14 1 13 0; #X connect 15 0 12 0; #X connect 16 0 11 0; #X connect 17 0 18 0; #X connect 17 1 20 1; #X connect 18 0 19 0; #X connect 19 0 20 0; #X connect 20 0 8 0; #X connect 21 0 22 0; #X connect 21 1 24 1; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 14 0; #X restore 186 467 pd closedcylinder; #X obj 186 221 GEMglGenLists 1; #X obj 156 398 GEMglNewList; #X obj 37 322 GEMglCallList; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 186 199 pd once; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 156 372 pd once; #X obj 419 201 t b f; #X obj 505 202 t b f; #X obj 235 354 loadbang; #X obj 235 373 GLdefine GL_COMPILE; #X msg 230 178 bang; #X obj 156 488 GEMglEndList; #X obj 156 425 t a a; #X obj 186 446 separator; #X obj 156 113 gemhead 1; #X obj 316 267 t b; #X obj 156 138 t a a; #X obj 286 241 t f b; #X obj 165 268 t f f; #X msg 305 343 bang; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 37 274 outlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f $1; #X obj 347 119 f $2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 67 246 disk 1; #X obj 67 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 131 t a a; #X obj 67 151 separator; #X obj 67 173 translate 1 0 0 1; #X obj 67 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 > 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 > 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 3 0; #X connect 2 0 8 0; #X connect 3 0 16 0; #X connect 4 0 23 0; #X connect 5 0 27 0; #X connect 6 0 20 0; #X connect 7 0 24 0; #X connect 8 0 6 0; #X connect 8 1 7 0; #X connect 9 0 3 1; #X connect 9 1 10 0; #X connect 9 2 11 0; #X connect 10 0 18 1; #X connect 10 1 19 1; #X connect 11 0 13 1; #X connect 11 1 12 1; #X connect 13 0 19 0; #X connect 14 0 13 2; #X connect 14 1 12 2; #X connect 15 0 3 2; #X connect 15 1 14 0; #X connect 16 0 1 0; #X connect 16 1 17 0; #X connect 17 0 18 0; #X connect 18 0 13 0; #X connect 19 0 12 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 22 0 23 0; #X connect 23 0 9 0; #X connect 24 0 25 0; #X connect 24 1 27 1; #X connect 25 0 26 0; #X connect 26 0 27 0; #X connect 27 0 15 0; #X restore 469 494 pd closedcylinder; #X text 346 477 this is a version without the openGL-wrapper; #X text 360 491 it is slower::; #X text 48 21 this is an example of how to use Gem's openGL-wrapper-objects to speed up things; #X connect 0 0 7 0; #X connect 2 0 10 0; #X connect 3 0 11 0; #X connect 5 1 21 0; #X connect 6 0 16 0; #X connect 7 0 1 0; #X connect 8 0 5 0; #X connect 9 0 6 0; #X connect 10 0 19 0; #X connect 10 1 4 1; #X connect 11 0 19 0; #X connect 11 1 4 2; #X connect 12 0 13 0; #X connect 13 0 6 2; #X connect 14 0 8 1; #X connect 16 0 15 0; #X connect 16 1 17 0; #X connect 17 0 4 0; #X connect 18 0 20 0; #X connect 19 0 9 1; #X connect 20 0 9 0; #X connect 20 1 8 0; #X connect 21 0 22 0; #X connect 21 1 19 0; #X connect 22 0 7 1; #X connect 22 1 6 1; #X connect 23 0 13 0;
cyrille henry a écrit :
hello,
anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card.
btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower).
patch to make this is almost the LS demo patch i send to this list few time ago.
ok, i don't make sound with those, but a good graphic card really improve processing speed.
cyrille
don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in :
repeat 1000 [ GEMglCallList
cyrille
Roman Haefeli a écrit :
hello cyrille
thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed.
putting this in the render chain works and gives the expected result:
[t b b a] | / / [any ]
but this makes pd/gem completely stuck:
[t b b a] | | | | [del 10] |
| / / [any ]as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution.
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done.
how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize?
roman
On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote:
to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash.
cyrille
Roman Haefeli a écrit :
hi all
it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (>1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers).
i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied).is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer?
any help appreciated!
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote:
btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower).
hey, soo nice pictures. do you have also a movie of them? wonderfull to see what is possible with gem.
roman
patch to make this is almost the LS demo patch i send to this list few time ago.
ok, i don't make sound with those, but a good graphic card really improve processing speed.
cyrille
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli a écrit :
On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote:
btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower).
hey, soo nice pictures. do you have also a movie of them?
no, they did not really move.
thanks c
wonderfull to see what is possible with gem.
roman
patch to make this is almost the LS demo patch i send to this list few time ago.
ok, i don't make sound with those, but a good graphic card really improve processing speed.
cyrille
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Feb 28, 2007 at 05:15:32PM +0100, cyrille henry wrote:
anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card.
btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower).
Awesome!!!
Chris.
chris@mccormick.cx http://mccormick.cx
-
chris clepper -
Chris McCormick -
cyrille henry -
Frank Barknecht -
IOhannes m zmoelnig -
Kyle Klipowicz -
Roman Haefeli