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!
Frank