From: marc%remarque.Berkeley.EDU@ucbvax.Berkeley.EDU (Marc DeGroot)
Subject: Re: SCI: Object behavior in VR
Originator: hlab@stein.u.washington.edu
Organization: Eukaryotic
Date: Sun, 11 Oct 1992 18:30:10 GMT



Dave Stampe writes:
<<
I'm not sure either Scheme or Forth are a good idea.  The problem can
be summarized: is it efficient and is it required?

For efficiency, any action taken by a program will have to call on
routines that are part of the world-structure support, even one as
simple as create(), destroy(), move(), etc.  This assures portability
and high efficiency.  It is trivial to create a set of "standard"
actions for, say, animation that would be run on a "real-time" basis.
Letting the world programmer have access to the interrupt-driven paths
of the program directly could result in a "hung" program very quickly.
I'd prefer to try to build an interface to all the scheduling stuff,
with data structure definitions for the interface.  Real time
multitasking is OK, but if you do something 1000 times per second (i.e
testing if an object has collided) then it's best left to the
programmers who code the system so efficiency can be guaranteed.
>>

Whoa! 1000 times a second?  Are you really going to try to test for
object collision on a real-time basis?  What happens if there's 1000
objects in your space?  What happens if the processor just can't keep up?
For collision, the best thing is to solve the simultaneous equation of
the two objects' trajectories and see if they overlap.  That way, you
can visit the collision code only 5 times a second without fear of missing
a collision.  

Dave Stampe writes:
<<
Now the question is, why use Forth?  I don't really see any advantages
myself, except those that rely on the simplicity of the interperter.
But Forth can be very inefficient, with more instructions executed to
perform a task.  So why not use a C varient?  Arguments about
compiling speed are not really valid.  I can completely recompile
REND386 in 3 minutes, and the usual modify-compile-test cycle is about
20 seconds.  In the case of a C varient based on data structures for
>>

You say that the simplicity of the interpreter is the
only feature that recommends Forth.  This assertion deserves further 
scrutiny, but I want to address a different issue here. 
It sounds to me like you're talking about developing code for a single-user
stand-alone system.  You're thinking about how you like to do code development.
That's fine.  I'm not trying to take away your development platform or 
language.  I'm looking for a way to transmit pieces of the universe from
one machine to another and have two or more users interacting in a room
in cyberspace together.

I'm thinking about a scenario like this:
I'm walking down the street in cyberspace, and I arrive at the door
of your building.  I ring the door bell, and you authenticate me and
admit me, whereupon my avatar in cyberspace is allowed to pass through
your door.  Once inside, I see a room in your building.  There are five 
dodecahedrons lazily spinning, colliding with one another and the walls.  
Your avatar is also in the room, moving about occasionally.

I want to talk about what happens when I pass over the threshold of your
door.  (The ringing of the door bell and the authentication process
deserve a thread by themselves.) My local processor needs to have the 
information about all the objects in your dodecahedron room, in order 
to render them.   Your processor must send me the coordinate 
points of the vertices of each object (or some other representation) 
as I step into your dodecahedron room.  Your processor also has to 
hand me other crucial pieces of information: How do the objects behave?
I need to know (1) about the actions of your avatar in the room; and (2) about
the actions of the dodecahedrons.

The information about your avatar must be transmitted to me over the net, 
and hopefully the latency will not be too bad, otherwise I won't see you move
in real time.

For the dodecahedrons' behavior we have a choice:
1) You run the entire simulation on your processor and transmit
   position and orientation data over the net to me;
2) You download the simulation code to me and I run it locally,
   and we periodically make sure we're synchronized over the net.

(1) is fine for a small number of objects, and low latency
(lag time) over the net.  But for 100 or 1000 objects, (2) is the
only system that makes sense, from a network bandwidth standpoint.

If that's the case, then what language should the code be written in?
Dave, I believe you'd agree that C is not the correct answer.  Even with
the compilation times you can get on a fast 486, the application argues
heavily for pre-compiled code that is interpreted.  Pre-compiled because
there really isn't time to compile the downloaded code, and interpreted
for portability and consistency across multiple platforms.  Yes, C can
be byte-coded and interpreted, but it is the wrong choice for several
reasons.  The language was designed ONLY with compilation in mind.  
Regardless of the speed of your C compiler, Forth will ALWAYS be able to
compile faster, like as fast as you can type.  Yes, literally.  If I showed
you how simple the Forth compilation process is, you'd agree.

"Mr. Sweet" writes:
<<
Also, lots of people got fed up with jerky garbage collection years
ago, and came up with various algorithms that collect a little at a
time.  Thus, in the main interaction loop you can continuously collect
a little each time without the user noticing anything.  One technique
is called "generational" GC, and exploits the fact that 80-90% of all
data lives for <1/10 of a second.  Generational GC tends to build up
medium-lifetime garbage, though.
>>

Very interesting technique.  I didn't know about that.

"Mr. Sweet" writes:
<<
I will probably switch over to Dylan at some point, if it appears with
a compiler/interpreter system as good as DEC's Scheme->C.
>>

Can you tell us more about it?

Michael Almquist writes:
<<
Yep, another good point and hopefully a good question: So?  Who came
down from the mountain top and said data-flow is the key and the way?
I hope it isn't - like most everything, dataflow has its strengths and
weakness - we need to look further.
>>

Agreed.  When I mentioned data-flow diagrams, I was pointing out that
Forth's extensibility doesn't restrict the paradigm that one uses to
model the reality.  If data-flow diagrams do it for you, you can have them.
If object-oriented programming does it for you, you can have that.  If you
really want to code in C, there is a C compiler that turns out Forth code
from its code generator.  Not that I necessarily recommend one approach over
another -- the point is that they're ALL usable from Forth.

"Mr. Sweet" writes:
<<
I've since realized that Smalltalk is probably the best language for
doing a "virtual desktop" aka a 3D real-time work environment, since
user interface prototyping is exactly what Smalltalk was o developed
for.  GNU Smalltalk has a nice C extension interface, and comes with a
DOS port (I think).  It should make a very nice front end for Rend386.
>>

Smalltalk is a language that I have too little experience with.  I will
be interested to see what you do (or someone else does) with it.

Anyway, in light of this thread I believe the best thing to do is the following:
In the data structure for the object, provide two pointers for the behavior
code: a pointer to code, and a pointer to data.  That way, Dave can write
his routine in C, and put the pointer to the code in the data structure.
When his code is called, it is passed an optional pointer to data.  For my
purposes, I can put the pointer to the Forth interpreter's entry point in
the code pointer, and I can put the pointer to my compiled Forth code in
the pointer to data.  Mr. Technically Sweet can put similar pointers in
for his Scheme code.

Peace.

-- 
Marc de Groot (KG6KF) San Francisco |
Internet: marc@kg6kf.ampr.org       |      "Penny for your thoughts, twenty
UUCP: ..!uunet!hoptoad!noe!marc     |          cents for your paradigm."
Packet radio: KG6KF @ K3MC          |
Newsgroups: sci.virtual-worlds