hello,
a MSD link in pure vanila pd, that would be awesome!
i had the same problem when doing the PM on a GPU shader.
the solution was to hard coded the link topology in the shader.
so it does not help you to create a generic solution...
for physigs i think the solution is the look at the problem the other way
around.
do not have link oriented table, but mass oriented.
i.e :
if you wish to connect masse 22 and mass 33 , you have to create a conection1
table that could have 33 in the index 22 and 33 in the index 22.
then sending connection1 to a code that compute the link.
you can have an other table to compute a 2nd link with other parameter.
all of the links contribution will then be summed with a simple "+~"
of course this is very inefficient if you have 10000 masses and 2 links, since
you have to compute forces for all masses. but if all mass n are connected to
mass n+1, then all link can be computed in only 2 times.
the only optimisation you're missing is that F(1->2) = -F(2->1), so you have to
compute 2 time the same link.
but this is negligible regarding to the performance boost you'll get...
do you understand my point, and do you think it can be done?
Cyrille
Le 09/07/2010 18:32, Frank Barknecht a écrit :
Hi,
On Thu, Jul 08, 2010 at 10:21:52AM +0200, cyrille henry wrote:
i haven't tested physigs yet (i probably missed the announcement), but
it look great.
but why would link has to be computed in message?
it is look very unoptimized...
Yeah, it's the main drawback. Without this fallback, [physigs] would
beat pmpd to pieces and be as fast as MSD. ;-)
But I really hammered by head to my table many hours to find a way to
compute links in DSP using only vanilla objects, and I could just not
find one. I would love any suggestion how to fix that.
The main problem is the execution order of DSP objects per block. It is
not possible to refer to samples calculated later in the DSP chain in
earlier objects. ([rpole~] is an object that became necessary because of
this restriction in Pd and systems with a similar architecture.)
As links may connect more than one mass point, the forces of all links
on a particle have to be accumulated to the table holding the
accumulated particle forces. Currently all links forces are calculated with DSP
(or "BSP" as I call this process in the paper) and their forces are stored in a
table "link-forces". The index there refers to the link, the value is
the force.
Other tables map all links to masses on both ends. Tables link-m1 and
link-m2 hold mass-ids as values, the indexes into the table (x-value)
again refer to the link-id.
To add up all link forces for a single mass, I would have to walk
through these links-table, lookup all link-forces connected to this
mass, and sum these forces. I didn't manage to do this in a single DSP
block so I did it with messages. :(
I my paper I still hoped to be able to solve this with a [tabwriteat~]
or [tabpoke~] object that is the signal-equivalent to [tabwrite] for
messages, but I later found that it wouldn't help.
Again, any suggestions to optimize this are more than welcome!
Ciao
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
