We hope that you will find something interesting in each of these posts, and that it opens your mind to some of the options provided by the physics system. If you have a comment, please feel free to post it here. If you find a way to improve a patch, post it and share. We want this to be a conversation, and that requires your input!

So enjoy the series (which will continue through September 28), and spend a little time with the physics engine – we think you’ll find it worthwhile.

[ddg]

The patch demonstrates the use of jit.phys world dictionaries, which contain all the data necessary to detect collisions, and even to determine when objects collide for the first time (think of it as a sort of equivalent to “debouncing”).

The interesting twist on this patch is that it contains a set of 3d LFOs controlled using standard ITM objects. These x/y/z vectored LFOs run quietly in the background as the spheres drift and interact and let you “teleport” them – that is, move them immediately to the location specified by the 3d LFO at a time interval you choose. Whenever the spheres are teleported, they move immediately to their new location and continue with their original momentum for interesting results.

Of course, this patch can be modified to do all kinds of other things. It just felt like a pentotonic tune kind of day here. Beam me up/sideways, Scottie!

the patch works fine, but … I have strange error messages in my max window :

freeobject: 892a058: bad object
zgetfn (nextrecord): corrupt object
zgetfn (clear): corrupt object
zgetfn (nextrecord): corrupt object
freeobject: 892a8a8: bad object
freeobject: 8929290: bad object
freeobject: 892a2d8: bad object
freeobject: 8928138: bad object
freeobject: 892aa70: bad object
freeobject: 89262f0: bad object
freeobject: 8928b38: bad object
freeobject: 89289d0: bad object
freeobject: 892a6e8: bad object
freeobject: 8929f30: bad object
freeobject: 8925170: bad object
freeobject: 892a638: bad object
…

(lattest max 6.0.7, macOs 10.7.4, macPro, …)

these errors apparently come from the second dict.iter (the one after zl.slice) in color-collision patchers ;

..bug report ?

Mathieu

[attachment=204007,4418]

1. Machine
2. OS Version
3. Version of Max you’re using

Thanks.

Thank to you !

mathieu, thanks for the report, and for narrowing down the offending objects.
i can reproduce and will investigate.
these should not keep the patch from functioning.

I see this from time to time. The pervert nature of Max.

nice piece staccatissimo pianissimo, molto generativo! bravo!

for today’s patch-a-day, we’ve got a fun demonstration of constraints between rigid-bodies, and enabling motors on those constraints.

the patch creates a structure of 5 rigid-bodies, held together with hinge-constraints. i’m calling it a racer.

the racer has 1 main body shape and 4 “limbs”. each limb is constrained to the main body with a hinge constraint, and each hinge constraint is motorized, allowing the racer to travel across the ground. the limb objects are each stored in their own bpather, found on the right side of the patch.

the ground (contained inside the “ground” sub-patcher) is made up of some static bodies (bodies with @mass 0). jit.phys.multiple is used to give some random obstacles to the ground.

the camera view can be controlled (via jit.anim.drive) by dragging in the window with the mouse, and pressing the w,a,s,d,q,z keys.

when you first start the patch, the racer’s main-body has @kinematic mode enabled, causing it to remain in place (rather than fall to the ground from gravity). this allows you to adjust properties of the body, limbs, and hinges, without the racer bouncing around in the world. once you’ve adjusted those properties, you can disable kinematic mode to see your racer in action. the patch comes with two presets for different body, limb, and hinge properties. the first preset sets up the limbs more as legs, and the second preset sets them up as wheels.

you can now propel the racer forward (or backward) by enabling the limb-hinge-motors (motorvelocity and motorstrength). what tends to happen at this point is the racer tips over, so we want to add another constraint to the main-body, using the jit.phys.6dof, to prevent this. the 6dof constraint is adjusted so that there are no limitations on linear movement (the lowerlimit_lin values are greater than the upperlimit_lin), allowing the body to move anywhere in the world. the only thing we constrain is the angular orientation of the body, thereby preventing the tip-over. as a side-effect, we can now adjust the racer’s direction by adjusting the world-space y-rotation of this “up” constraint. the patch allows you to use the up and down arrow keys to adjust the motorvelocity and left and right arrow keys to adjust the constraint y-rotation, thereby driving the racer.

as a last bonus, a javascript file can create some opponent racers, using the same basic structure in the main patch, with some randomness applied to certain properties. this demonstrates how physics and gl objects can be managed via javascript.

if you are feeling mirthful, comment out the lines of code that add the “up” constraint, and watch hilarity ensue as the little guys struggle to cross the terrain.

happy racing!

I’m exploring the jit.phys.multiple system, and particularly the use of constraints and impulses within the multiple set. My first patch – AngryHuddle – I pay homage to the complete anarchy that has become of the NFL (National Football League) with the use of replacement referees. Not only are players fighting their opponents, but they’ve begun fighting each other as well. I’ve created a simple “huddle” of 11 spheres, each constrained to an overhead 6dof that keeps them in place, with impulses that cause them to “knock heads” every once in a while.

Two important points in this patch: first, the use of the @name attribute to give names to the individual bodies that are then used by the jit.phys.6dof object. By giving the name “hangers” to the multiple set, I can access bodies with a ‘hangers_n’ name, where n is the body number (starting at 0). If I was using a 2-dimensional array for multiple setup, I would use ‘hangers_x_y’ to access the row and column of the multiple set. This gives me the ability to directly access the individual bodies by my constraints.

The second interesting feature is the use of a force matrix to impulse individual bodies. This is done by creating a matrix with a single force entity, then turning it off (by zeroing out the matrix) 100 ms later. In this way, I can have the random objects properly select and pulse one of the objects, rather than impulsing them all (which is what happens when we sent an impulse message to the jit.phys.multiple).

The jit.phys.multiple can also have an embedded constraint, where these constraints are automatically connected from body to body within the multiple set. With his permission, I am including a patch by forum user matmat (Mathieu Constans): the NurbsSheet patch, which shows a simple use of 6dof constraints within the multiple set, and using nurbs rendering to create a cool, smooth sheet-in-the-wind model that is mesmerizing to watch. You can see how using a multiple-constraint makes patching a lot simpler; as long as body-to-body constrains are what you want, you will find it much easier to accomplish using the built-in multiple mechanism.

Enjoy the patches, and enjoy the series!

[ddg]

The set up for this patch is that there are four “force points” in a diamond shape. These are jit.phys.ghost objects. They can be attractors or repellers. Then, in the middle, there is a moveable force point, which is a combination of a jit.phys.body and a jit.phys.ghost. This gives the effect of having a body which also can attract or repel. The functionality is achieved by using the ‘kinematic’ attribute of the jit.phys.body, and handling all of the positioning of the object (and force), by mouse tracking in the jit.window. A jit.gl.sketch object is used to visualize the center ghost/body position.

The “particles” are all handled by the combination of jit.phys.multiple and jit.gl.multiple. In this patch, there are 400 bodies generated, and their color, torque, scale and mass are all generated by a single jit.noise object. The random matrix is then scaled by the use of jit.expr objects. Another even easier way to do it is in jit.gen, where you have the ‘scale’ operator. Depending on your computer, you may have to alter the amount of bodies to maintain smooth performance.

Try changing the central_force of all of the jit.phys.ghost objects. Positive repels and negative attracts. Setting the central_force to 0 effectively disables the ghost force. Sending central_impulse messages to the ghost objects create single shockwave-like forces through the physics world. Move the central “Moveable Force” around by click-dragging in the jit.window. See how the spheres are colliding with it, but also attracted or repelled.

This is just the tip of the jit.phys iceberg, so experiment and enjoy!

[attachment=204297,4433]

-Ben

Another question tough: With the 400 objects and a central force applied to the ghosts my framerate drops below the 20 fps.
So every single ghost with a central force costs 3-4 fps.
However if I set the central force to 0 it goes back to 30fps (while the objects still move around).
I am curious. Is it that much more “heavy” to calculate constant forces?
Is that because the “force” gets weaker the further away the objects are from the emitter?

Thank you all for those cool patches!

for today’s patch, i wanted to demonstrate how we can use jit.phys.multiple with jit.path and jit.gen, to simulate bodies in a vortex or tornado.
disclaimer: in no way is this simulation intended to be scientifically accurate.

so what kind of forces are involved in this?
well, first a tornado has a long spiral shape, and objects are pulled along the shape of the spiral. and second objects are sucked upward into the spiral shape.

to create a spiral, the patch uses jit.expr and jit.path. i simply copied the jit.expr from the jit.gl.path help-file, and slightly modified the expr. i then used the “outputeval” message to jit.path to send a matrix containing the path points to a jit.gen.

the jit.gen simply takes the path matrix, and the phys.multiple position matrix, and tries to find the closest point on the path to each body. a jit.gen attribute @steps will determine how many path-points are iterated to find the closest. the more steps, the more cpu is consumed. once the closest point is found, a tangent is calculated by subtracting the previous path point from the current. this tangent will pull bodies along the path, so in order to pull bodies toward the path, we mix the tangent with the distance from the body position to the path point (adjusted by the jit.gen @fade attribute).

that’s it! the force matrix is then sent to phys.multiple to apply the forces to each of the bodies. we also send the force matrix to gl.multiple color matrix, mainly for debugging. there is also a jit.phys.ghost that can be enabled to add more forces to the equation.

the real fun happens when you interpolate between presets, so a pattrstorage is provided to get you started with that.

[attachment=204485,4441]