I''m curious as to what sort of problems (to do with physics, and specifically collisions, I guess) aren''t solvable analytically, and require timesteps. Like, for what sort of system you can determine an equation that will give you the time until the next collision, and the appropriate point(s) of contact and normal(s) for the collision.

For instance, I''ve made a ball bounce around inside a container with objects inside, and worked out formulae that determine the exact time of collision, etc., and it appears to work fine. Of course that is a relatively simple system, and your''s is no doubt more complicated. But is it really too complicated to be done this way? The formulae I came up with really aren''t that computationally expensive. Perhaps they take a bit longer than a timestep test, but they only have to be done once per frame (my physics isn''t decoupled from the framerate) rather than several times. IIRC, we''ve sort of been over this before (Decoupling physics rate from frame rate). But I admit I only skimmed over that just now .

Ok, so I haven''t ever done a timestep method before , but I''ve thought and read about it, and the sort of tests that it requires. Do you still think it''s necessary to use timesteps, and that it wouldn''t be feasible to find an exact solution? Or do you think that the timestep method has some advantages over an exact solution?

Miles

Mike, DOH! I'd totally forgotten about that earlier discussion (darn search engine not working!). I've been living with the timestep method and had gotten sidetracked from collisions (and therefore had forgotten about the previous discussion). I'm now back at collisions and will have a go at the methods we discussed in the previous thread. Having said that, I think I have a timestep-based implementation that will work, so I may go with that first.

Part of the problem is that the physics for my vehicles HAS to be run at a fairly high rate (200 Hz min. or so...and less frequent and it becomes instable) and it isn't so easy to devolve the movement of one of these vehicles in to a single algorithim that can easily be used for collision checking. For my projectiles, I can certainly do the sort of analytical collision detection, but I don't think it will work where the vehicles are involved. I'm afraind for them that I will have to devolve collision checking to the lowest common denominator (meaning checking at the same rate as the vehicular physics is calculated).

Thanks for the link back to what was a very productive discussion!

Onnel

P.S. An edit: I CAN cheat and use a bit of a hybrid method for detecting collisions between projectiles and vehicles. since I have algorithims for the projectile movement, I can first compare the vehicle position during it's movement to the line representing the projectile movement from the last projectile physics update until the next upcoming projectile physics update. If they intersect, I can calculate the exact time by looking at where the line was intersected. This isn't ideal, but since I don't think I can use an algorithim-based approach for the vehicles, I think this is the best I can do.



[edited by - onnel on September 16, 2002 8:19:41 AM]

[edited by - onnel on September 16, 2002 8:32:35 AM]

quote:Maybe this is all a misunderstanding of the word framerate. for me, framerate means how often the system is rendered (i.e. frames per second (FPS)). My physics having NOTHING to do with that and the frame rate will be as high as it can manage while still calculating the physics. My physics rate is directly controlled by me and is independent of the framerate.

Yeah, I think there is a little misunderstanding A "frame" for me is a single interation of the main program loop, whereas a "frame" to you is whenever you render. So we both make sense in our different ways I should have mentioned what I meant by a "frame"; DOH!

What I was just trying to say was that whether or not you perform your physics calculations each frame or based on a time interval, you can still get the correct position because it's a function of time. If you do it every frame, you get more accurate lines, but as you mentioned, it's not worth overloading the CPU to perform those tedious calculations each frame

Okay, then. Cheerio

[edited by - Zipster on September 16, 2002 2:16:15 PM]