|
 |
JRG wrote:
>
> Actually I've just studied numerical calculus at University... but didn't take the
> exam yet (I'll probably do it in september) so I still have to read through my
papers
> before doing something useful with the new notions I have... :-)
>
> [...]
>
> Yeah, that's the other way round :) I didn't take into account *forces*, just
gravity
> acceleration and collisions. Anyway I'll look into it deeplier as soon as I have my
> calculus exam done.
Well actually an acceleration is force divided by mass.
Numerical calculus will surely be very useful (i heard a lecture on that
matter last term too), but it won't help without some mechanics of course.
;-)
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
|
|
"Christoph Hormann" wrote:
>
>
> JRG wrote:
> >
> > Actually I've just studied numerical calculus at University... but didn't take
the
> > exam yet (I'll probably do it in september) so I still have to read through my
papers
> > before doing something useful with the new notions I have... :-)
> >
> > [...]
> >
> > Yeah, that's the other way round :) I didn't take into account *forces*, just
gravity
> > acceleration and collisions. Anyway I'll look into it deeplier as soon as I have
my
> > calculus exam done.
>
> Well actually an acceleration is force divided by mass.
Of course :) I just meant the only force I took into account is weight.
> Numerical calculus will surely be very useful (i heard a lecture on that
> matter last term too), but it won't help without some mechanics of course.
> ;-)
Hehe, that's for sure. Fortunately I don't lack physics notions, just quite a bit of
programming experience.
--
Jonathan.
Post a reply to this message
|
|
|
|
"Slime" wrote:
> Yes. Let's say I have a system with two balls. Imagine this now: One ball is
> at (0,0) and is heading towards (1,1). The other ball is at (1,0) and
> heading towards (0,1). Assume their radii are extremely close to zero.
>
> They're going to bounce off each other at time=0.5 (assuming time=1 is the
> end of the iteration, when they reach their destinations).
>
> I detect the collision at t=.5. I then figure out their new velocities. (In
> this case, their velocities will simply be swapped, I believe. Or something
> like that. Let's say for simplicity that they swap their velocities.)
>
> Then I place the balls at (their current starting position) + (.5*(their old
> velocity)) - (.5*(their new velocity))
>
> Their new position is at (1,0) and (0,0), respectively. In this example,
> they happen to have swapped starting positions.
>
> Now that I've taken care of that intersection, I ignore any intersections
> that occur at t <= 0.5. That way I won't detect their collision again. And
> at the end of the iteration, I just add each balls' velocity to it's
> position, so the first ball ends up at (0,1) and the second at (1,1).
>
> Did that make sense?
Sure it did. It sounds very interesting.
> Before long, I'll work on the code and make a new example for you. But not
> now... Warcraft III takes priority =) (two levels left! I think.)
Hehe, must be real fun... :-)
--
Jonathan.
Post a reply to this message
|
|
