

VRREP4.TXT                     
report-Virtual Reality section 
Computer Art forum             
CompuServe                     
John Eagan-76130,2225          


CONTENTS>

1> Group 3
     (John Eagan-76130,2225)

2> Summary of Group 3 Activities
     (Jerry Isdale-72330,770)

3> Conference Technical Notes
     (John Eagan-76130,2225)


Group 3

Introduction to Group 3

For those of you new to the Virtual Reality area of COMART, "Group 3" is a
software development team dedicated to developing VR software capable of
running on low cost systems (relatively speaking!), with plans to support
as many different machine platforms as possible. The project leader for
Group 3 is Jerry Isdale. The current project has been under the working
name of "World Editor/ World Player". More on this follows in this report,
and other information may be found in the libraries by searching on the
filename WE*.*.

The Team Concept

Those of you who have been following this section for some time know that
there has been a fair amount of activity and discussion of the World
Editor project. You also realize, or should, that not an awful lot of
concrete results have come forth in terms of actual software. There has
existed, to date, a serious amount of scattered efforts and opinions
regarding goals and direction. This is a very serious problem, which must
be corrected, if any positive results are to come of all this.

For those of you who don't know, there are hopes of getting an independent
VR forum. For those of you who don't know, there is essentially no chance
of this happening until we have working software for VR to show for our
efforts. This is not something I agree with, quite the contrary in fact. I
believe that there is plenty of justification for a VR forum, regardless
of whether or not we have our own software, and associated "world files"
of data to use with said software. However, this opinion counts for little
among those who make decisions at CompuServe. The "bottom line" here is
that to set up a forum, the administration of CompuServe has to see enough
activity, and enough library files of interest, to convince them that
enough people will spend enough time in the forum to build up a
significant amount of connect time charges, to make the forum profitable
enough to make it worth the expense and time required to set up and
maintain a forum. A forum doesn't come into existence at the snap of a
finger. A forum won't come into existence by wishing really, really hard.
A forum won't be created just because "VR is a really cool subject!". This
is the reality here.

The existence of a VR forum would have many advantages. There would be
room to have separate libraries and message boards in different subjects
in virtual reality. Programmers, hardware types, philosophers, fiction
writers and readers, all could have areas devoted to their own favorite
subjects. Foremost of all, the greatly increased visibilty of a forum, as
opposed to a section within a forum, would no doubt attract much more
interest and activity, as people interested in the subject would discover
the forum more easily than they would happen to find out about a section
on VR in the Computer Art forum. The fact is, unless we produce interesting
finished work, that people can download and use, a forum won't happen.

If we DO produce usable software, we could have something that would be a
small revolution in computer technology...virtual reality as something
accessible by people with desktop computers, who can create their own
"virtual worlds" and play with them, or share them with others, or
download "worlds" created by others. People could create "computer art"
that is not merely an electronic still image, or an animation, but a true
interactive electronic environment that could be a work of art that you
can play with, be active with, rather than passive images. There is an
extraordinary opportunity here. The unique nature of the online
environment, allowing rapid communication among people, with the ability
to share complex information through text and graphics, means that team
efforts of an entirely new kind can happen. We can, literally, "build
cyberspace IN cyberspace".

This effort requires a special level of discipline and cooperation,
however. In the area of VR, this is especially vital, simply because this
is an area where there are no standards yet. Because of this last point,
in particular, there is an extra effort of communication and cooperation
required here.

We have, in the person of Jerry Isdale, somebody who has a strong
background in graphics programming, across many different hardware
platforms and operating systems. He has accepted the challenge of leading
the group effort in the software projects of Group 3. The main problems so
far in development are not from lack of ideas, or talented programmers,
but the fact that people keep going off in different directions on their
own. Ideas are raised, and some people agree, some don't pay attention,
others examine an idea and simply say "no! that's not the way! I want
THIS!..".

If anything of value is to be accomplished here, in terms of software, in
terms of "world" data files to share, we need to all be working along
similar lines. This is not only important for setting and reaching goals
of having software of our own, freely available, but just as important,
the biggest single advance we could make is to help create a "defacto"
standard for the format of data files for sharing virtual worlds. This
group could help do as much, or more, as anybody or any institution in
setting standards for VR. The implications and potential benefits in
having standards for the field of VR should be obvious to all.

To this end, I need to make it very, very, clear, that if we're going to
make progress on the points I've mentioned, there is one overall,
absolutely _vital_ point I must make. That is, go through the Project
Leader! Make suggestions of ideas you have, in the message base, so
everyone can see them and comment or question. Address ideas, questions,
and comments to Jerry. When Jerry comes to a decision on a particular
point, or asks for development of certain ideas, LISTEN!! If he asks for
help on particular assignments in the project work, help him out! If there
are questions or uncertainties about specific goals or methods, discuss it
in the message base, or in conference, or both. If you have ideas or code
to put out for public analysis, development, and consideration, consult
with Jerry.

Most of all, understand that Mr. Isdale is not a tyrant, he is not a
dictator, he is not an egocentric megalomaniac. He has plenty of
experience in the field of computer graphics, and is probably as well
versed in the technology, and well informed about the current state of the
art of virtual reality, as anybody here. In short, he knows what he's
doing. If after discussion of ideas, he comes to a decision or position,
you can be quite sure that he has very good reasons for that decision. Do
what he asks, if you want to see VR at this level become reality. Trust
his judgement, and once he settles on a particular plan of action, do all
that you can to fulfill that plan. I cannot possibly stress this idea
strongly enough.

If my role as the section leader is to help guide, direct, and lead this
section toward tangible progress, then this is the most important thing I
can state toward that end. We have a project leader. Take that role
seriously. Jerry does. I do. The absolute single most important issue that
will decide whether this project group and this section succeeds and opens
up a brand new frontier in personal computing, or dissipates and decays
into oblivion, is whether or not there is a dedicated, united, cooperative
effort in this project, and that single essential point is completely
dependent on the cooperation and respect given to the project leader.
Please bear this in mind.



Summary of Group 3 Activities
April 1992
Prepared by Jerry Isdale [72330,770], Project Leader 

Overview

Group 3 is the name of the development group that is creating the World
Editor/World Player system. It is a very ad hoc group. There are a number
of subgroups (or individuals) who are working on various concept
demonstration projects at present. At present, there is no formal
specification or description of the project. (This should be a high
priority item)

Prior months have given us some basic building blocks such as the Nintendo
Power Glove and Sega 3D glasses interface, and The Rend386 renderer from
Dave Stampe via Internet. Not much has been done with the PG, although DS
has promised some updated code, possibly integrated with his renderer. We
should see that sometime in May (?)

[note: the new version of RND386 is now in the library-JLE]

The commercial program 'Virtual Reality Studio' was the subject of some
more discussion and a few uploads at the end of March got some discussion.

April Activities

John P. Tighe [72730,574] uploaded a sample world player (renderer)
written in C++ (wpjt00.zip). There was subsequent discussion of the
program architecture in the message threads. The folks from DPRC
[75530,3041] gave the program a very thorough review. Their comments can
be found in WEDP01.TXT. John is currently rewriting the system using
straight C. 

Omar Loggiodice [74040,1543] and Adam King [71031,3303] are working on an
example language and parser for the the project. There should be some
working stuff from them during May (or June <g>).

I (Jerry Isdale) uploaded a set of musings on the project (weji01.txt)

John Eagan [76130,2225] has been editing and uploading message traffic
from the Internet newsgroup sci.virtual-worlds. (see s*.zip, keywords "VR
and "SVW") These files contain interesting discussions of VR, including
some very good tech discussions. I heartily recommend reading them.

Other Notes:

Contact was made with a group over in the Flight Simulator Forum that is
working on a public domain FS. There could be considerable overlap & cross
pollenation with them. Also some efforts of the Raytrace folks on ComArt
to produce a pd GUI and modeler are of interest. (see aewire.zip in the
raytrace sources library, and the Modeler threads of this past month)



Conference Technical Notes

Preface

In the online conference of Sunday May 31, 1992 (VRCO29.TXT in the
library) Jerry Isdale spoke a bit on setting some guidelines, goals and
directions. The full conference log is in the library, but I've distilled
the main statements from the log for clarity here. I've edited the log to
put the conversational nature of conference discussions into clearer
written text. <John Eagan>

Jerry Isdale:

Folks, i'd like to take a few minutes and put forth some ideas for
technical considerations. In the last CO I mentioned some reading I've
done recently, mostly about the VR systems being done by the Big folks,
many of them are taking a fairly open system design, like the VEOS (HITL)
VUE (IBM) and Cyber?? (Adesk). These systems are generally multi-tasking
and are more concerned with connecting various peripherals to objects and
renderers. This workbench approach allows them to  substitute different
input devices, renderers, etc. However, we don't have the luxury of a
multitasking OS unless we all go buy Amigas. <g> (sorry, digressing)

What I would like to see us work toward is more of a monolithic program
which still allows hooks for other input/output devices, but only if you
rebuild the code. That's part 1. Any questions or comments? 

Omar Loggiodice/AL:

Jerry- That has been my idea from the beginning, but we do not have to
rewrite code necessarily. We can use device drivers for new I/O devices
and interchangeable code for platform dependent code. (the method is
something like what I described in WEOL00.TXT) What we have to concentrate
on is *interface* specification between modules and device drivers, not on
their semantics.(until we want to make a platform-specific implementation)

Jerry Isdale:

Omar, the problem with device drivers is that many devices require more
processing, such as gesture recognition from the glove fingers, etc. This
gesture recognition and control can be very difficult, and not something
that can be defined once and forgotten, it is often what the designer
wants to play with. Also the recognition may take more time than an
interrupt driver can afford. 

Here comes part 2: ...let me lay out some of the tasks & goals... First we
will be making a PC specific version as our initial prototype. This is
because we have a major chunk of the system given to us in the REND386
stuff from Dave Stampe (which supposedly includes glove and glasses stuff
in its latest incarnation, but which has yet to be uploaded here. I would
like to see what Bernie Roehl and Dave Stampe have done but also we need
to progress on our own. 

Our WE/WP system might not support the glove first round. Maybe it will,
but it shouldn't *require* it. The WE side should allow the user to define
and place simple objects (cubes, etc) and import more complex ones. We
don't want to build a full CAD system right now; later. <g>

The system would have a simple scripting language (ie VORL), that offers
much the same capabilities as VR Studio, which i have suggested before as
our model and our goal... to build a PD VRStudio that supports better
scripting (printing, copying, and other things Raymond and others have
mentioned), and better modeling primitives (PLG vs cube/triangles), and
hopefully allow glove/glasses.

I'm still not sure what commands are to be supported by the VORL system
nor it's syntax, but recall it to be C like. 

We will need to consider things like the control panel graphics (imported
from paint program), menu design and the text (script) editing subsystem.
These are beyond the DS/BR system at present. 

That is my basic thought for the WE/WP system. Comments?

Omar Loggiodice/AL:

It seems project leader and assistant leader agree! 

(ed. note...general roar of approval from the great unwashed here....)

Jerry Isdale:

OK, to continue, our use of DS's renderer gets us around some of the
limits of VRS, but leaves us with lots of open problems. On the player
side, we need to have a fast world interpreter that leaves enough time for
Rend386 to do it's work. Also, to allow the input devices time for their
processing, which leads to the question of control panels and menus in the
Player. I like the VRS method of adding control panels generated in a
paint program, but it really suffers from lack of audio/visual feedback
when you enter/leave or activate a button. I found that frustrating as a
user. Any comments? 

Omar Loggiodice/AL:

Generally I agree. What you mention are long term points to be considered.
We will eventually need and develop our own renderer (John Swenson has
been working in some primitives); also we will need, before the new
renderer, a user-interface specification that will eventually evolve into
a professional looking GUI. (hope so! <G>)...

We should also discuss the short term goals which will move us toward
those long run goals that you are mentioning. That's why I'd like the next
CO to be a *key* conference to organize our work here; that is, specifying
or supporting already defined short and long term objectives and forming 
workgroups. 

Jerry Isdale:

There are still some other long term goals we need to put forth. I would
like to get them all out so we can be ready to break them down into some
short range milestones.

So on the WP side we need:

Renderer API, control panel code (which could work with DS'stuff - there's
a milestone), and a fast interpreter, which brings us to the interface
between the WE and WP. 

The primary interface is the world description files which consist of
scripts and object geometries. These will need to be in ASCII format at
some point, but binary format would be better for fast loading &
replacement during playback.

Moving past the WDL, we have the WE to think about. Here we need a simple
modeler, a text script editor, and a way to position objects within the
world. (also a way to divvy up the world into sub spaces)

Mark, these are some areas where you might have input...go ahead.

Mark Pflaging:

Sounds like the classic compiler/interpreted question...make your programs
data or refine your data definition? Of course, we want both to happen, so
go ahead, but I'm not so sure that text description will end up being the
preferred format for creating/distributing VR worlds.  Remember that text
is a stepping stone. 

Jerry Isdale:

Mark, we have in the past talked about various c/i approaches including
using threaded code (ala FORTH). I like some of the possibilities of a
Threaded system, but there are many drawbacks. such a system is easily
extended, including, perhaps, new gesture recognition. 

I think that approach might be worth looking into, but not many of us are
familiar with how to implement it, thus it may never come to pass.

Well, I've laid out a goal here that we can expand on, and I'd like folks
to send messages this week to discuss some of the possible milestones we
could attempt. If we get a decent response, I'd like to schedule the
formal CO for the week after next. (June 14, tentative)

 end VRREP4 
