- Location.
Alturus Inc. Broadcast VR.
| 408.557.6743 office
|
NASA ATCC
| 408.557.6786 fax
|
650 Saratoga Avenue
| www.alturus.com
|
San Jose, California 95129
| ... Thanks Alturus for break refreshments and lunch!
|
- Attendees.
- Overview of DJV objectives.
An extended discussion about DIS, the dis-java-vrml (DJV) library, motivations
and group goals. Primary points:
- VRML 97 is stable, clarified and has completed the final stage
of standardization. VRML 97 is about to be approved as an International
Standard by the
International Standards Organization (ISO).
Java via the Script node is an effective way to
connect VRML to network streams.
- DIS is an an example behavior protocol, i.e. a way to communicate
behavior among multiple entities.
- Since DIS is an IEEE standard, it is well specified. There are also
lots of legacy DIS simulations in the military.
- Choosing an arbitrary behavior protocol (such as a networked game)
or making our own hacked-together behavior protocol would be a bad first
start, because there are too many open issues. Our first implementation
for inter-entity many-to-many behaviors is therefore DIS.
- We want lots of people able to communicate and interact together
through VRML scenes. DIS-Java-VRML (DJV) can provide the necessary links.
The DJV library is written for easy inclusion in VRML scenes.
DJV also provides an application programming interface (API) for
other Java applications/applets that want access to DIS.
- Many people talk about large-scale multicast applications, but few
are actually building them. DIS-Java-VRML is intended to show results.
In another sense, we are also building a market of multicast users.
- NPS is interested in research that implements Large-Scale Virtual
Environments (LSVEs). Once the DJV library is functionally tested, implements
multiple entity connectivity in a single scene, and has effective
live demos which are a mouse click away from any user, we will be
shifting our immediate programming efforts into a dial-a-behavior
protocol (DBP). NPS will of course continue to maintain and support
DJV library development. Significant new programming additions can
come from other working group members.
- Related VRML Consortium (VRMLC) working groups (WGs). Lots!
- Streaming. This WG has just started. Unfortunately neither
Mark Callow nor Mark Pesce were able to attend this meeting.
We expect that a lot of overlap and cooperation between our groups
is possible. (See section 8 of these minutes.)
- Human animation. This group has done a lot of work to specify
conventions for naming transformations in a scene corresponding to
the human body (but not facial animation, yet). Several theses have
been written at NPS about modifications to DIS to support human
animation. Other work has also been done (e.g. Jack at
University of Pennsylvania). WG collaboration is a good idea.
- External Authoring Interface (EAI). This is a proposed alternative
way to interface Java to VRML. It is not an approved part of the
VRML 97 specification. There are several EAI examples in the DJV
library, but they are probably out of date since EAI details remain in flux.
- MPEG-4. MPEG-4 is an ISO standards effort to provide
general-purpose streaming protocols to compose audio, video, 3D graphics,
facial animation and other streams. After a controversial set of
initial discussions, it appears that MPEG-4 will use unadulterated
VRML 97 for a 3D format. A joint liaison working group will likely be
formed. MPEG-4 is working towards producing a Committee Draft and
is likely several years away from approaching International Standard
status. Nevertheless MPEG-4 is worth monitoring. Nermeen Ismail's
group at Philips Research is active in the MPEG-4 effort, she provided
several good insights on MPEG-4 and other topics.
- Script. The vrml-script working group did an outstanding job
clarifying ambiguities in scripting, event routing, JavaScript and
the Java Script Authoring Interface (JSAI) VRML 97 annexes as part of
final specification review. They are now considering the CLASSPATH problem,
i.e. inconsistent and error-prone differences in CLASSPATH settings (and
vrml.* class file naming) between different browsers.
- Biota. Generation of artificial life forms provides an interesting
application area that might benefit from adding DIS connectivity.
The L-system seeds used to feed the growth algorithm are usually pretty
small, and so might be passed as Comment PDUs (free-format messages).
Most biota examples seen have been stationary, however, so DIS ESPDUs
for motion might not be needed.
- Intellectual Property (IP) policy. Because NPS is part of the U.S.
Government, we have unique copyright status: government works can not
be copyrighted, by NPS or any other company. Thus NPS code can't be
"hijacked" away from DJV users.
Our IP policy is pretty simple: free for academic, private or commercial use,
as long as the NPS and the DJV group receives acknowledgement,
and no money is charged to users. Essentially the same as Gnu CopyLeft.
We will not add any contributed code to the DJV library that can't abide by
these restrictions. Therefore no licenses or encumbrances will be permitted.
- Status of code library. Don McGregor provided a
PowerPoint slide set.
Summary follows.
- Design objectives. A free, public-domain DIS library. Produce
recommended set of practices for mapping between DIS and VRML.
Also usable as a VRML-independent DIS API. Provide DIS
utilities (such as record and playback). Math and physics libraries.
- Packages. Looked at the main DIS library, JavaViaScriptNode,
Utilities, Math and other package directories.
BoidsDemoEai is suffering from "software rust" since EAI is a
moving target. JavaViaScriptNode is the primary VRML development
directory.
- Bridge. We hope that Bridge will eventually become a rarely used
utility program, when
multicast security restrictions (and apparent bugs) in Netscape Communicator
are fixed. Don McGregor is working this problem, if anyone has suggestions
they are most welcome. Signed applets are likely required. Diagram follows.
- NetworkMonitor. Major problem trying to get new Communicator
classes to comply with security incantations rather than throwing
exceptions. Extending NetworkMonitor to handle multiple entities
in any scene, with all network communications safely threaded.
This is the major area of work right
now and the last big piece remaining before end-to-end many-to-many
functionality is available. Hoped-for completion: December.
- SimulationManager. Lots of miscellaneous PDUs for exercise
start, stop, pause, resume, etc. Any actions taken must be at
application level, the DIS library just passes them through without
taking any action.
- Espdu Articulation Parameters. Articulation Parameters (APs)
are the way to add data to an Entity State PDU (Espdu) without
breaking it. Default is zero. As an example, the NPS AUV entity
has three APs with bit-stuffed values for propellors, plane surfaces,
sonars etc. Needed: a general way to expose AP values to the VRML
scene. This will include naming conventions.
- Math. Handles simple things like quaternion (VRML Orientation)
<=> Euler angle (roll pitch yaw) arithmetic.
Might someday replace with Java3D classes (if they ever get delivered).
- Class Hierarchy. Reviewed in detail. Matches DIS specification
hierarchy of PDUs. Future non-DIS variations (such as dial-a-behavior
protocol, DBP) will likely appear at the ProtocolDataUnit class level,
in order to reuse underlying NetworkMonitor classses.
- Other PDU types. We've implemented many of them: Entity State,
Collision, Fire, Detonate and the simulation management PDU family
(which includes the free-format Comment PDU).
A lot of cats & dogs remain (e.g. logistics PDUs). Other folks
are welcome to add these remaining PDU types as they need them.
The class hierarchy is carefully
designed to make this chore relatively easy. Recently six graduate
students were able to add about ten PDU types, working individually
on 2-week class projects, with no prior DJV experience.
We talked about current problems with CLASSPATH inconsistencies between browsers.
An interesting point was brought up: if the DJV work eventually becomes
a VRML Recommended Practice (RP), the class path might change from
mil.navy.nps.dis.* to vrml.dis.*. This would
suggest that a consistent directory structure for all vrml.*
classes is important. This comment has been passed to vrml-script working group.
Although scheduled, the timetable for a RP proposal was not discussed.
Basically we need to get everything running and a lot of testing started first.
Conceivably a RP proposal might be ready for the VRB by next summer.
- PDU relay server demo. Mike McCarthy provided an Entity State PDU
(ESPDU) multicast-unicast relay server demo - receiving PDUs from Monterey -
and a corresponding
PowerPoint slide set.
His PDU generator provides multicast PDUs, with world-wide scope
(time-to-live ttl=127) from Monterey,
at a rate of 1 PDU per 2 seconds (0.5 Hz). Mike then showed
a multicast <=> unicast relay bridge: he dialed up via modem from Alturus
over a standard (unicast-only) PPP link phone line,
connected to the relay bridge server,
which converted multicast PDUs from the campus backbone and sent them down
the phone line as unicast PDUs. It worked very well!
The relay bridge technique gives us a lot of flexibility.
We can use multicast when directly
connected to the Internet multicast backbone (MBone), or use unicast over
other links (such as modems and LANs not connected to the MBone).
So far, Mike has gotten twenty simultaneous read-only clients
connected to the server without utilization problems,
which is a good start. Server-based approaches often can
scale to the low hundreds (but rarely much more).
We will also look at having multiple groups running at once,
where a group = (multicast address + port) combination.
Mike has configured half a dozen 386/486 PCs with Linux to act
as PDU generators and multicast-unicast PDU relay servers.
It is worth noting
that these bridging and relaying techniques are similar in functionality
to an area-of-interest manager (AOIM) which handles group management.
This will be an important area for future work when we start scaling up.
Next steps: getting this program to work both reading and writing, and
making the PDU relay bridge the default connection technique for new users
visiting the DJV site. Note that this approach sidesteps the entire signed
applet issue (which is good).
We expect that users and authors will be able to connect to a multicast
scene without installing the DJV library. Only software developers will
need the software distribution.
A diagram showing the multicast-unicast PDU relay server follows.
- Streaming. Possibilities for streaming VRML via DIS were discussed
several times. Interesting ideas include:
- Interpolators. Utility routines which read an Espdu stream and
generate a matched pair of PositionInterpolator and OrientationInterpolator
VRML nodes. Also the inverse: converting a matched pair of PositionInterpolator
and OrientationInterpolator nodes to a DIS stream.
- General DIS-ification of VRML nodes. It is a worthwhile task
to go through the entire set of nodes in the VRML 97 specification
to see whether corresponding DIS-capable EXTERNPROTO versions might be
produced.
- Camera. Many people are interested in streaming a video-like
program using VRML. Using an EspduReadTransform above a Viewpoint node
appears to be a great way to animate camera for an audience.
This capability is available now.
- What me worry. A lot can be done with Anchors, Inlines and
ProximitySensors without special networking hooks. We expect to find a lot
of new and surprising functionality as we begin building internetworked
VRML worlds.
- Time and timestamp issues. There are several time and
timestamp-related problem areas. Simultaneity/cheating is a semantics
issue, getting clocks synchronized is a deployment chore, and deciding on
timestamp payload formats is a representation issue.
- Simultaneity/cheating. An unsolvable problem is how to get
reliabile delivery, global consistency and fast updates simultaneously.
It's not possible. There are many approaches to this problem, usually
tuned to the capabilities and needs of a given system. In DIS,
the shooter says "BANG" but the target decides whether "YOU'RE DEAD."
In other words, the shooter issues a FIRE PDU based on its best estimate
of target position, which the target uses to determine damage and then
issue a DETONATION PDU damage estimate.
This avoids most latency problems. It is interesting to note that
the speed of light is ten milliseconds per time zone, so some
amount of latency will always be present in distributed virtual
environments.
Is cheating possible using the DIS convention? Sure. Can that be fixed?
Mostly. Cheating is pretty boring for other players so misbehavior
doesn't have to be tolerated. Administrative controls on what software
is used can force participants to use "approved" or "certified" applets
(but then who watches the watchers...). These are all application
decisions, meaning they are not built into the DIS code we are building.
There are many references on this topic and a lot of activity in the
networked gaming community on a plethora of different approaches
that mask network latency. This is a likely area for future work
by this group in establishing policy and usage conventions.
For now we are satisfied
to implement DIS as specified, which pushes responsibility for
compliance up to the application. Interesting online papers can
be added to the DJV References section, keep those pointers coming
please. Recommended viewing includes "The Good, the Bad and the
Ugly" as a case study in 3-way interactions.
The pertinent networking slogan here is "fast, cheap, reliable:
pick any two."
- Getting all our clocks synchronized. Once we commence running
shared VRML scenarios using DJV, having clocks consistently set
among various participants will have numerous benefits. This is an
Internet-wide problem, so we will assess and select the most effective
Internet solutions as our recommended practice for clock synchronization.
Likely technologies to be investigated include:
- Network Time Protocol (NTP). Available as
RFC-1305. From SNTP RFC-2030:
"In most places of the Internet of today,
NTP provides accuracies of 1-50 ms, depending on the characteristics
of the synchronization source and network paths."
- Simple Network Time Protocol (SNTP). Available as
RFC-2030.
A more recent, lighter-weight, compatible version of NTP that
probably sees broader use.
- Geographic Positioning System (GPS). GPS satellites are
used for real-time latitude/longitude updates anywhere in the
world, with commercial GPS positional accuracy good only to within
200 meters, due to intentional insertion of Selective Availability (SA)
error distributions into the system.
Differential GPS (DGPS) uses a additional receiver nearby at a known
location which transmits corrections for spatial error.
An area of future work for DJV is describing the conventions and
implementing conversion routines for various coordinate systems
in common use.
GPS system operation relies completely on accurate timekeeping.
Independent of spatial errors, GPS receivers maintain time
accurate within a few milliseconds. Now that GPS receivers only cost
a few hundred dollars, it appears that GPS timekeeping in combination
with NTP/SNTP handshaking will be able to keep clocks on all DJV
hosts synchronized. This is an important area for demonstrating
working group results.
- Local and global configuration questions. Do we all need NTP
time servers at our local sites? Do we need NTP clients installed
on each host? Do our NTP servers need to be interconnected, or is
there already a tree of trusted NTP servers deployed? Do we need
GPS-quality time accuracy everywhere, or at all? What high-quality,
inexpensive GPS interface devices are worth procuring?
- Clock drift. Many PC and workstation clocks are notorious
for huge drift rates. It remains to be seen whether NTP/SNTP can
adequately correct for clock drift. Particularly broken hardware
or particularly helpful web sites are worth tracking.
- What timestamp value goes in the packet?
This problem remains unresolved. Example
choices include:
Specification
| Data type
| Payload
| Start time
| Reference
|
DIS
|
| 32 bits
| microseconds since top of hour (?!),
but start time varies widely in practice
| IEEE 1278.1 (DIS spec) section 5.3.31
|
Java
| java.util.Date (long)
| 32 bits
| milliseconds since January 1 1970 00:00:00 GMT
| java.util.Date
|
VRML 97
| SFTime (double)
| 64 bits
| seconds since January 1 1970 00:00:00 GMT
| VRML 97 5.10 SFTime
|
ISTP
|
| 32 bits
| milliseconds since start of week
| ISTP section 12.1
|
NTP / SNTP
| two unsigned fixed-point numbers (integral and fractional)
| 64-bit
| seconds relative to 0h on 1 January 1900
| RFC-1305,
RFC-2030 section 3
|
RTP
|
| 32 bits
| related to NTP,
but actually is media dependent
| RFC-1889 sections 4 and 5.1
|
RTSP
|
| 32 bits
| related to RTP/NTP,
but actually is media dependent
| draft-ietf-mmusic-rtsp-05.txt
|
The
Interactive Shared Transfer Protocol (ISTP)
at
www.meitca.com/opencom/istp.html
is a virtual world communications API recently issued by
Mitsubishi Electric Research Laboratory (MERL).
Originally designed in parallel with the Scalable Platform for Large
Interactive Networked Environments (SPLINE) project, ISTP is
intended for large-scale virtual world communications. The ISTP time
convention is a pretty good one since representing a week's worth of
milliseconds requires 31 bits. Thus different hosts can still establish
valid timestamp ordering despite clocks with errors up to 3 days apart.
NTP
and
SNTP
are the primary references for time data used on the Internet.
From
SNTP RFC-2030
section 3:
"Since NTP timestamps are cherished data and, in fact, represent the
main product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned
fixed-point number, in seconds relative to 0h on 1 January 1900. The
integer part is in the first 32 bits and the fraction part in the
last 32 bits. In the fraction part, the non-significant low order can
be set to 0."
The
Real-time Transport Protocol (RTP)
at
ds.internic.net/rfc/rfc1889.txt
is a light-weight header prepended
to most multicast streams running on the MBone. It is likely we will
need to devise an RTP Profile for DIS. This probably needs to be a
user-selectable feature to provide legacy interoperabity (after all, DIS is
an over-the-wire protocol that is completely concerned with bit formats).
Addition of an RTP header can provide compatibility with multicast network
monitoring tools for performance measurement and troubleshooting.
Within restrictions posed by sections 4 and 5.1 of the RTP RFC, media-dependent
variations are allowed. Perhaps the 32-bit RTP time field can be used,
in combination with the 32-bit DIS timestamp and a suitable start-time
convention, in order to provide a reasonable conversion into 64-bit VRML
SFTime.
The draft
Real-Time Streaming Protocol (RTSP)
at
ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-05.txt
is essentially a protocol that passes commands similar to a VCR remote control
for starting/stopping/pausing/resuming media streams. RTSP is usually (but not
necessarily) associated with RTP. RTSP has a variety of time formats
and for absolute time specifies ISO 8601 (??) timestamps using Universal
Time Code (UTC) Greenwich Mean Time (GMT).
A few additional details can be found in
earlier e-mail messages
by Don McGregor.
The big challenge here will be resolving differences between DIS and VRML
in a way that is compliant with both specifications.
- Recent ADI work plus JVerge. Chris Thorne and Justin Couch provided
two excellent overview messages on
recent work by ADI
and
recent progress with JVerge,
specifically commenting on applicability to DJV.
Surprisingly, we ran out of time to discuss them. Sorry guys.
The messages are forwarded to the DJV list for comment and archiving.
- VRML 98. At the VRML Symposium in Monterey next spring,
Don Brutzman & Don McGregor plan to provide a half-day
tutorial on DJV followed by a half-day DJV working group meeting. Likely
date: Monday February 16.
A multiuser DJV demo is planned for the Wednesday night Demo SIG - we will
want some PDUs arriving from remote sites around the world. VRML 98
registration is now open on the
VRML 98 home page
at
ece.uwaterloo.ca/vrml98/
- IETF LSMA. Mark Pullen of George Mason University presented a
PowerPoint slide set
on the Internet Engineering Task Force (IETF)
Large-scale Multicast Applications (LSMA)
working group. This is an important area of related work.
(Thanks for flying out from Washington, Mark!)
Three pertinent IETF Draft Request For Comments (RFCs) of interest are
Another pertinent area of work is the Internet Research Task Force (IRTF)
www.irtf.org.
The Reliable Multicast (RM) research group
www.east.isi.edu/rm/
is working on transport-layer distribution mechanisms that might be
useful for DIS traffic.
DJV is a candidate for building large-scale multicast application (LSMAs)
that may also benefit from reliable multicast (RM). Our future testing
results will likely be interesting to a variety of network research engineers.
- Web site, documentation and configuration management.
Ronan Fauglas presented a
PowerPoint slide set
(also in
PostScript)
about his planned work as a visiting student at NPS over the next two months.
- Web site redesign. Ronan is working on making the web pages
better for two principal classes of users: (a) visitors who want to
learn about DJV and try an example, & (b) developers and contributors.
Marcy Stahl suggested the following items: clear vision, examples
to download & test, architecture diagrams, and clarifying the size/scope
of the download library. She noted that she could have used a simple
flyer to describe this meeting, for distribution two nights earlier at
the VRML SIG meeting in Mountain View at SGI.
- Javadoc documentation.
JavaDoc
is Sun's source-code-commenting convention which is used to autogenerate
documentation (as can already be found throughout the DJV software
distribution). Ronan is making a JavaDoc template and
establishing commenting conventions. This effort builds upon previous
work by NPS student Namik Kaplan. Ronan will update the code comments
documentation thoroughout the entire library. The template will
provide guidance for future contributors about how to contribute code
in a consistently commented way.
- Configuration management (CM). If we expect many people to
eventually contribute to the DJV libraries, we will need version
control and configuration management support tools. Ronan looked at
tools used by the
Apache
http server (written in C++),
the
Jigsaw
http server (written in Java)
built by the World Wide Web Consortium (W3C), and other major projects.
Concurrent Versions System (CVS)
appears to be the CM software tool of choice. Additional comments by
other DJV members are most welcome as we prepare to select our group CM
tool.
- Future research. Don Brutzman discussed
virtual reality transfer protocol (vrtp)
and dial-a-behavior protocol (DBP) using a
PowerPoint slide set
prepared for the recent VRMLC Summit meeting.
- DJV library testing holes and testing plans. Discussion deferred.
- Schedule plans.
Dates
| Times
| Event
| Location
| Details
|
Tuesday DEC 16
| 1-5 PM
| DJV Working Group
| Alturus San Jose
| New demonstrations, how sites can get MBone connectivity,
test plans, VRML 98 preparations, etc.
|
Tuesday DEC 16
| 7-9:30 PM
| VRML SIG
| Bay Area
| 15-minute presentation on DJV
|
Thursday DEC 18
|
| Conformance / Interoperability WG
| Bay Area
| Work expected on CLASSPATH problem
|
January ?
|
| DJV Working Group
| Alturus San Jose
|
|
Monday FEB 16
| 8:30-12 AM
| DJV Tutorial
| VRML 98 Monterey
| "How to DIS your VRML"
|
Monday FEB 16
| 1-5 PM
| DJV Working Group
| VRML 98 Monterey
|
|
Wednesday February 18
| 8-10 PM
| Demo SIG
| VRML 98 Monterey
| 5-minute multiuser demo
|
- Action items and planning. We had a stimulating extended discussion.
Mark Jean will write this up, possibly as a Functional Requirements Document.
He'll use the perspective of DJV group members (not just us NPS maniacs).
Corrections and comments regarding these minutes are welcome.
All in all, a great and productive day. Thanks everybody for contributing.
Respectfully submitted, Don Brutzman