[jit.phys] why does the ball sometimes go through my surface?
Oct 01 2012 | 4:02 am
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
- Oct 02 2012 | 3:05 amHi Terry,You will probably want to use @shape dynamicmesh on the corrugated plane body.Does that help? -Ben
- Oct 02 2012 | 4:27 amthanks 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
- Oct 02 2012 | 5:13 pmHi 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
- Oct 03 2012 | 10:58 pmThanks 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?Tedit: btw thanks for pointing out the example patches-- I didn't actually know they existed...
- Oct 03 2012 | 11:09 pmHi 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
- Oct 04 2012 | 12:14 amHi 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:
- Oct 04 2012 | 3:17 pmhi 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.
- Oct 04 2012 | 11:07 pmthanks 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.
