Well, creating a joint that fix an object in a 2D plane isn’t a good idea, because it imply more computations for a simpler thing. For stopping rotation, a “code unplug” would be feasible, but for constraining in a 2D plane, I don’t see how this could be easily done, since it’s in all the computations formulaes.
Oh right… I do see what you mean and it is technically feasable. After the calculations are done after stepping a method is called named stepBody or something. Its the bodies responsability to actually take the results from the LCP algorithm and add it to its angular and linear velocity. So… I spose if it just ignored it… No wait… We have still wasted computations in the step bit… Still it probably complicates things a bit less for the LCP algorithm by one less constraint (the joint) being present.
Yeah. So a subclass of Body can over ride the stepBody method and ignore certain parts of the calculations. And make sure it never ends up with a linear velocity in one direction or whatever. My ownly concerns is that a joint or someting might go crazy trying to compensate but they way I have it working in my head at the moment I don’t think it can do that. Hmmmm. Interseting.
The thing I liked about doing it with joints though is that you could define the plane of movement. If you just ignore one coord, as in the idea above, you are limited to movement in axis aligned planes. OK if your whole game is 2D but not the flexability I crave :o)
If you really wanted the system to be pluggable, then I suggest that bodies would throw a step body event and do nothing by default. It would be the responsability of (bound) listeners to implement the actual application of linear velocities and angular velocities. The thing is though, stepBody is such a low level method that it seems wasteful to pipe it through an event model… still… you might be able to do some insane things…hmmmmmm…
An event model actually isn’t the ideal thing. I forget what the proper pattern should be. The interceptor model, like JBOSS’s old security system before AOP, invoke(…) and all that… You can plug together a sequence of things to be applied. The problem with the event model system is you never know what order stuff is going to be applied so you need a pattern with ordering in the sequence of events. Anyway details! details!
Let me know what you think…
Ok here’s what I think : Why don’t make JOODE truly open ?
I mean, very modularized, like :
- You can choose if you want to have a 2D or 3D simulation
- You can choose if you want to compute rotational stuff or not
- You can choose which algorithms that is used to solve equations
- You can choose the integrator you want
- You can choose the friction model you want
- And so on…
That will make JOODE really interesting, because everyone can implement every algorithm he want, from the naive first order Euler integrator with no rotational computations to the complex Kunga-Rutta 4 robust algorithm, including something like a Verlet integration scheme.
To implement something like that, we surely need a “sequential system” in “physic simulation stepping”. And interfaces for objects.
I suggest also that we shouldn’t limit JOODE to rigid body simulation, so we can implement cloth simulation, partial and global deformations of objects, and so on.
All algorithms should be contained in a class that implement an interface (Ex : EulerIntegrator implements Integrator), and are nothing but code that treats data contained in the World / Space / Geom / Body / Particle / Joint classes.
So we clearly data and the code.
What we have to do is determine if this is really feasible and if yes how to do that. We should be careful because sometimes models don’t have the same data representation.
Following this idea, there would be only one type of space, and several type of CollisionTesters. However this could cause problems as kinds of spaces sometimes needs additionnal data stocking.
So we could maybe replace this by simply extending basic classes, so we can add data needed for the algorithm to work.
With this approach, I then see JOODE as a “big open-source framework released with a bagful of algorithms” rather than a “semi-open library with only one buggy algorithm useable only in specific cases”.
As for the 2D plane in arbitrary location / orientation issue, I think we could do the 2D/3D choice AND a 2D plane joint, cause it won’t have the same uses.
Well there are allready a variety of constraint solvers in the pipeline. Cholseski, LCP various different optimizations leading up to that point. At the moment its very crude the way you choose which you want to do (change a static variable and recompile). But this will be turned into an abstract factory pattern at some point (using the properties system kitfox made). So in a sense some of the functionality you want is there. It is definatly not the case that there is just one buggy algorithm that everything else is built around.