I have a simple 2D physics engine (actually several) that uses euler equations and it gets unstable. From what I've heard this type of engine is usually a little unstable, but I was wondering if anyone had any tricks to help stabalize a physics engine running on classical equations. On another note I'd like to handle collisions with lines instead of polygons. I want to be able to collide a piece of string against another piece of string (or maybe itself), but I have no idea how to handle the collision response. I'm using discrete time steps so I'd like to avoid fancy parametric exact time of collision type things if you know what I mean. edit: Almost forgot to throw in some links: http://www.alrecenk.cjb.net:81/java/show/physics/line/ http://www.alrecenk.cjb.net:81/java/show/physics/spring/

Well, about euler integration, there's really not much you can do...
The best thing would be to reduce the timestep, but it won't be long till this starts having an an effect on the framerate; there's a limit to this if you want your application to keep up with real time...

The problem with euler is very prominent when integrating acceleration (forces essentially) that can change very fast for euler to keep track.
In fact, it's not the actual rate of change that matters; E.g. Euler yields precise results if the integrand increases very fast but at a constant rate;
It's when the rate of increase/decrease is not constant (and also very high), that Euler really mucks up! (like with stiff spring forces...)

One quick tip to increase Euler's accuracy is to use both the current and previous value of acceleration and velocity, in order to derive the current position.

e.g. usual euler:
1. x(n) = x(n-1) + v(n-1)*dt
2. v(n) = v(n-1) + a(n-1)*dt

Mod
v(n) = v(n-1) + dt*(a(n-1)+a(n))/2
x(n) = x(n-1) + dt*(v(n-1)+v(n))/2

The geometric meaning behind it is to use trapezoids (instead of rectangles in simple euler) to approximate the area under the function's curve.
The former is precise only for constant functions, while the latter obviously offers better approximation.
You'll just have to adjust your calculations to be one step ahead of the visible part of your simulation.
And don't expect any miracles, this is still euler.
If you totally want to get rid of exploding simulations etc. you may want to consider switching to a more advanced integrator.

Quote:Original post by someusername
If you totally want to get rid of exploding simulations etc. you may want to consider switching to a more advanced integrator.

What would you suggest? I tried verlet, but it was much worse. Am I correct in thinking that collision response in verlet is just projection?

Quote:Original post by Alrecenk

Quote:Original post by someusername
If you totally want to get rid of exploding simulations etc. you may want to consider switching to a more advanced integrator.

What would you suggest? I tried verlet, but it was much worse.

Are you certain that you didn't miss something in the implementation? It should be far more accurate than Euler...
The tricky part with Verlet is actually starting it up. Since it requires two "previous" positions in each step, this is a little troublesome in the beginning. Some tests I did a month ago, showed that when starting verlet with an initial value calculated with Euler's method (instead of the actual value indicated by the mathematical formula), the error would increase by 200%!
This showed that minimum error in the initial conditions, propagated -and possibly escalated- during the simulation.

Quote:
Am I correct in thinking that collision response in verlet is just projection?

I'm not quite sure about that. Haven't tried to implement collision response with it, to be honest. From what I've read though, I know that you can explicitly move an object in a certain position/orientation and let the simulation handle the rest.
I think this is -pretty much- how constraints are handled with Verlet.
You meant something similar?
I believe you'll need the input of someone with more experience in Verlet for this.

To conclude, I cannot just suggest one method or another...
Euler is -often- enough for simple simulations, where a good ratio of speed/accuracy is necessary.
Verlet is more accurate in calculation of position by 2 orders of magnitude, than Euler. However that doesn't seem to be fully verified by numerical results.
However, it is far more accurate.

RK2 seemed to yield pretty accurate results with relatively little CPU overhead. It only needs evaluation of one extra intermediate point in the timestep.
Probably because of the error in verlet's initial values, it seemed to be more accurate than Verlet, but this is in contrast with theory...
RK4 would be your choice if you wanted the maximum possible accuracy. It will be quite "heavy" for a simple simulation though.

I guess you should weigh the pros/cons, consider the ratio of speed/accuracy you want.
Why not implement them all and be able to switch from one to another, anytime?
Btw, try the modified euler I suggested... If you want to stick to the classic Euler scheme, I doubt it can get any more accurate. And it's fast!

Quote:Original post by Alrecenk
On another note I'd like to handle collisions with lines instead of polygons. I want to be able to collide a piece of string against another piece of string (or maybe itself), but I have no idea how to handle the collision response. I'm using discrete time steps so I'd like to avoid fancy parametric exact time of collision type things if you know what I mean.

im writing a paper on precisely this subject at the very moment, and i hope to be able to post it here asap (although that could still be a while). it provides a simple and efficient solution to your abovementioned problem.

I think I'll try my luck with RK4. It sounds good though I haven't found any really good articles on how to do it for physics(please post if you know any). A lot of pure math articles... One thing I would like to know: does it define velocity explicitly or implicitly?

Eelco, I look forward to reading your paper. I've been working on some ideas of how to do that myself. I haven't tested anything yet though as I'm still working on getting a better physics core. The collission detection should be as simple as checking which side of the lines each point is one before moving and then checking again after moving and if they are different and if the line connecting the point's positions crosses the line in question then there has been a collision. Though the line will be moving as well and I'm not really sure how that will affect things. As for the reaction I would distribute the collision force between the objects based on their mass and then on the line I distribute that force based on where the collision was on the line. But that is all just speculation. Of course, if you're talking about 3D that's a whole different story...I'd like to talk about this more though I probably won't even begin the implementation for a week or two(depending on how difficult it is implement RK4).

That would explain why I didn't find anything relating directly to physics. I guess I've got a lot of research to do. Glad it is explicit, I'll checkout your demo, hopefully it will clear things up.

Seeing as how it is stable I would have to say no...