 |
Sailing Page Technical Report |
 |
| |
Sailing Page Technical Report |
|
There was a great difference in boats, of course. For a long time I was on
a boat that was so slow we used to forget what year it was that we left port
in. But of course this was at rare intervals.
- Mark Twain
I have with only a slight bit of tongue in cheek suggested in rec.boats.racing and comp.sgi.xxx that the folks who provide Sailtrack(tm) computer graphics support to the televised America's Cup extravaganza also make the data available on the Web. Unfortunately, Paul has taken me seriously and asked me to briefly ruminate on what might be required in 1999 (or whenever the next AC occurs) to make this happen.
First I should like to point out that guessing what technical capabilities will be available on the net in 6 months is risky, and being anywhere on target 4 years out is about as likely as a $40,000 AC boat winning the Auld Mug. Also committing oneself in print means whatever I say will come back to haunt me. Finally, except for HTML, my knowledge of various prototypes and such come from what I read on the net, so for details of what I say you should check with the appropriate vendor. Finally, any named product is for example only and is in no way an endorsement. With these caveats, I proceed.
What I imagine is a viewer on your screen, with most of the area covered by what one sees today from the SailTrack system, models of the two boats with laylines, and paths through the water. Displayed around the edges are user controls to move back through time, change the camera position, and toggle things like laylines, etc. One can imagine more complex interactions, but this seems a reasonable working set.
But, you are saying, why not just download video realtime? First, I'm not sure what bandwidth will be available to the typical user in 4 years, but it is possible that this may be a choice. More importantly, for the same reason that ESPN(tm) uses Sailtrack, having a user controlled representation is very valuable. First off, after you download the models of the ships to the client, you are only sending position information, so this can be a relatively low bandwidth type of endeavour. Second, it is very hard to tell from video, who's winning, which can be visually evident with a computer generated representation.
There seem to me to be three technical issues that separate what is standardly available to your typical WWW user today, and what is needed to have a live real-time representation of an AC race: a sustained (though possibly intermittent) connection between client and server; a 3D modeling language and appropriate viewer controls; and a procedural language to get things to move around, show tracks over time, etc. These three items, and of course a lot of work.
Currently, HTTP, the protocol that WWW clients talk to servers is very transaction oriented. You click on a link, a connection is opened, a page or image is downloaded, and the connection is closed. Clearly to keep pumping data down to your viewer, the connection has to be kept open for the duration of the race, with incremental changes in the position of the ships sent to you, or some clever arrangement of client pull or server push mechanism must be implemented. I know the viewer from Netscape(TM) has both a client pull, and a long term connection facility, and I assume other viewers do as well, but I believe no standard exists, and it isn't clear that these models are sufficient, or that some multicasting facility would be more appropriate.
On the 3D front, a consenus seems to be forming around VRML, which is an object oriented, 3D rendering standard, based on Silicon Graphic's(tm) OpenInventor(tm) product. OpenInventor is actually more than a rendering standard, with interactions and engines and such, but the current VRML (at least to my understanding) has stressed the object -> rendered scene part of OpenInventor. There exist viewers today that display VRML, and a number of sites have VRML data. My impression is that VRML or something like it will be the solution to the 3D part of the problem.
The need for, and the market for the procedural part of the problem is much less clear to me, and clearly the trickiest of the technical issues. One needs procedural control, if you want to have local interaction with the data. For instance to change the camera position, something (a procedure) needs to move the local camera. The trick is to allow this to happen in a safe way. If you allow arbitrary procedures to happen on your client, through evil design or bugs instead of moving the camera, the procedure might move some of your files or introduce a virus. Much work has been done in this area, and there are a number of competing early prototype products out there for the Web, such as the GNU project's GUILE as well as a number of proposed proprietary solutions, but I don't believe we are far enough along to guess which might arise as the standard. An alternative would be a special purpose client with the necessaries built in, but having an off the shelf solution, just as HTML has done for the current AC would allow a much wider audience.
So, the summary is that I believe by 1999, the market and standards will have sorted themselves out so it will be easily technically feasible to hook into real-time data and have two computer simulated AC boats dueling away on the then available average Web browser.
