gdalgorithms-list

Re: [Algorithms] Simple player collision response problem

[<SHA...@ao...>]

In a message dated 07/09/00 17:15:05 !!!First Boot!!!, zi...@n-... 
writes:

<< 
 What I'm doing now is simply calculating a sliding plane based on the poly
 the player is hitting and sliding him along that with the remaining velocity
 after the initial collision.  I do this recursively each frame against the
 environment until the velocity is so small I can just set it to zero.
  >>

Hi,

What you need to do is do it recursively between frames not each frame 
otherwise you will see these oscillations.

John.

RE: [Algorithms] Simple player collision response problem

[Steve W. <Ste...@im...>]

> -----Original Message-----
> From: Jason Zisk [mailto:zi...@n-...]
> Sent: Thursday, September 07, 2000 9:42 AM
> To: Algorithms List
> Subject: [Algorithms] Simple player collision response problem
> 
> What I'm doing now is simply calculating a sliding plane 
> based on the poly the player is hitting and sliding him 
> along that with the remaining velocity after the initial
> collision.  I do this recursively each frame against the
> environment until the velocity is so small I can just set
> it to zero.
> 

Don't wait until the next frame to recurse the rebound.  In my collision
detection I let the movement continue as far as is possible during the frame
that the collision takes place so the frame displays only the results of the
bouncing.  What I see at creases is a smooth migration toward the center of
the crease until the player is directly on the crease.

Re: [Algorithms] Simple player collision response problem

[Jason Z. <zi...@n-...>]

I guess I phrased that line poorly.  It should have said, each frame I keep
sliding the player recursively until he comes to a stop then flip the frame
and do it again.  Problem is, when the player is in a valley he will often
come to a stop on alternate sides of the valley each frame, and thus kind of
bounce back and forth.  I can reduce this by including friction (which I
intend to do anyway), but unless I put a LOT of friction he will oscillate.
I'm assuming the oscillation will occur in corners of buildings too.

Maybe I'm doing something simple wrong in my implementation?  From people's
replies it sounds like what I'm doing should work.  Here is my code, maybe
someone can spot something.  It is fairly simple.  Note it isn't actually
recursive, but it should be the same effect.  It originally was recursive
but I found this easier to debug.

-----------------------------
// do the initial collision with world, sphereCenter is player's location,
// vel is his velocity, cInfo is a struct that contains collision info
bool collided = terrain->CollideSphere(sphereCenter,3.0f,vel,&cInfo);

// if no collision just move to destination
if(!collided) sphereCenter += vel;

// do collision response if we hit something
while(collided)
{
  // remember what our destination point would have been
  zVector3 dest = sphereCenter + vel;

  // Move to the nearest collision
  zVector3 V = vel;
  V.normalize();
  V = V * (cInfo.dist - 0.01f);    // cInfo.dist is distance to collision
  sphereCenter += V;

  // Determine the sliding plane
  zPlane sp;
  sp.normal = cInfo.point - sphereCenter;// cInfo.point is collision point
  sp.normal.normalize();
  sp.dist = Dot(sp.normal,cInfo.point);
  // create ray starting at where we should have stopped and going in
  // direction of plane normal
  zPickRay r;
  r.origin = dest;
  r.dir = sp.normal;

  // intersect with plane to find out distance to new position on that plane
  sp.Intersect(r);
  zVector3 slidePlaneNormal = sp.normal * r.dist
  zVector3 newDestinationPoint = dest + slidePlaneNormal;

  // Generate the slide vector, which will become our new velocity vector
  // for the next iteration
  vel = newDestinationPoint - cInfo.point;

  // make sure this new mini-velocity doesn't collide with anything else
  collided = wState->Terrain()->CollideSphere(sphereCenter,3.0f,vel,&cInfo);

  // if no collision add slide velocity and break out
  if(!collided) sphereCenter += vel;
}
-----------------------------
And thats it.  I then set the player's location to sphereCenter and its
done.  It works wonderfully for the most part, until you get stuck in a
crease.  Is there something I'm overlooking?

- Jason Zisk
- nFusion Interactive LLC


----- Original Message -----
From: Steve Wood <Ste...@im...>
To: <gda...@li...>
Sent: Friday, September 08, 2000 7:44 PM
Subject: RE: [Algorithms] Simple player collision response problem


> > -----Original Message-----
> > From: Jason Zisk [mailto:zi...@n-...]
> > Sent: Thursday, September 07, 2000 9:42 AM
> > To: Algorithms List
> > Subject: [Algorithms] Simple player collision response problem
> >
> > What I'm doing now is simply calculating a sliding plane
> > based on the poly the player is hitting and sliding him
> > along that with the remaining velocity after the initial
> > collision.  I do this recursively each frame against the
> > environment until the velocity is so small I can just set
> > it to zero.
> >
>
> Don't wait until the next frame to recurse the rebound.  In my collision
> detection I let the movement continue as far as is possible during the
frame
> that the collision takes place so the frame displays only the results of
the
> bouncing.  What I see at creases is a smooth migration toward the center
of
> the crease until the player is directly on the crease.
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Simple player collision response problem

[<SHA...@ao...>]

In a message dated 09/09/00 00:14:16 !!!First Boot!!!, Ste...@im... 
writes:

<< Don't wait until the next frame to recurse the rebound.  In my collision
 detection I let the movement continue as far as is possible during the frame
 that the collision takes place so the frame displays only the results of the
 bouncing.  What I see at creases is a smooth migration toward the center of
 the crease until the player is directly on the crease. >>

Hi,

What I do is only test collision on tri's which the player is not allowed to 
walk on i.e. by testing the normal->y component of the surface.
Then, to determine the player's y position, I shoot a ray straight down and 
see which tri this hits and from that compute the y of where the player is 
standing.
This stops wallowing around in creases :) and also cues which sounds to play 
for the players footsteps based on the texture type under the player.

Does your algorithm also have the undesirable effect in a concave corner 
where two walls meet??

John.

Re: [Algorithms] Simple player collision response problem

[Jason Z. <zi...@n-...>]

I am going to test to see if happens with corners as well, if it only
happens on valleys in the terrain I might be able to hack something.  But
since the algorithm is the same for walls and floors I'd assume it would
happen for both.

I actually want to use the same algorithm for all polygons, mainly because
of things like walking up stairs.  This algorithm (found on flipcode.com)
allows the player to smoothly walk up stairs.  By just getting the height
under the player you will often run into trouble with stairs where you will
just kind of pop up and it looks/feels quite bad.

- Jason Zisk
- nFusion Interactive LLC


----- Original Message -----
From: <SHA...@ao...>
To: <gda...@li...>
Sent: Saturday, September 09, 2000 1:54 AM
Subject: Re: [Algorithms] Simple player collision response problem


> In a message dated 09/09/00 00:14:16 !!!First Boot!!!,
Ste...@im...
> writes:
>
> << Don't wait until the next frame to recurse the rebound.  In my
collision
>  detection I let the movement continue as far as is possible during the
frame
>  that the collision takes place so the frame displays only the results of
the
>  bouncing.  What I see at creases is a smooth migration toward the center
of
>  the crease until the player is directly on the crease. >>
>
> Hi,
>
> What I do is only test collision on tri's which the player is not allowed
to
> walk on i.e. by testing the normal->y component of the surface.
> Then, to determine the player's y position, I shoot a ray straight down
and
> see which tri this hits and from that compute the y of where the player is
> standing.
> This stops wallowing around in creases :) and also cues which sounds to
play
> for the players footsteps based on the texture type under the player.
>
> Does your algorithm also have the undesirable effect in a concave corner
> where two walls meet??
>
> John.
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Simple player collision response problem

[Robert D. <RD...@ac...>]

> But since the algorithm is the same for walls and floors
> I'd assume it would happen for both.

Not necessarily a correct assumption, since gravity acts downwards you
always have a force pulling you down into the crease, but when walking into
a corner you could simply zero the walking force since the player is doing
something silly, and this won't look bad.  Whereas to zero gravity could
look very wrong.

Robert

[Algorithms] FIST optimization

[John R. <jra...@ve...>]

As many of you already know, the call to 'ftol' can be one of the biggest
hotspot spikes in a 3d application.  Every time a floating point number is
converted into an integer, rather than simply producing a 'fist'
instruction, MSVC will instead invoke a very slow procedure call to 'ftol'.
I have heard this is to ensure that the rounding behaviour of the operation
conforms to ANSI standard or something like that.

Back when I was an assembly programmer I just used the fist instruction
wherever needed.  With MSVC there is a compiler optimization switch called
/Qifist, which allows MSVC to use the 'fist' instruction instead of the call
to 'ftol'.

When I enable this optimization my performance profile is greatly improved.
At the heart of my collision detection routines is a hash, where I take the
floating point x,y co-ordinate in world space and remap it into an index to
this precomputed collision detection table.  This is a critical operation
that requires the conversion from floating point to int, very efficiently.

However, the behavior I am experiencing is as if the rounding mode were
occasionally set to something other than truncate behavior.  Meaning, where
I expect a conversion from 2.99999 to int to produce a 2, not a 3.  The
behaviour is spurious and unpredictable.  When I worked in assembly code I
never had this problem.

My main question is, how can the rounding mode ever get changed?  Or am I
missunderstanding the behavior possibly?

The symptom is as follows.  Without the /Qifist option enabled my collision
detection works flawlessly.  With the /Qifist enabled it behaves spuriously,
exactly as if sometimes it rounds the float to hash index incorrectly, thus
accessing the wrong pre-computed collision detection polygon set.

Why can't you guarentee that the rounding mode is set to truncate throughout
the application?  I could switch to inline assembly I suppose, but I prefer
to have the compiler generate the code naturally with all of it's normal
optimizations enabled.  Does anyone know the preferred method to guarentee
the processor is in a rounding mode which causes truncation to always occur?
Or am I missinterpreting the problem entirely?

Thanks,

John

RE: [Algorithms] FIST optimization

[Norman V. <nh...@ca...>]

John Ratcliff writes:
>
>My main question is, how can the rounding mode ever get changed?

There was a discussion about the fpu being reset recently on the MingW32
list

This URL should get you lots of hits
http://www.egroups.com/messagesearch/mingw32?query=long%20double

See any of the thread

"More on 'long double' problems under Win9x"

Let us know if you come up with anything 'definate'

Norman Vine

Re: [Algorithms] FIST optimization

[Pierre T. <p.t...@wa...>]

> I have heard this is to ensure that the rounding behaviour of the
operation
> conforms to ANSI standard or something like that.

Exactly. Else the FIST instruction alone can produce anything, as you stated
(a floor, a ceil or a best, depending on the current FPU rounding mode).


> My main question is, how can the rounding mode ever get changed?  Or am I
> missunderstanding the behavior possibly?

I would have said the rounding mode was saved/restored during task switchs,
but I'm not so sure. If it's not, I guess it's perfectly possible for a
thread to setup a "ceil" rounding mode, and then you're in trouble later.
But I really doubt the FPU mode is not saved, since many apps would already
have exploded otherwise.

So, maybe somewhere in your code you call a third-party API which changes
the FPU rounding mode. IIRC you're using some of them (some RAD Tools apps
or maybe a physics one). You'd better restore the correct FPU rounding mode
after you call'em.

IIRC the LoadLibrary method also resets the FPU to a particular state, which
might not suits your needs. All in all it's worth reconfiguring the FPU
before your collision code. Once / frame, it's free.

Use the _controlfp and _control87 functions if you don't want inline
assembly.

And BTW I would say this is a common problem. I had similar troubles, more
than one time...

Pierre

Re: [Algorithms] FIST optimization

[Amit B. <am...@de...>]

If you're using D3D, then it's quite possible that D3D is
changing the rounding mode. I think there's a flag somewhere
in D3D which you can set so it restores the FPU control
word every time D3D decides to change it.

Ahh.. found it :

IDirectDraw7::SetCooperativeLevel

has a flag called "DDSCL_FPUPRESERVE". From the
docs :

"The calling application cares about the FPU state and does 
not want Direct3D to modify it in ways visible to the application. 
In this mode, Direct3D saves and restores the FPU state every 
time that it needs to modify the FPU state. For more information, 
see DirectDraw Cooperative Levels and FPU Precision. "

That might resolve your issues.

Re: [Algorithms] FIST optimization

[Pierre T. <p.t...@wa...>]

Well,

I've just experienced the very same bug, just today, with some skeletal
animation code:

- it works in Debug build
- it works in Release build without /Qifist
- it fails in Release build with /Qifist

After some time, I managed to find the wacked line. Just that:

 curidx  = udword(mPlayTime);

...where mPlayTime is obviously a float.

This modification fixed it:

  curidx  = (udword)floorf(mPlayTime);

...which means one way or another the FPU rounding mode actually had been
modified before, somewhere. This is quite "fun" to face that bug just when
the topic comes to the list. But this is frightening to realize it
*actually* happens. And since I'm *always* compiling with /Qifist, I wonder
how many of them silently lie all over the place, ready to bomb.

Then I thought about the recent mails here. I then changed the way I
initialize Direct3D, and used DDSCL_FPUPRESERVE instead of DDSCL_FPUSETUP.
Nothing changed.


...but the guilty one is D3D anyway...

When I reset the FPU to the "chop" rounding mode before calling
Renderer->Init(), it still does not work.

When I reset the FPU to the "chop" rounding mode after Renderer->Init(), it
*does* work.

Hence:
1) Initializing D3D changes the rounding mode.
2) ...even if you use DDSCL_FPUPRESERVE..... !
3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway, *and*
reset the FPU after D3D has been initialized.

Maybe I'm missing something with D3D (perhaps another magic flag in another
place), but for the moment and for my particular bug, I clearly found the
guilty one.

Hope it helps.

Pierre



----- Original Message -----
From: John Ratcliff <jra...@ve...>
To: <gda...@li...>
Sent: Saturday, September 09, 2000 7:27 PM
Subject: [Algorithms] FIST optimization


> As many of you already know, the call to 'ftol' can be one of the biggest
> hotspot spikes in a 3d application.  Every time a floating point number is
> converted into an integer, rather than simply producing a 'fist'
> instruction, MSVC will instead invoke a very slow procedure call to
'ftol'.
> I have heard this is to ensure that the rounding behaviour of the
operation
> conforms to ANSI standard or something like that.
>
> Back when I was an assembly programmer I just used the fist instruction
> wherever needed.  With MSVC there is a compiler optimization switch called
> /Qifist, which allows MSVC to use the 'fist' instruction instead of the
call
> to 'ftol'.
>
> When I enable this optimization my performance profile is greatly
improved.
> At the heart of my collision detection routines is a hash, where I take
the
> floating point x,y co-ordinate in world space and remap it into an index
to
> this precomputed collision detection table.  This is a critical operation
> that requires the conversion from floating point to int, very efficiently.
>
> However, the behavior I am experiencing is as if the rounding mode were
> occasionally set to something other than truncate behavior.  Meaning,
where
> I expect a conversion from 2.99999 to int to produce a 2, not a 3.  The
> behaviour is spurious and unpredictable.  When I worked in assembly code I
> never had this problem.
>
> My main question is, how can the rounding mode ever get changed?  Or am I
> missunderstanding the behavior possibly?
>
> The symptom is as follows.  Without the /Qifist option enabled my
collision
> detection works flawlessly.  With the /Qifist enabled it behaves
spuriously,
> exactly as if sometimes it rounds the float to hash index incorrectly,
thus
> accessing the wrong pre-computed collision detection polygon set.
>
> Why can't you guarentee that the rounding mode is set to truncate
throughout
> the application?  I could switch to inline assembly I suppose, but I
prefer
> to have the compiler generate the code naturally with all of it's normal
> optimizations enabled.  Does anyone know the preferred method to guarentee
> the processor is in a rounding mode which causes truncation to always
occur?
> Or am I missinterpreting the problem entirely?
>
> Thanks,
>
> John
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FIST optimization

[Pierre T. <p.t...@wa...>]

> 3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway,
*and*
> reset the FPU after D3D has been initialized.

Another idea: maybe we could just put the render code in a separate thread
and let it go... Since the FPU mode is saved/restored during task switches
(I checked), it could probably be the simplest way.

And John, I just found that my Perlin noise code was not working anymore in
Release mode (I didn't use it for a long time), because of the /Qifist as
well ! I checked it after reading about your wacked hash-table, since the
standard Perlin also use the hash-way. And that was here, crystal clear,
completely biased with a round-to-nearest mode......

...suddenly I'm scared...

Pierre

Re: [Algorithms] FIST optimization

[Timur D. <ti...@3d...>]

After running into this bug sometime ago i just did this:
there`s very few places where this code actually needed,
simple check of profiling result will give all places where this function
should be used, without sacraficing
precision in code where speed is not relevant.

inline int ftoi( float f ) {
  int temp;
  __asm   fld [f]
  __asm fistp [temp]
  return temp;
}

_______________________
 Timur Davidenko.
 Lead Programmer.
 3Dion Inc. (www.3dion.com)
 e-mail: ti...@3d...


----- Original Message -----
From: "Pierre Terdiman" <p.t...@wa...>
To: <gda...@li...>
Sent: Sunday, September 10, 2000 4:55 PM
Subject: Re: [Algorithms] FIST optimization


> > 3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway,
> *and*
> > reset the FPU after D3D has been initialized.
>
> Another idea: maybe we could just put the render code in a separate thread
> and let it go... Since the FPU mode is saved/restored during task switches
> (I checked), it could probably be the simplest way.
>
> And John, I just found that my Perlin noise code was not working anymore
in
> Release mode (I didn't use it for a long time), because of the /Qifist as
> well ! I checked it after reading about your wacked hash-table, since the
> standard Perlin also use the hash-way. And that was here, crystal clear,
> completely biased with a round-to-nearest mode......
>
> ...suddenly I'm scared...
>
> Pierre
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

[Algorithms] rather curious

[Akbar A. <sye...@ea...>]

hey,
i am just wondering, but how many people know about *this*
"gravity isn't really a force" and that it is caused by the curvature in the
space time fabric.

And, if you drop two objects in a vacuum they *really* don't fall
at the same rate (difference is very small, order of 10^-24) <this *makes
sense*>
why don't more people know this?

even if it's at a difference 10^-24,
i assure you, if we had money that was this accurate, banks would "require"
this much precision in there software :|

i am just curious what is the *the few on this list*  knowledge about
this...

i recently (3 minutes ago) got in an argument with a friend on this *topic*,
he told me his professor said that "Gravity is a FORCE" and saying anything
different from that is pure anarchy.

i told him what is above is true and André Lamothe writes this in all of his
books, and i'm pretty sure he knows more than your professor (the laws make
sense as well), ...



i am probably just t-ed of cause i didn't have more proof about the space
time fabric one :|


btw, andre, if your not on the list;
i highly suggest you join :) i know your busy with volume 2 and all...

peace,
akbar A.

Re: [Algorithms] rather curious

[Eric L. <le...@C4...>]

> i am just wondering, but how many people know about *this* "gravity isn't
> really a force" and that it is caused by the curvature in the space time
> fabric.
> 
> And, if you drop two objects in a vacuum they *really* don't fall at the same
> rate (difference is very small, order of 10^-24) <this *makes sense*> why
> don't more people know this?
> 
> even if it's at a difference 10^-24, i assure you, if we had money that was
> this accurate, banks would "require" this much precision in there software :|
> 
> i am just curious what is the *the few on this list*  knowledge about this...
> 
> i recently (3 minutes ago) got in an argument with a friend on this *topic*,
> he told me his professor said that "Gravity is a FORCE" and saying anything
> different from that is pure anarchy.

Due to my degree in astrophysics, I have had some exposure to this kind of
stuff.  The presence of matter or energy in space (which are actually
equivalent -- remember E = mc^2) causes the space surrounding it to become
curved.  The more mass (or energy), the greater the curvature.  Gravity is
the attractive force which arises due to this curvature.

General Relativity is very interesting, but I doubt that many programmers
need it unless they're simulating near-light-speed travel or plan to let
users fly a spaceship near black holes.  Basic Newtonian physics ought to
serve you just fine.  For a character standing on the surface of a planet,
time actually travels faster for his head than it does for his feet, but the
difference is so miniscule that it's difficult to measure with even our best
technology.  Implementing a relativistic effect like this would never
produce any noticeable results.

If you're curious about the subject of General Relativity, I have found the
following book to be very well written:

Foster and Nightingale, "A Short Course in General Relativity",
Springer-Verlag.

http://www.amazon.com/exec/obidos/ASIN/0387942955/

Let me warn you though, unless you have an M.S. or better in physics or
mathematics, this book will scare you.

-- Eric Lengyel

Re: [Algorithms] rather curious

[Joe S. <jo...@ax...>]

Not that I have anything to add to this conversation..  but I did want to
ask.. where is a good place or a good book to get started with physics?  my
physics knowledge is pretty low..

-Joe

RE: [Algorithms] rather curious

[Akbar A. <sye...@ea...>]

>where is a good place or a good book to get started with physics?
here i will lay this out in stages, i am sure a lot of people can offer some
advice.

check out André lamothes' newest book, chapter 13 is well worth a read.
like always, he gives a good intro and finishes off with some good old
simple kinematics (demos included, not just text and a code blips like most
texts) he also tries to keep calculus at a down low most of the time.

after that you might want to look into
Thomas/Finney edition 9
Calculus
published by Addison Wesley (www.awl.com)
ISBN = 0-201-53174-7

check out Chapter 9 and Chapter 11. you really want to parameterize all your
objects. helps with keeping bandwidth at an all time low and predication
issues.

chris hecker has written some *very good* stuff and has "demos" on his site.
www.d6.com
he gives some good books as well.

jeff lander has also written some good articles on physics, as well as
demos.
you should check out archived issues of gdmag.
www.gdmag.com


you should also check out this book as well ( i am not sure if it's
available *everywhere*, got at it at ut, one of those *ut* books i suppose?)

Dynamics (Engineering Mechanics)by: Anthony Bedford, Wallance Fowler

your best bet to really understanding this is "learn" the fundamentals
really well. pull out some paper, work out the problems, make fake problems,
then do them again, and again. repeat till get sleepy. then write code...
goto starbucks write more code..
pass out :)

imho in general you should get really good at integrals, your going to get
sick of them after a while though, but later on when you have to
implement/reading some algo it will help you out..


peace,
akbar A.







-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Joe
Silver
Sent: Sunday, September 10, 2000 8:30 PM
To: gda...@li...
Subject: Re: [Algorithms] rather curious


Not that I have anything to add to this conversation..  but I did want to
ask.. where is a good place or a good book to get started with physics?  my
physics knowledge is pretty low..

-Joe

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] rather curious

[<ro...@do...>]

Joe Silver  wrote:

>Not that I have anything to add to this conversation..  but I did want to
>ask.. where is a good place or a good book to get started with physics?  my
>physics knowledge is pretty low..
>

The three-volume set "Lectures in Physics", by Richard Feynman, is
terrific.  It is pitched to the level of freshman and sophomore
science majors.  

Re: [Algorithms] rather curious

[Mark W. <mwa...@to...>]

> equivalent -- remember E = mc^2) causes the space surrounding it to become

Actually, correct me if I'm wrong, E = mc^2 + Eo

Sorry, couldn't help but get pedantic considering the current thread :)

Mark.

Re: [Algorithms] rather curious

[<ro...@do...>]

Akbar A.  wrote:

>hey,
>i am just wondering, but how many people know about *this*
>"gravity isn't really a force" and that it is caused by the curvature in the
>space time fabric.
>

Of course, this thread is entirely off topic with respect to game
algorithms in the ordinary sense (unless of course you want to make
relativistic physics the object of the game :-)).  But physics is one
of the best subjects to be "rather curious" about, so no one has
objected so far.

In the modern physics paradigm,  gravity is one of the four basic
forces,  and,  by many orders of magnitude,  the weakest of the four.
The other three are called (in order of increasing strength), the weak
force (which, for example,  is responsible for the decay of neutrons
into protons, electrons and neutrinos), the electromagnetic force
(which is responsible for all of chemistry, optics and all other
electromagnetic interactions), and the strong force, (which is
responsible for the binding of quarks into protons and neutrons, and
the binding of protons and neutrons into atomic nuclei.  There has
recently been a buzz about some experimenters claiming to have
discovered a fifth force, but it has not yet entered into the
mainstream physics paradigm.  So, in terms of modern physics it is
perfectly OK to call gravity a force.

But in this paradigm, gravity is indeed also understood as a
phenomenon of the curvature of the space-time "fabric", necessarily
caused by the presence of energy (including mass).  You can completely
understand the orbits of bodies under the gravitational force as
motion along geodesics, i.e. paths of shortest length, in the curved
space-time.  The mathematics that you need to put this all on a sound
logical basis is higher-dimensional differential geometry and tensor
analysis.  This is the framework of Einstein's General Theory of
Relativity.  For the most part, for most ordinary experimental
observations, General Relativity predicts the same behavior as the
classical Newtonian gravitational model, up to the precision of
experiments.  But in the several dozen experiments where GR predicts a
measurable difference from the predictions of Newtonian gravitational
theory, GR has been confirmed.  Read any popular book on modern
physics, such as Stephen Hawking's "A Brief History of Time" for a
non-mathematical review of these ideas, experiments and astronomical
observations.  If you want the real stuff, the best book is
"Gravitation", by Misner, Thorne, and Wheeler, but it is daunting. 
  
>And, if you drop two objects in a vacuum they *really* don't fall
>at the same rate (difference is very small, order of 10^-24) <this *makes
>sense*>

Nah, this is NOT true according to Einsteinian General Relativity, and
no one has ever done an experiment sensitive enough to detect that.
All bodies, in a vacuum, fall at the same rate--the result of
Galileo's Tower of Pisa experiment, and a cornerstone of Einstein's
theory, in which it is called "the Principle of Equivalence".

However, the main unsolved problem of today's physics is the "Theory
of Everything", which would put all four of the forces together into
one logical framework.  The three strongest forces all coexist nicely
in a theoretical framework called "The Standard Model", whose
framework is essentially quantum mechanical.  No one has yet got a
decent theory of quantum gravity, nor done any experiments that would
expose the quantum mechanical nature of gravity.  But everyone (in
physics) believes there ought to be such a theory that would unify all
the forces.  The present dominant line of theoretical investigation is
called "Superstring Theory", which claims, among other  things, that
the dimension of space-time might be as high as ten.  But superstring
theory has not yet made any predictions that are subject to
experimental verification under present experimental technology.  I
don't know but mabe you or someone has heard that some of the results
of string theory predict a departure from the Principle of
Equivalence, but I haven't heard of it, and certainly no one has
observed it in experiments.  For a good popular review of the present
state of this knowledge see the book "The Elegant Universe" by Brian
Greene.  "A Brief History of Time" was an enormous best seller in the
80's and 90's.  Greene's book was a best seller last year.

>
>i am just curious what is the *the few on this list*  knowledge about
>this...
>
>i recently (3 minutes ago) got in an argument with a friend on this *topic*,
>he told me his professor said that "Gravity is a FORCE" and saying anything
>different from that is pure anarchy.
>
>i told him what is above is true and André Lamothe writes this in all of his
>books, and i'm pretty sure he knows more than your professor (the laws make
>sense as well), ...

>i am probably just t-ed of cause i didn't have more proof about the space
>time fabric one :|
>

Don't be teed off--change your career and study physics. The proof is
in the elegance and economy of the theory and the fact that it has
been completely confirmed to within the precision of all experimental
tests so far.

>btw, andre, if your not on the list;
>i highly suggest you join :) i know your busy with volume 2 and all..

This comment reminds me of the sign in the post office:  "No dogs
allowed, except seeing-eye dogs".

Re: [Algorithms] rather curious

[Alex M. <am...@bw...>]

----- Original Message -----
From: "Ron Levine" <ro...@do...>
To: <gda...@li...>

> expose the quantum mechanical nature of gravity.  But everyone (in
> physics) believes there ought to be such a theory that would unify all
> the forces.  The present dominant line of theoretical investigation is
> called "Superstring Theory", which claims, among other  things, that
> the dimension of space-time might be as high as ten.  But superstring

    Ummm, hrmmm, correct me if I am wrong, but the number ten is based off
of KSV (Kikkawa, Sakita, Virasoro) diagrams, which produce modular
functions, that just seem to spit ten back in extremely bizarre places.
Also, noting that ten is not the only number, as 26 has also been proven to
work for superstring theory.... but I digress....

> observed it in experiments.  For a good popular review of the present
> state of this knowledge see the book "The Elegant Universe" by Brian
> Greene.  "A Brief History of Time" was an enormous best seller in the
> 80's and 90's.  Greene's book was a best seller last year.

    I would also read, for the laymen, Hyperspace by Michio Kaku. Simple,
elegant, and my cat can understand it.


> Don't be teed off--change your career and study physics. The proof is
> in the elegance and economy of the theory and the fact that it has
> been completely confirmed to within the precision of all experimental
> tests so far.
>
> >btw, andre, if your not on the list;
> >i highly suggest you join :) i know your busy with volume 2 and all..

    Yeah, only on chapter 8, and he made another (edited I believe) in the
meantime.

_________________________
> GDAlgorithms-list mailing list
         /.\
          |
          |
 Whoa, where did the word physics go....


ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full
version. All important social functions will be disabled from now on.

RE: [Algorithms] rather curious

[Akbar A. <sye...@ea...>]

>Nah, this is NOT true according to Einsteinian General Relativity, and
>no one has ever done an experiment sensitive enough to detect that.
>All bodies, in a vacuum, fall at the same rate--the result of
>Galileo's Tower of Pisa experiment, and a cornerstone of Einstein's
>theory, in which it is called "the Principle of Equivalence".

i'm currently doing some reading on General Relativity, <Physics for
Scientists and Engineers, by Raymond A. Serway, 3rd edition. Copyright is
pretty old>

But,
what i brought up is that if we go by Newton's law of universal gravitation
there is a *difference*

>All bodies, in a vacuum, fall at the same rate-
if we take this formula
F = G ((m1*m2)/r^2)

and we run this for 2 separate objects with *very similar* masses,
F will be different.

F = ma;
a = F/m;

even at a *tiny precision* they still fall at different rates, thus hitting
the surface at a different time.
hence i feel that this should be taught in schools at least for a
"technical" viewpoint cause it's the *right thing* to do.

*before you write anything read below ;)

>But in the several dozen experiments where GR predicts a
>measurable difference from the predictions of Newtonian gravitational
>theory, GR has been confirmed.

with the knowledge from above i see what *you mean*, but i still have to
read those books to *understand* and *see the differences* ;)
as well as to understand the essence and derivation of these theory's.


i have always thought adding any 2 arbitrary numbers will always give the
output of the sum of those 2 numbers.
i guess maybe in this level these "elementary" rules do not apply (note: i'm
a  making parallel here)?




*******
*******
this is "non-technical" and is based entirely on my ways/experience with the
"World(Tm)".
also a reply from Ron about switching career field to physics.
this is very biased :)

please DO NOT send reply's to the list about *this* unless you feel it
pertains to "gaining "technical" knowledge" " ;)
*******
*******


or maybe this is the same case with the definition of "light" (
"it's a wave, wait a sec, in this case it's acting like a particle"
here is a conversation with a truthful researcher and on of the chairs on
the book community.

my question is, why can't they just come up with a "new" definition/name,
which combines both of the properties and merges them into one?


btw, speaking of the universe and all, and somebody mentioned string theory,
faster then light issues, etc..
http://www.superstringtheory.com/basics.html
haven't read through it yet, but it "looks" somewhat legit mate.
we all know that looks can be deceiving though.




>Don't be teed off--change your career and study physics.
;)

a.) academia is not my cup of tea ( i have change my ways ;), i have *no*
idea how some of you manage to stay in school for +6 years. i guess if you
like it...

b.) to get a *decent* (imho gov jobs don't count<pay to low>) job let alone
doing research/getting paid in that field you have to have a highly
appraised *background*, and *just* going to oxford doesn't cut it.

c.) don't get me started on thesis's and some issues with proffeesor/deen
pride...

d.) i like the way carmack summarized this up (full time physics people),
the people in that field have to wait a long time to get there ideas built
up into a reality.
some times they wait years for the "authorization" to happen. then there is
organizing the team, building the facilty if it doesn't exsist, etc..

for us in the cg/real time field, we think of something and do it the next
minute :)


e.) yes, writing missile tracking software is *very* cool, this is physics
and just about every other problem in "real life at work" (Tm)!
but the restraints your stuck with are mind blowing.
imagine waking up every morning to restrains like, ("your code segment is
WAY to big, the MEMORY think of the MEMORY!") and your trying your best...

i wonder what types of hardware(memory,cpu) there running for the new missle
guidance systems.
hehe.

i really admire those guys, as well as console developers who manage to
squeeze technically cool stuff through there hardware limitaions...
a good example would be the software team which was responsible for porting
Resident Evil 2 to Nintendo 64.
see gdmag (www.gdmag.com)  for more details.
there might be an article up about it at www.gamasutra.com ?


peace,
akbar A.

"imho, and i'm sure in yours as well, this entire universe follows out a set
of equations...
the objects of course "

// couldn't fit this anywhere else ;)






-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Ron
Levine
Sent: Sunday, September 10, 2000 10:51 PM
To: gda...@li...
Subject: Re: [Algorithms] rather curious


Akbar A.  wrote:

>hey,
>i am just wondering, but how many people know about *this*
>"gravity isn't really a force" and that it is caused by the curvature in
the
>space time fabric.
>

Of course, this thread is entirely off topic with respect to game
algorithms in the ordinary sense (unless of course you want to make
relativistic physics the object of the game :-)).  But physics is one
of the best subjects to be "rather curious" about, so no one has
objected so far.

In the modern physics paradigm,  gravity is one of the four basic
forces,  and,  by many orders of magnitude,  the weakest of the four.
The other three are called (in order of increasing strength), the weak
force (which, for example,  is responsible for the decay of neutrons
into protons, electrons and neutrinos), the electromagnetic force
(which is responsible for all of chemistry, optics and all other
electromagnetic interactions), and the strong force, (which is
responsible for the binding of quarks into protons and neutrons, and
the binding of protons and neutrons into atomic nuclei.  There has
recently been a buzz about some experimenters claiming to have
discovered a fifth force, but it has not yet entered into the
mainstream physics paradigm.  So, in terms of modern physics it is
perfectly OK to call gravity a force.

But in this paradigm, gravity is indeed also understood as a
phenomenon of the curvature of the space-time "fabric", necessarily
caused by the presence of energy (including mass).  You can completely
understand the orbits of bodies under the gravitational force as
motion along geodesics, i.e. paths of shortest length, in the curved
space-time.

The mathematics that you need to put this all on a sound
logical basis is higher-dimensional differential geometry and tensor
analysis.
This is the framework of Einstein's General Theory of
Relativity.

For the most part, for most ordinary experimental
observations, General Relativity predicts the same behavior as the
classical Newtonian gravitational model, up to the precision of
experiments.

But in the several dozen experiments where GR predicts a
measurable difference from the predictions of Newtonian gravitational
theory, GR has been confirmed.  Read any popular book on modern
physics, such as Stephen Hawking's "A Brief History of Time" for a
non-mathematical review of these ideas, experiments and astronomical
observations.  If you want the real stuff, the best book is
"Gravitation", by Misner, Thorne, and Wheeler, but it is daunting.

>And, if you drop two objects in a vacuum they *really* don't fall
>at the same rate (difference is very small, order of 10^-24) <this *makes
>sense*>

Nah, this is NOT true according to Einsteinian General Relativity, and
no one has ever done an experiment sensitive enough to detect that.
All bodies, in a vacuum, fall at the same rate--the result of
Galileo's Tower of Pisa experiment, and a cornerstone of Einstein's
theory, in which it is called "the Principle of Equivalence".

However, the main unsolved problem of today's physics is the "Theory
of Everything", which would put all four of the forces together into
one logical framework.  The three strongest forces all coexist nicely
in a theoretical framework called "The Standard Model", whose
framework is essentially quantum mechanical.  No one has yet got a
decent theory of quantum gravity, nor done any experiments that would
expose the quantum mechanical nature of gravity.  But everyone (in
physics) believes there ought to be such a theory that would unify all
the forces.  The present dominant line of theoretical investigation is
called "Superstring Theory", which claims, among other  things, that
the dimension of space-time might be as high as ten.  But superstring
theory has not yet made any predictions that are subject to
experimental verification under present experimental technology.  I
don't know but mabe you or someone has heard that some of the results
of string theory predict a departure from the Principle of
Equivalence, but I haven't heard of it, and certainly no one has
observed it in experiments.  For a good popular review of the present
state of this knowledge see the book "The Elegant Universe" by Brian
Greene.  "A Brief History of Time" was an enormous best seller in the
80's and 90's.  Greene's book was a best seller last year.

>
>i am just curious what is the *the few on this list*  knowledge about
>this...
>
>i recently (3 minutes ago) got in an argument with a friend on this
*topic*,
>he told me his professor said that "Gravity is a FORCE" and saying anything
>different from that is pure anarchy.
>
>i told him what is above is true and André Lamothe writes this in all of
his
>books, and i'm pretty sure he knows more than your professor (the laws make
>sense as well), ...

>i am probably just t-ed of cause i didn't have more proof about the space
>time fabric one :|
>

Don't be teed off--change your career and study physics. The proof is
in the elegance and economy of the theory and the fact that it has
been completely confirmed to within the precision of all experimental
tests so far.

>btw, andre, if your not on the list;
>i highly suggest you join :) i know your busy with volume 2 and all..

This comment reminds me of the sign in the post office:  "No dogs
allowed, except seeing-eye dogs".

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] rather curious

[Jeff L. <je...@di...>]

Man, we are all working late tonight.  On a sunday, that's kinda sad.
But to drag this back to algorithms, your use of Newton's gravitation law is getting you into trouble.  

Realize that the only thing that effects when two dropped objects hit the ground is the acceleration of those objects.  Force doesn't enter into it yet.  Here is why:

Gravity is as you say F = (Gm1*m2)/r^2, also thanks to Newton we have F=ma.

Solve for the acceleration using those two equations:

m1a =  (Gm1*m2)/r^2     // note the m in f=ma is for the dropped body which I am calling m1.

a = Gm2/r^2

The acceleration of body 1 is only dependent on the gravitation constant, distance, and the mass of the earth (or whatever).  On most of the surface of the earth as you know that a = 9.8 m/s^2.  I guess at airplane height, it is a bit different.

So you can see that a body of any mass will hit the earth at the same time.  The difference due to the original gravitation law is that a more massive body will hit the earth with more FORCE and make a bigger dent.

Of course this ignores the fact that the formulas need to be applied to the earth as it is attracted to the other object.  If the object being dropped was very massive, it would move the Earth also.  This would change the time of collision.  Of course for most objects you will ever be able to drop, this doesn't matter.

-Jeff

At 01:21 AM 9/11/2000 -0500, you wrote:
>But,
>what i brought up is that if we go by Newton's law of universal gravitation
>there is a *difference*
>
> >All bodies, in a vacuum, fall at the same rate-
>if we take this formula
>F = G ((m1*m2)/r^2)
>
>and we run this for 2 separate objects with *very similar* masses,
>F will be different.
>
>F = ma;
>a = F/m;
>
>even at a *tiny precision* they still fall at different rates, thus hitting
>the surface at a different time.
>hence i feel that this should be taught in schools at least for a
>"technical" viewpoint cause it's the *right thing* to do.

Re: [Algorithms] rather curious

[<ro...@do...>]

Jeff Lander  wrote:

>Man, we are all working late tonight.  On a sunday, that's kinda sad.

Nah,  I spent a pleasurable day listening to a free concert by the San
Francisco Opera in Golden Gate Park, and am so wiped out by sunburn
that sitting in front of the tube and pontificating on physics is an
entirely appropriate activity.

>But to drag this back to algorithms, your use of Newton's gravitation law is getting you into trouble.  
>

>Realize that the only thing that effects when two dropped objects hit the ground
> is the acceleration of those objects.  Force doesn't enter into it yet.  

Actually, in most developments of the logical foundations of physics
that I've seen I think that  "force" isnot well defined.  In the way I
was using it, in terms of the "four forces",  it refers to a type of
"interaction".

>....
>So you can see that a body of any mass will hit the earth at the same time.  
>The difference due to the original gravitation law is that a more massive body
> will hit the earth with more FORCE and make a bigger dent.
>

Here, I think your use of "FORCE" is not appropriate.  The two bodies
fall under the same acceleration, so fall for the same time duration
and hit the earth with the same speed, but the more massive body has
more kinetic energy and more momentum, so makes a bigger dent. 

Re: [Algorithms] rather curious

[Steven C. <sc...@ti...>]

Ron Levine wrote:
> 
> >....
> >So you can see that a body of any mass will hit the earth at the same time.
> >The difference due to the original gravitation law is that a more massive body
> > will hit the earth with more FORCE and make a bigger dent.
> >
> 
> Here, I think your use of "FORCE" is not appropriate.  The two bodies
> fall under the same acceleration, so fall for the same time duration
> and hit the earth with the same speed, but the more massive body has
> more kinetic energy and more momentum, so makes a bigger dent.

But I thought (possibly naively), that by definition Force = Mass *
Accelleration, hence more mass, more force (for a fixed accelleration,
ie gravity).

Or are you saying the cause of the dent is momentum, not force?

Just rambling,
Steve

-- 
Steve Clynes
sc...@ti...
"Help stamp out and eradicate superfluous redundancy "