Hi, Yep, list parsing is probably the issue. Without the snapshot trick, every render frame sends data requests to the [timbreID] object, and lists are output in response. Those lists have to be parsed to get the coordinates for points. That's the price for storing/manipulating all the analysis data in [timbreID], but you could definitely do everything it does internally via patches, and then have more flexibility. Or you could still use [timbreID], but do all the data requests in advance and store the results in tables.
On Sun, Sep 2, 2012 at 12:23 PM, Cyrille Henry <[email protected]> wrote: > hello, > > the repeat/gemlist trick is very fast. it can be used to render lot's more > point in real time. > (try pmpd example 57 : 2000 points are rendered at 50 fps on my computer > with no problem) > > i suspect that the bottleneck is the list parsing. > one trick to speed this is to put the list in a table, and use tabread to > access the data. > (i did not have a look a the patch, so i may be wrong). > > cheers > c > > > Le 02/09/2012 18:01, Max a écrit : > >> hi list, william, >> >> this is a Gem recursion and glsl question. >> in the example patches for timbreID there is an interesting patch where >> the grains of a sample can be seen as a point cloud according to their >> parameters. this is done by parsing a long list for each point throuch a >> recursive gem chain using [zexy/repeat] it works very well up to 40 points >> (or a sample of up to 10 seconds). However, when you try to do this with a >> sample of 4.5 minutes it doesn't work any more because the list parsing and >> gemlist repeating for each and every point (then about 900) at framerates of >> 10 fps is to heavy on the CPU. >> William resolves this by rendering it once and taking a snapshot of the >> scene. that works nicely, but is not an option for my work, as i want to see >> the 3d space and navigate in it real-time. I was wondering if this could be >> done more efficiently and where to start. I think the points should be >> rendered in a glsl environment and the list of every points position should >> be static (in a matrice?) and not called and parsed by [list] objects at a >> rate of >9000 times per second. Unfortunately the geometry shader example >> doesn't work here, i was hoping to get some clues from there. >> >> william has a tiny image of a point cloud on his page: >> http://williambrent.conflations.com/pages/research.html#timbreID >> >> max >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
