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
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 02.09.2012 um 18:23 schrieb 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)
ok, good to know. by the way: the examples in pd-ext go only until 51, but i found the others (not there: drpichon.free.fr/pmpd/ google top result) but http://www.chnry.net/ch/?081-pmpd
i suspect that the bottleneck is the list parsing.
i see.
one trick to speed this is to put the list in a table, and use tabread to access the data.
to you know how tables compare to iemmatrix? the advantage of a matrice would be that i can get a whole row at once.
(i did not have a look a the patch, so i may be wrong).
i'll try.
thanks cyrille!
max
Le 02/09/12 18:45, Max a écrit :
Am 02.09.2012 um 18:23 schrieb 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)
ok, good to know. by the way: the examples in pd-ext go only until 51,
yes, i always forget that pmpd in pd extended is very outdated.
but i found the others (not there: drpichon.free.fr/pmpd/ google top result)
wow, I did forget this page still exist. i should remove it.
this is only updated about once a year. latest dev are only on pd svn.
i suspect that the bottleneck is the list parsing.
i see.
one trick to speed this is to put the list in a table, and use tabread to access the data.
to you know how tables compare to iemmatrix? the advantage of a matrice would be that i can get a whole row at once.
on my experience, i would say that list are slow, table are fast. iemmatrix sends list, but process them in C, so i don't know.
cheers c
(i did not have a look a the patch, so i may be wrong).
i'll try.
thanks cyrille!
max _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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
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@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@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
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
-
Cyrille Henry -
Max -
William Brent