From: broehl@sunee.waterloo.edu (Bernie Roehl)
Subject: Re: TECH: world description
Date: Mon, 13 Jul 1992 13:05:57 GMT
Message-ID: <BrBwDy.FAq@watserv1.waterloo.edu>
Organization: University of Waterloo


In article <1992Jul12.223503.12374@u.washington.edu> Jerry Isdale <72330.770@CompuServe.COM> writes:
> There is a fair bit of discussion about multi-user and other distributed VR
>applications. This is great, but there is a tremendous amount of ground work
>in getting a single user system up.

Agreed.  I guess the main thing is that whatever we develop as a single-user
system should be designed with network extensibility in mind (to avoid having
to re-think everything when we go to a networked VW).

>Some of us have VR machines that would support a TCP/IP
>(internet) connection, some might have only local networking, many of us might
>own only a single user PC. I'm a representive of the latter. I dont have a
>direct Internet connection at present, only this mail-only Compuserve link. 

I believe that any networked VW should be very network-independent, and should
not have built-in assumptions about the underlying networking technology.

If you're running any reasonable kind of LAN, or even just a couple of
machines hooked up together via their serial ports, you should be able to
implement a shared VW.

> The scripting of object motion, interactivity and behavior is a major area 
>that needs to be addressed.

Agreed.  For standalone worlds this is especially true -- otherwise they
become static and boring.

> Consider them the next step up from the static world fly through... an 
>animated world you can fly through. 

And from there it's a (very) small step to animated objects that respond
to your presence, and to each other.

>[...] beyond what I want to consider at present (neural net controllers,
> genetic sw, etc).

One reason for going to networking is so that you can implement these things
on other machines (instead of having your rendering station also have to
do neural net simulations, for example).

>Interactivity can be done several ways. You might have a GRAB function, 
>[...] There is also the simple when-touched-explode/beep or pick-up &
>add to inventory functions that would be easier to script.

Right.  What I would suggest (actually, I'm just quoting others who have
suggested it) is some sort of threated interpretive language (e.g. Forth).

The advantages are:
        - small
        - fast
        - easy to implement
        - portable
        - extensible
        - lends itself well to multi-tasking on single-task machines

Does anyone know of a Forth implementation where the inner interpreter is
written in C?

>  There is a LARGE area here to be explored. I dont want to see pull down 
>menus, or other crude 2D widgets only. They have their place, and might be 
>useful for some window-on-world vr apps. The control panels in VR Studio 
>are an example. The next step would be to move the 2D panel off the window 
>frame and into the 3D world. It would still be a 2D widget on flat panel, 
>but the panel could float and be moved. 

Yes.  I can see a VR Studio-like interface initially, and then a progression
to a true 3D set of controls.

>There are conventions for 3D control widgets that need to be developed. 
>Simple controls for manipulating an object, ways to display types of data 
> The world description should have some way of designing (scripting) control 
>panels. (i think in terms of worlds designed by one person to be experienced 
>by others for many VR applications).

This sounds very good to me.  I'd also like to provide the flexibility of
a customizable user interface, so you can have your control panel and I can
have mine and we're both happy.

>Thats enough for now, i've got a new baby to go take care of.

Congratulations!  And thanks for some good ideas...

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
	BangPath: uunet!watmath!sunee!broehl
	Voice:  (519) 885-1211 x 2607 [work]