[jit.phys] why does the ball sometimes go through my surface?

Oct 1, 2012 at 4:02am

[jit.phys] why does the ball sometimes go through my surface?

thought I’d try some jitter physics stuff after looking at the latest patch-a-day examples.
i’ve tried to do something very simple, which is mostly made up of bits of tutorial patches, help files and other resources stuck together.
I made a corrugated surface, using jit.expr into jit.phys.body, which a ball can bounce around on, but often the ball falls through the surface instead of bouncing off it. Increasing the mesh density doesn’t seem to help. There is probably some obvious mistake, given I’ve never used jitter for anything 3d before. feel free to point out any conceptual errors that may be evident in how i’ve patched this together… thanks

– Pasted Max Patch, click to expand. –
#64560
Oct 2, 2012 at 3:05am

Hi Terry,

You will probably want to use @shape dynamicmesh on the corrugated plane body.

Does that help?
-Ben

#232963
Oct 2, 2012 at 4:27am

thanks a lot Ben, works a treat now.

another question: how can i get the coordinates of each time the ball strikes the surface, and the ball’s instant velocity (so I can map that to pitch, loudness etc).

Thanks
-T

#232964
Oct 2, 2012 at 5:13pm

Hi Terry,

You will want to explore the @collisions attribute of jit.phys.body. Take a look at the example in Max6/examples/jitter-examples/render/physics titled phys.body.collisions.maxpat. Velocity is an an attribute of every jit.phys.body, so you can just query that with a ‘getvelocity’ message. There is also an example of that, phys.body.velocity.maxpat.

Have fun!
-Ben

#232965
Oct 3, 2012 at 10:58pm

Thanks again Ben, but now I have another question–

OK, so I have made multiple version of my bouncy balls, ie [jit.phys.multiple 7 @name balls....], and encapsulated it with all the controlling matrices and related gl objects just to clean it up a bit.

It works fine, except the floor body that the balls bounce off [jit.phys.body @name floor....] does not report collisions in the same way, now that the “balls” generating part is in a subpatch and apparently hidden from the “floor” part. It replaces the names “balls_0″ … “balls_n” with a generic name that is no good for parsing with regexp.

So my question is do the different interacting elements need to be in the same parent patch? Is there a simple way around that?
I can post the patch but it’s pretty messy right now. Any suggestions?

T

edit: btw thanks for pointing out the example patches– I didn’t actually know they existed…

#232966
Oct 3, 2012 at 11:09pm

Hi Terry,

As it is now, with jit.phys.multiple, you will have to do some tricky business with extracting the matrix position out of the name that is generated. You should be seeing something like ‘u870000345_6_1 or something. the 6_1 part of it is kind of the ‘id’ of an instance of the multiple body. I think I have a patch around that parses this all out, I’ll post it if I can excavate it.

-Ben

#232967
Oct 4, 2012 at 12:14am

Hi Ben,

you said:
“You should be seeing something like ‘u870000345_6_1 or something. the 6_1 part of it is kind of the ‘id’ of an instance of the multiple body.”

Yes I am seeing that, but it _should_ be ‘balls_6_..’ because the jit.phys.multiple is named ‘balls’. But if it’s encapsulated in a subpatch the collisions are reported differently. Just wondering how to get around that, given the generically generated ID is unpredictable.

This is how I parse it:

– Pasted Max Patch, click to expand. –
#232968
Oct 4, 2012 at 3:17pm

hi terry. i’m not sure what this patch you posted is demonstrating.

there should be no problem having a named phys.body or phys.multiple inside a subpatch.
make sure you re-instantiate the named object (or close and reopen the patch) after encapsulating.

– Pasted Max Patch, click to expand. –
#232969
Oct 4, 2012 at 11:07pm

thanks Rob– that bit of patch was just showing how I’m doing the collision detection.

I think I had the patch hidden but open for the past day or so, so I closed the patch and reopened it and it now works as expected. Thanks again.

#232970

You must be logged in to reply to this topic.