Dave Raggett comments
> For machines with insufficient power to support smooth motion
> through a VR scene, we can provide browsers which allow you to jump
> to a new position simply by clicking on where you want to go.
> Double clicking would then be reserved for picking things up or
> teleporting through a cyberspace hyperlink.
>
> The cursor motion keys could be used for systems without a mouse or
> other pointing device. Although it would be quite a challenge to
> write a VRML browser for a 512K DOS system!
I've been sitting by watching the action as it were, on this group
since it started. By way of introduction, my name is Thomas Churchill
and I work in the R&D facilities of NEC Systems Laboratory here in
San Jose.
Although I am glad to see SGI's Inventor being considered as a base for
file format, (if files *have* to be used -- personally, I'd like to see
a CORBA brokered exchange of information between "live" objects -- but
I figure this is probably a little too radical given the current state
of things) what concerns me is the large number of times the limited
hardware related capabilities most (inepensive) machines have is
being brought up.
IMHO, hardware is irrelevant. Well, not totally -- but nearly totally,
if for no other reason than machines like the Atari Jaguar are available
right now for aprox. $250 with 5 processors. And the "Project Reality"
machine SGI and Nintendo are developing (based on the 64 bit MIPS R4XXX
chipset) will probably push the envelope even farther. Given the strength
of these machines, I see no reason why a person who wants to build a
"garage VRML" browser cartridge couldn't do so. In fact, a $50 VRML
cartridge you plug into the next generation Nintendo and a 28K V.fast
modem could open the VRML world on the Internet to millions of people.
Using domain-specific compression on the VRML documents (tokenizing
keywords, and good word-based text compression) could increase throughput
by probably a factor of 4-10 -- Important for those low bandwidth connections
people seem to be worrying about. (Not me so much, because I think
bandwidth is a problem other people will solve, sooner rather than later.
At least here in San Jose, we've already got cheap ISDN, which is a
decent first step; and DEC is trying now to sell 10Mbps Internet
connectivity to cable operators)
The point I am trying to make, and others have also voiced, is that you
can't look at today's machines as realistic target platforms. You can't
even look at today's machines and linearly extrapolate-- technology in
this area is progressing exponentially, and at the very least, the spec
should consider that. I am half concerned that the increased latency of
fetching "greater detailed" object descriptions will be self-defeating;
that it might actually decrease perceived performance. For connections
which transfer only a small amount of information, the overhead of making
a connection might be greater than justified by the amount of data sent.
--thomas
1 3 5 Thomas Churchill (KC5GAU) Voice: 408.433.1516
|_|_| Software Technology Center Fax: 408.433.1448
| | | NEC Systems Laboratory
2 4 R Western Division - San Jose, CA Email: [email protected]