[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] physics basics?



Michal Wallace <sabren@manifestation.com>:
>
[snip]
> I hadn't thought of that. My calculus is a little rusty, but
> I do remember that it dealt with ALL the possible values of
> x, where the distance between ticks shrinks to zero. Is that
> what you're saying?

More or less, yes. If you picture the curve given by a
(non-approximated) solution, it's continuous -- i.e. it exists for all
values of x. With the approximation you describe, you not only miss
the x-values in-between, but the y-values for the x-values you _do_
have will be a little off. And they will become more and more wrong as
time goes by, since you approximate them stepwise from the previous
y-value, so the errors accumulate.

In many cases, this "error" may not be a problem -- it's only an error
in the sense that it's a difference from the calculus-based solution;
if you're only simulating things to make them look/feel good in a
game, that may not be a problem. If you're trying to predict the
weather (for instance), such errors are more of a problem :)

[snip]
> One of Grand's examples is a racecar game. Apparently he
> worked on one a long time ago. The developers wanted to hard
> code the equations for swerving, breaking, etc. He argued
> for modelling the rules of physics and letting these
> behaviors emerge on their own.

Sounds reasonable. But simulating the rules of physics are still
possible to do using physics... I guess the problem is that the
physical system quickly becomes far too complex, and numerical
solutions (the approximations we're talking about) are the only
feasible way of dealing with it. (This is, I guess, what they do when
predicting the weather too :)

> When you run the bouncing ball code, it actually does look
> like the path of a bouncing ball.

Yup. And it will be veeeery close to the movement predicted by
Newton's laws. It's basically a numerical solution instead of a
symbolic solution.

> Can we look at a more complex example though?
> 
> There's a nice physics demo that uses macromedia flash:
> 
>     http://www.illogicz.com/flash5/physicsengine/
> 
> I don't see the actionscript code anywhere, but it seems
> like a nice system.

Cool stuff! :)

> It brings up two big questions for me:
> 
>    1. how is he dealing with all those curved surfaces?
>    2. which model (equations or rules) works best for this
>       kind of thing?

I'd go with a numerical approximation. Trying to solve this kind of
system symbolically would be a terrible task.

On the other hand, it may be that it's possible to do parts of it
symbolically, i.e. calculate the paths of a ball in free fall using
standard formulae, and let it move until it hits something etc.

I'm sure the O'Reilly book discusses this sort of thing -- I haven't
really read that much of it yet :)

[snip]
> Thanks. I admit I never got that far! :)

Me neither, really ;)

> I'll take a look.

Me too, I guess.

BTW: I saw a couple of generic simulation programs a few years ago.
The idea was that you linked containers of fluid (variables) with
pipes that had valves (differentials) that were relatively simple
functions of the contents of other containers etc. This is basically
similar to setting up a differential equation, which isn't all that
hard. (E.g. just encoding Newton's laws directly.) Then the systems
used methods such as Euler's to simulate the behaviour of the system
(i.e. numerically solve the differential equations to get the values
of the variables for each point in time). This approach (which is what
Grand is talking about, more or less) made it very much easier to
simulate all kinds of systems than actually deriving the exact
equations for each variable (which usually would have been all but
impossible :)

> Cheers,

-- 
Magnus Lie Hetland        Practical Python          The Anygui Project
http://hetland.org        http://ppython.com        http://anygui.org
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org