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