[PD] pointcloud in Gem (timbreID) and performance

[Max]

Hi,

Thank you all for the suggestions. ♥ ♥ ♥
I did the later, all xyz spacial and rgb color data is now stored in tables and it works much better all-though the sound is still a little glitchy. All the lists are retrieved one time when the plot button is banged. I'll investigate the glitch tomorrow.
if anyone wants to give it a try, it's in the 08-timbre-space folder and needs pd~ for the Gem subprocess, so no MS-win.
https://github.com/mxa/timbreID-examples
You'll need a Kinect and Synapse for the whole fun. Samples up to 4,5 Minutes long and 7000 tID units are loaded. 

m.

Am 03.09.2012 um 17:41 schrieb 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