Newsgroups: rec.arts.int-fiction
Path: gmd.de!ira.uka.de!yale.edu!newsserver.jvnc.net!howland.reston.ans.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!world!tob
From: tob@world.std.com (Tom O Breton)
Subject: Adventure interface, Physics
Message-ID: <C34yLt.LJx@world.std.com>
Keywords: physics,vr,virtual reality,interface
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 28 Feb 1993 01:53:52 GMT
Lines: 136

Phil:

I like your model. It's quite specific.

I nitpick anything which I like, so please take the following as a
compliment:

> INTERACTIONS OCCUR AS A RESULT OF PHYSICAL PROPERTIES, NOT CODING
> Say you want to open a door with a key. [...]

I think you're discarding rather a lot of power there.
It seems to me that some important things are better modelled by
"magical" interactions that happen when surfaces come in contact than by
detailed physical modelling.(*)

In other words, when they come in contact they can invoke other
functions besides the usual each-bounces-off-the-other.

This opens up lots of possibilities, such as surfaces that have a high
effective momentum when pushed by some things and a lower one for
others. (The extreme is surfaces that can only be pushed by certain
things.) Or surfaces that some things can pass right through and others
can't.

For instance, a flame burning things. "Magical" surfaces do it almost
trivially - what it touches gets burned. I don't want to imagine what
complexity it would take to do it with physical modelling.

For another instance, to model different keys (Presumably you don't want
one key to open everything) physically you end up with unholy detailed
models from locksmithing books.  Magically, you give both key and plate
an identity, command that the plate can only be moved by the correct
key, and you're done. (You can do it even simpler with magical surfaces
but you start to lose too much realism.)



> 1.  What if you bounce a ball against a poster on
> the wall?  The poster has little mass, so most of the momentum goes to the
> poster.  The poster won't move, because the wall prevents it; the ball will
> drop directly to the ground instead of bouncing.

Poster and ball bounce. Poster and wall bounce. Poster and ball bounce.
Poster and wall and toaster and Paul bounce. Tweedle beetles battles in
a puddle in a bottle. (Oops. I Dr.Suessed out for a sec.)

So it looks like we'll need some rules to handle force transmission
without executing a large number of binary collisions.

The way I like best is to make objects act as part of other objects.
Give them a 3-D "envelope" of forces that might act on them. When
there's a collision, check if the force vector is inside that envelope.
If so, simply calculate it on the group as a whole. Otherwise, detach
them.(**)

We could give surfaces different "stickinesses" so that the poster would
becomes part of the wall despite gravity while other things just fell.

We could even build everything from little bricks with large envelopes,
so that things could break realistically without incurring a lot of
overhead.


> But I can think of no way of specifying that a metal block does not
> bounce if dropped onto a metal floor, yet will move away if you hit it
> with a metal bat.

Er, I don't see the problem. Elasticness just determines how much of the
collision force is lost (becomes heat, if you care to model that)
When more than 50% is lost, it won't bounce up.

Getting into the calculations, you add the resultant force of the
collision to the falling anvil's momentum; you find it is insufficient
to reverse the anvil's direction.


> B. Every object within a certain distance of you - any distance metric that
> is easy to compute -

I suggest that being out of sight is a criterion to emphasize.


> Object A "supports" object B if object A is in contact with B along the
> surface of B which is selected as the "bottom" at that timeslice.
> [...]
> So, if block B is 4 meters long, and 1 cm of it is over table T, T supports B.
> This is bad.

Hard to do without allowing rotation. If it can't rotate, how can it
fall off? Only by going through the table!

It doesn't seem that hard to add rotation to collisions/support. Here:

Looks like you're not modelling a centre of gravity. For binary support
or a binary collision (EG an object against the ground):

If both CoG's fall inside the region of contact (along a line parallel
to the direction of collision), you have a simple straight-on collision.

(Note that with my earlier multiple-objects-treated-as-a-whole
suggestion, simple binary collisions/support becomes more common and you
can get larger regions of contact.)

Otherwise you calculate the angular force (torque) around the CoG's.

Quick and dirty calculation:
Pretend they're connected, as if they were both on the rim of a wheel.
And that they're each exerting force of the collision on this wheel.

Remove the component of them that is pointing toward the hub of your
imaginary wheel - use that part as an ordinary straight-on collision.
The rest becomes angular momentum.  (Draw it -- the remaining part of
the vectors are parallel to the "rim" in opposite directions)

You also have to know both objects' distribution of weight to know how
fast it rotates for a given angular momentum. For example, dumbells
won't rotate much for a given angular momentum, whereas a small wheel of
the same mass will go a lot faster. To simplify, you might give
everything the same angular mass.


> I think this could be a cool topic for my PhD dissertation,
> provided I emphasize VR and not IF.  What do you think?

Go for it!  }:) Care to send me a copy when you're done?

        Tom

(*) You're welcome to use this idea in your dissertation if you like.
Please credit me if you do, since it is original (As far as I know).

(**)  Ditto for this idea.

-- 
The Tom spreads its huge, scaly wings and soars into the wild sky...      
(tob@world.std.com)
