Pretty hawt.

What integration method did you use to calculate? Euler? Verlet? Runge-Kutta? Is the cloth handling internal collisions?

A REALLY sweet feature would be to automatically switch between these, sort of a intregrate(VERLET) syntax.

pretty sweet toolkit you got going there. I'm curious.. what is "abstract" when you write that before "class"?



Yes. Fluid sim would be very handy, like being able to define a box-range for a fluid field, then define the viscosity and such.

Looking at your code... every mass and force is registered to a Physics class and is updated thru it? Pretty good idea!

Torque would be extremely handy. As well as surface friction (non linear friction?)

Keep it up :] This is awesome.


PS: you're from carnegie mellon. do you know of a programmer named Eugene? He's korean, kinda chub (haven't seen him for like 6 years though...) and a very good GL programmer.

(i) I just used simple euler integration, since it's quick and doesn't require two-steps to start.  Runge-Kutta's only second-order, so I don't think the improvement would be very much, since the time-step is processing's framerate.  Vertlet isn't so hot for kinematics in processing, because the framerate usually varies, and that messes things up.

(ii) Abstract classes are like partially implemented interfaces.  You can have a reference to an abstract class, but you can never instantiate one.  You can write constructors, however, and call them in it's descendents with "super" like in any other class.  I use it to define all methods and protocols common to any force (and avoid redundant coding).  This does require java to use it's type-checker, though, so it reduces performance.

(iii) So far my roomate tells me that fluid sims would require a node per pixel, which is kind of ridiculous at present.  I'm researching a better model at the E&S library right now with little success.

(iv) I want torque too, but I'm trying to think of how to implement it.  I think I need a Lever class that is represented by a static node and a dynamic node that rotates around it.  Then forces could either be defined on the whole bar or at a point, openning up the possibility of making spring loaded puppet arms with their spring properties key-framed

(v) Sorry, I don't know any Eugenes.  Pretty much everyone is a programmer here.

(vi) Quaternions would be easy.  I wanna hold off on last-minute gift ideas and flesh out the whole skeleton of the package first.

My ultimate goal is to have a kinematics package to work in tandem with my keyframing class (http://andrew.cmu.edu/~mwkaufma/gob2) and my obj loading class to make animating natural motion simple, and then make MEL bindings for Maya.

On the fly (though not necessarily in real-time).  I'm modelling an animated scene not as a series of images, but instead as a collection of parameters that change over time according to functions.  Programming kinematics moves much of the burden of defining those functions to the computer, so I have to key fewer parameters by hand, and let the rest react to my input, like a signal response.