On Nov 24, 2008, at 4:35 AM, WT wrote:
Hi Peter,
thanks for answering my post.
>> [...]
>>2. continuously running the simulation engine, at a rate that can
also
>>be changed dynamically by the user (for instance, in the bouncing
>>balls example, increasing gravity makes the balls move faster,
thereby
>>requiring the engine to run more often in order to preserve accuracy
>>and to prevent anomalies such as the balls overlapping one another);
This isn't normally how physics simulations are done (decreasing step
time based on number of objects). This is especially bad because
collision detection can go up exponentially with the number of objects
(so more math has to be done per step as it is).
>
>While it may wind up making sense to put the simulation engine in a
separate thread, I would recommend _not_ trying to adjust the
simulation rate to account for the speed of the balls, precision,
etc. This sort of load-adjusting sounds good in theory, but it
ultimately fails because the performance characteristics of the code
changes according to the settings.
I'm afraid I'll have to disagree. My concern is not balancing the
CPU load, but getting accurate results. To use the bouncing balls
example again, if the balls move fast enough and if I don't
compensate by decreasing the time-interval through which I'm
advancing the motion, the balls WILL overlap and may do so
considerably. Even if they don't overlap in a way that's visible to
the human eye, overlaps may cause other anomalies, such as energy
non-conservation. These kinds of problems are typical of numerical
integration of differential equations and have nothing to do with
optimizing the CPU use.
Actually, this sounds more like a problem in the physics simulation
itself - no matter how small the time-step of the simulation,
collision will cause items to overlap. There are two approaches that
are common - recalculate with a smaller time step until the items no
longer overlap (basically a binary search to find the impact time).
The second is to use the math to figure out the exact moment of
collision - it's not too hard to figure out when two spheres will
intersect based on position, direction, and acceleration (or sphere vs
plane), but doing this for an arbitrary shape that is also spinning
(think rolling dice) becomes much harder.
The way it is generally done is to basically have two loops - one that
is always executed on a regular basis (to advance, say, a single
frame) and then within that "update simulation 1 frame" it can use one
of the two basic options above to have multiple (and non-regular)
updates to advance the simulation.
Personally I'd recommend looking into how existing physics engines
work (I'm a fan of ODE), as well getting a copy of O'Reilly's "Physics
for Game Developers", and track down David Baraff's (of Pixar) "Rigid
Body Simulation" paper. Brent Dingle's "Rigid Body Motion, An
Introduction" is a good lead in to the Baraff paper as well. In
general, the trick is to figure out how to do as little math as
possible on a regular basis, even if it requires doing some more
sophisticated math on an occasional basis.
Glenn Andreas [EMAIL PROTECTED]
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
