[PD] pointcloud in Gem (timbreID) and performance

[Cyrille Henry]

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
>