Forums MaxMSP

jit.phys.world – Difficulty with Collision Data


kski

kski
Dec 3, 2013 at 9:12pm

jit.phys.world – Difficulty with Collision Data

Hey all,

I am experiencing difficulty parsing and efficiently getting data from my jitter system. I currently have 32 objects in a world and am trying to get the collision data out in a more manageable form (such as o dot). One difficulty that I am having is when I choose to output collision data my jitter program seems to drop frames (stutters) and becomes less fluid in drawing the animations. With fewer objects this does not occur however I am wondering if this has to do with available ram (and computer hardware) or if Max is the issue. (One last hypothesis of mine is that the slowdown is due to printing the dictionary data). My other difficulty has to do with how to parse the collision data as it is in Dictionary format. I am not too familiar with this however I have learned that goes something like this.

collisions -> dictionary, “object 1″_”object 2″ -> dictionary, “position” “normal” “contacts” “duration” “impulse” “body1″ “body2″

I am not sure how to parse this data without routing each individual permutation of collision objects (which will be 7 (for last dictionary parameters listed above) * 32 (# of objects) + 6 (# of walls of a cube) = 266 number of times I will have to utilize route). If someone has delt with these issues before I would greatly appreciate some feedback on how one might approach these problems.

Here is the portion of my patch that is giving me the most difficulty.

– Pasted Max Patch, click to expand. –
#274658

Rob Ramirez

Rob Ramirez
Dec 4, 2013 at 10:51am

can you repost your patch using copy-compressed. it’s not working uncompressed.

without seeing the patch, i can say that if you’re using a dict.view or dict.print, it will greatly impact performance.

here’s a little abstraction to help your detect collisions for specific named bodies.
if you need something more complex, javascript is a good solution.
in this case, check out the following example:
Max 6.1/examples/jitter-examples/render/physics/phys.world.collisions.js.maxpat

— save as “pdict-route” —
<code>

– Pasted Max Patch, click to expand. –

</code>

example usage:
<code>

– Pasted Max Patch, click to expand. –

</code>

#274721

kski

kski
Dec 4, 2013 at 11:18am

Ah naming bodies really helps to understand what data is being reported! Now that I understand what is being outputted I now want to route that data out in a more manageable way (using o dot). Here is my compressed code (hopefully this works better).

<code>

– Pasted Max Patch, click to expand. –

</code>

#274726

kski

kski
Dec 4, 2013 at 11:32am

Also thanks for your example! I really appreciate you helping me out. I am a little confused how you parsed the data in pdict-route. If you could explain a little how you went about to making that sub-patch I would greatly appreciate it.

#274728

kski

kski
Dec 5, 2013 at 6:24pm

I feel like I have exhausted all my options on trying to get collision data out from a multi-object system. Trying to work with dict formatted data with more than 5 objects just gets ridiculous and taxing on the system as you try and access all the available data. As such, I have tasked myself to develop my own collision collecting system just biased off of 3d position data. If anyone has any suggestions on how to optimally get data out of multi-object systems from jit.phys.world please feel free to comment on this thread. Frankly, I’m kind of disappointed in the output formatting of the collision data and would love to see this better executed (o dot would be great).

If anyone would like to see my attempt at parsing the collision data take a look at the patch below. Please note that in order for the last sub patch to make sense you will need o dot externals from CNMAT (http://cnmat.berkeley.edu/downloads) Also note that since my system was a 32 body system I had to iterate this patch 32 times and change the o dot variables for each iteration. Lastly, I combined them all together into one o.message however the load to do so was too taxing on my system.

– Pasted Max Patch, click to expand. –
#274911

Rob Ramirez

Rob Ramirez
Dec 6, 2013 at 12:20pm

first thing is to get rid of all those message boxes that you’re sending the collision data into. not only will that greatly impact performance, but you will bloat the symbol table unnecessarily.

if have no idea what o.dot is or what you need the collision data to do, but as mentioned, if you want to manage multiple collisions javascript is probably your best bet.

the abstraction i posted uses regexp to match a specific named body, and if it finds a match will output the collision info. if you’re interested in collisions with walls, make 6 instances, giving each one the specific wall-name as an argument (wallbody0 … wallbody5). each frame, if there’s a collision it will output the data for each collision.

without knowing what specifically you want to do with this data, i can’t really offer more advice.

<code>

– Pasted Max Patch, click to expand. –

</code>

#274983

kski

kski
Feb 12, 2014 at 12:38am

Wow! This works fantastic! I have only one big issue now. This works great if I don’t have any “ghosts” (jit.phys.ghost) however when I do add them (they provide force fields to move the cubes around) the patch “pdict-route” is constantly responding. I am having difficulty not including these objects in the collision data or perhaps parsing them out of the final dict.iter? The objects that I wish to not include are named “SmallForce”, “LargeForce”, and “SphereForce.” Any ideas how to change “pdict-route” to accommodate this? Thanks for your help, I really appreciate it.

#280821

kski

kski
Feb 12, 2014 at 12:48am

Ah, I think I figured out how do achieve this. All I did was chain regexp “SmallForce”, “LargeForce”, and “SphereForce” together each connected by the “unmatched” outlet. I will leave an example here.

– Pasted Max Patch, click to expand. –
#280822

You must be logged in to reply to this topic.

Forums MaxMSP