   Physics Engine
  I am currently developing my first physics engine and I have questions about two topics:1)  Through my research I have determined that my engine should be frame rate independent, how is the best way to do this?  --I am using Java and Java3d (please don''t laugh, I know the community consensus is that Java isn''t the "best" language for 3D game development but my application is not actually geared toward high-end graphics) and my first idea is to be notified every time that the frame is redrawn, time the duration of a frame and use the result as my delta t in any physics computations I perform.  I originally came up with this idea to just test my physics code but I have realized that there could be a few problems before I''ve even implemented it!  One is that the delta t (and thus all the physics calculations) will always be one frame behind the rendering, and another is that rendering won''t finish until after my physics code has completed meaning that if the physics code hogs all the CPU cycles my frame rate will become physics-dependent.Should I divorce the physics engine timing completely from the rendering pipeline?  If so, how do I handle unfinished business in my physics code?  I would greatly appreciate any suggestions.2)  I am interested in simulating rigid body dynamics in my physics engine, however, I am having problems with numerical integration (big surprise  ).  I have researched a ton of numerical integration techniques; euler, backward euler, runge-kuttas, predictor corrector, etc. and I would like to write a numerical integration library that will take an arbitrary function and integrate it using whatever method the user or and optimization routine chooses (preferably at run-time).  Are there any suggestions?  Thanks, I hope I haven''t been too long-winded or circumspect. 
  Frame-rate independent movement is pretty simple. First record the time before you do everything, then record it after everything (updating, rendering, etc.). You can then subtract the times and divide by a number, something like 1000 if you measure in milliseconds and want fractions of a second. Then you simply multiply all update values by that fraction. This is where Java does have a problem though, since it''s timer is very inaccurate. I believe it''s only accurate to 20 ms on Windows 98. Ouch... ;  I have come across this method of frame rate independence before and I certainly see its utility for frame rate independent animation.  However, it seems to lack the versatility needed for simulation i.e. integration and such (I could certainly be wrong).  I am really interested in what experience other people have with time representation.  Is this the only method that people are using?  Thanks. ;  Well, integration comes into play once you''ve broken your time sequence down into frame-rate independent timesteps. For each timestep, your integration method determines how your simulator handles events during that timestep. ;  I am familiar with the basics of numerical integration.  I was really interested in hearing how others may have implemented data structures to represent functions, integrators, etc.  I am also very interested in hearing the different ways that others have implemented frame-rate independent timing.  I have a few ideas of my own but I clearly recognize that others may have thought of things that I have not and that they may have implemented ideas that I have in more elegant ways than I probably will.  Thank you. ;  I use two separate systems. (A) For things that must reproduce the same results from the same input regardless of frame rate, I run the game logic/physics step N times each frame where N is determined by how much time has passed since last frame. This means the physics is running at a constant speed, typically 100 steps a second. Player movement should be in this category to keep it consistent. (None of that "the higher your frame rate the higher you jump" like in Quake3..)(B) For less important things, such as non-interactive particle effects and animations, I just multiply the motion vectors, gravity etc by the time step. As many things as possible should be put in this category because it''s "cheaper". ;  Yes, with things like physics, its not always a matter of multiplying all magnitudes by your framerate derived ''speed'' factor; this is fine for animation, but not for physics. Like AP said, you will have to run a fixed logic update x number of times rather than multiplying the magnitudes by x. ;quote:Original post by Anonymous Poster   (None of that "the higher your frame rate the higher you jump" like in Quake3..)I thought that happened because they rounded velocity to the nearest integer after each update, so rounding error tended to go one way or the other depending on frame rate. At least that''s what this guy says