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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list