[PD] pointcloud in Gem (timbreID) and performance

[William Brent]

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