Both of these protocols do the folowing, among other things:
A) Provide a format for the exchange of data between simulations
B) Provide lists of predefined objects to which the data exchange applies
and lists of predefined data values.
Lets consider the predefined objects and predefined data values. As long as
the number of simulations is small these lists can be reasonable in length.
If the number of simulations is large or the process of "mutual agreement"
on the syntax and semantics of the list elements is not effective, then
these lists can be quite unreasonable. The length, syntax and semantics of
these lists are important since any browser or simulation interface must
translate the "PDU's", "ALSP messages" or "whatever" into the internal
format of the simulation.
Note: In the case of a browser, I suppose that the translation would be
according to the specifications for VRML/GopherVR/etc. In this case the
simulator would be executing a VRML/GopherVR/etc. simulation with rigidly
defined internal structure. Suppose the simulator is not a browser, say a
scientific or industrial simulator, or much worse, a game. In this case,
translation of the predefined objects and predefined data values would be
more difficult.
Lets consider the format for the exchange of data between simulations.
Ignore the actual architecture of the format and think of the data classes
that are to be exchanged.
For a simulation that is a browser, consider the following abbreviated list
of classes if the browser is only concerned with static VR scenes which
provide an environment to extract predefined "fun stuff" from a 3D home
page
Object State
identification (name)
position (3D)
orientation
geometry
surface features (Textures, procedural features, data table features,
etc.)
location and nature of hyperlinks
state
lighting characteristics
sound characteristics (absorption,reflection,etc.)
etc.
Sound State
object emanating from
frequency
etc.
Lighting
positions
intensity
etc.
Etc.
Many of these browser classes are covered by the VRML 1.0 Draft
Specification with the exception of sound which seems to have been
posponed. Browsers need a lot of geometry and a method for hyperlinking so
the draft specification is tailored for graphics. The good news is that we
have a fair percentage of the structure for distributed VR, at least the
structure related to geometry and hyperlinks.
Now suppose that the simulator is not a browser but an industrial or game
simulator. The types of information that needs to be exchanged becomes more
and more non geometrical. Suddenly, you need characteristics and state data
related to games and physical processes. You also need the algorithms to
model the events in the simulator, but that is mostly a problem for the
individual simulator. Naturally, the algorithms would help to drive the
data requirements.
I've spent a lot of time talking about the problems facing VRML / GopherVR
/etc. from the standpoint of distributed VR. So I suppose I should share
some thoughts on solutions.
I presume that there will be some sort of archive of predefined objects and
data values. These would probably have an identification label, at least
for the objects. Browsers and other VR simulators would have to create
their own translation tables to their internal data naming conventions.
Eventually, the exchange process will have to handle arbitrary types of
data such as temperature, velocity, fatigue level, food level, etc. and
some pretty wierd data values. One concept that will be required by
distributed VR is that of local data classes that are user editable. Thus,
the DIS/ALSP type messages and PDU's would have to be user editable.
Naturally, if this concept is not constrained, the parsing and
interpretation problems would lead to anarchy. There will probably have to
be a sophisticated filtering process and probably a method to attach
distributed VR simulators to one another. See the user-defined node in the
VRML 1.0 draft specification.
Functionally, the distributed simulators will have to:
make new objects
remove old objects
allow objects to interact
change their status
It seems that the first 2 functions (make and remove) are functions that
are of primary concern to VRML browsers. These browsers would be making and
removing scenes and hyperlinks, etc. The rest of the functions relate to
dynamic browsers and VR simulators. Changing status relates to housekeeping
details and modifying physical characteristics of the subobjects in the
scenes. Interaction relates to modifying the relationships between
subobjects in a VR scene. These relationships may also concern the geometry
of the scene.
The filtering can be localized in the simulators/browsers as in the DIS
strategy or can be centralized in an intelligent router as in the ALSP
strategy . In this case the intelligent router would be a "distributed VR
router". Filtering is important from the standpoint of network traffic.
Note that by attaching to a router, distributed browsers or other vr
simulators could limit their interactions to selected 3D VR browser or
simulator sites.
Finally, there will probably have to be some sort of time stamp so that the
simulators can be synchronized. Not only do you need a time stamp, but you
need some sort of time umpire to enforce synchronization rules.
Now let us consider how the data is sent. The DIS strategy seems to favor
bit fields. The DIS PDU's are dumped onto the network and the receiving
browser or gopherVR creature or VR simulator then decodes the PDU. Decoding
the PDU equates to determining what bit fields map to what class or
subclass of exchanged data. The ALSP strategy seems to favor text
transmission. The ASCII text is sent to an intelligent router, filtered and
then transmitted to the destination browser, etc. The receiver would
pattern match for keywords. It should be noted that the US navy has
developed some intelligent DIS "routers".
By the way. I like to think of a VR simulator as just a VRML browser with
dynamic capabilities and a set of algorithms for doing something with the
"browsed scene". Note that one of the reasons for distributed VR is to
allow one requesting browser or vr simulator to utilize any special
algorithms or abilities of another browser or vr simulator and then pass
the results back to the requestor.
Note that the VRML 1.0 Draft Specification has self-describing nodes. This
is probably the quick and dirty way to extend VRML 1.0 to dynamic browsers
and distributed VR simulators. The SFMatrix is limited to transformations
so a general matrix structure would be nice. MFvec2f and MFvec3f would be
inefficient. There probably should be a method to attach an identification
to an object. Probably should consist of at least a name and the "id" of
the sending browser or vr simulator or VR Gopher creature, etc.
A lot of these VR simulators would be gamming systems but there are a few
other systems:
interactive vr theater
ineractive vr conferences
interactive vr education (vr version of edutainment)
etc.
---------
P.S. - I have not had a lot of time to comment on VRML, etc. So I might as
well vote for a newsgroup, since the newsgroup issue is probably of high
priority.
1st Choice comp.vr.vrml
2nd choice sci.vr.vrml
P.P.S. - I have not read every word of every discussion on this mailing
list so if I have repeated some concept that has been discussed from here
to venus, my appologies, especially if the problem has been solved.
John F. Richardson
NRaD
[email protected]
http://manta.nosc.mil/~richards/bolts.html