Week 8 - Class 1
We will not be using fixtures in this class. Rather, I will have you 'patch along' with me during the lecture.
We can use the jit.world as a tool for building a physical world for OpenGL objects. To do this, we need to make only a few changes:
First of all, we have the whole section around the "worldbox" message - this is where we interact with the physics engine that is embedded in the jit.world, and tell it what we want. In this case, we tell it that we want to build a psuedo-physical "box" around our physics world, meaning that items will remain inside that area. In order to see the worldbox, we create a jit.gl.physdraw object, which shows us the edges of our box.
Also note that our camera position is now at Z=20, which is much farther away than normal. We do this because our worldbox uses larger extents (in order to give room for physical activity), and we need to pull the camera back in order to see everything.
In order to create items in our world, we need to make a gridshape, then connect a jit.phys.body to the gridshape. When we make this connection, you can see the resultant 'physical' action in the shape.
Notice that about the only thing that I have to add to a jit.phys.body object is a shape that (roughly) matches the gridshape. Note that there are some gridshapes (particularly the torus) that have no matching body shapes, so you sometimes have to compromise.
Once you add the body, the gridshape drops to the ground - because it is being controlled by the body object. You will now find that there are many settings (such as position, scale and rotation) that are not allowed on the gridshape; if you want to change these, you have to change them at the body, then allow it to morph the gridshape into compliance.
Next, if we add another object to the world, we can see that they can start to interact. By adding a jit.phys.picker object, we can directly move the items within the window to move the objects:
Moving things around in a physics world is a little different that we've done to this point. In the past, if we wanted to move something on-screen, we would decide on the X/Y/Z location we want to move to, then get the object there. In a physics world, you have to "let go" a little - you set the situation, then allow the object to move (or be moved) as necessary by gravity, collisions and other forces. If you want to programmatically force an item to move, you can 'pulse' the object with an impulse message. This uses an X, Y and Z amount to determine the direction of the pulse:
Using the physics world embedded in the jit.world can be a little limiting, because you have to do everything with messages sent through a "sendphys" method. If we go a little 'old-school' with the creation of jit.gl.render and jit.phys.world objects, you will have direct access to the details, including how gravity works:
-9.8 is a standard Earth-like gravity pull, meaning 9.8 m/sec2 acceleration in the negative (downward) direction. Reducing that - or even inverting it to a positive-direction gravity, produces interesting (and sometimes disturbing) results!
Now, we can add some programmatic behavior to the individual objects in order to see the items 'dance' throughout the space:
For more about the Max Physics engine, I encourage you to go through my friend Les Stuck's Physics Tutorials on the Cycling '74 site. The information you get there, in combination with these test fixtures, should help you get started with the Max physics world.
- Using the concepts in this lecture, create a multi-object system that runs itself to create an interesting 3D environment. Show it to me before you leave for the evening.
Week 8 - Class 2
We need to watch a video...
We are going to look at a few details surrounding information that you should have gotten from the Les Stuck videos. The first thing is the decoding of the dictionary content found in collision information. An example patch is found in this file.
Collisions contain a lot of detailed information - much of it is a pain in the neck to access. In this example, I provide some shortcuts that allow you to more easily access collision info:
If you run this patch, you'll see that it randomly pushes the sphere around, but it also does something else - whenever it hits a wall, it pushes off in the opposite direction. This is done by watching for wall impacts, then forcing an impulse in the opposite direction.
You can see that we have collision tracking turned on for the jit.phys.world, and that we are watching the output of the world. From there, we look for collisions, then I have a subpatcher that turns collision dictionary data into a self-documenting list. From there, I look for specific 'wallbody' activations, and send impulses from there.
The constraint system provides a number of different ways to connect items together - or to connect items to a point in space. The video explained constraints (especially the 6dof constraint) well; but it helps to know all of the available constraints. They are:
- jit.phys.6dof - six degrees of freedom (or constraint)
- jit.phys.barslide - slide along a constraining bar
- jit.phys.conetwist - limit the twist/spin of a connection (think of your shoulder)
- jit.phys.hinge - a prototypical hinge constraint
- jit.phys.point2point - a dual-point connector/constraint
- Each person will be given a topic (either collisions or one of the constraints), and will provide an example patch for its use. You will show this to the rest of the class, describe why it is important, and how you can use it for useful work.
Return to the class index.
Last update: 05/10/2016