[PD] get the position of the mass in the same order than the creation with MSD

[cyrille henry]

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