Key among the things that need improvement, is the file size. The files need to be much smaller (and I don't just mean gzipping them), and be able to load information in order of importance. Because everyone likes to have pictures come up as fast as possible, and everyone also likes being able to stop the transfer in mid-stream without losing everything up to that point.
Next down, is platform support. VRML started out as an SGI-only thing..and then when the visions of dollar signs flashed in people's eyes, Windows platforms came next. Everyone seems to be forgetting about (or putting, last on their list) the Mac (which a large part of WEB publishing is created from), Amiga, Atari, NeXT, and BeBox. So it would be nice to have viewers for all platforms come out at the same time, from the same source.
Since browsing doesn't require the precision of most 3d stuff (like CAD/CAM, or reenactments for court cases), you could use fuzzy-logic to send only relative approximations of the objects and placements through the modem. To accomplish this, you wouldn't be sending a ton of coordinates to be plugged into algorithms. You'd be sending equations themselves. Your 3d viewer would essentially be a calculus interpreter. It would take more processing power at the viewing end, but current VRML viewers only run smoothly on $x0,000 to $x00,000 systems anyways. So with a relatively cheap board (since calculus already exists) or chipset that you could license, a lot of people could have the viewer hardware in their computers.
The real benefit at the high end of this, is that objects of great complexity (that would be huge in VRML) could be transferred in a very short amount of time. Viewer apps on slower computers, would just interpret the shapes in a simpler way.
Another good thing about the format, is that it would be completely scalable as far as extra details. The viewer would send how powerful the hardware and connection is to the server, and the server could scale the complexity of the 3d data so it would run smoothly no matter what kind of system you were running (well, within reason.. like I don't think it could run at all on an old XT at 2400 or something).
After the minimal information comes through, there then is the question of textures. This can add an amazing amount to the size of the file. So in addition to compressing texture-maps with JPEG and/or Fractal compression schemes, the use of a procedural shader set would be useful. To speed the redraw, the shaders could be 'rendered' before the scene gets mapped, and turned into a quick-moving bitmap. It would require more memory, but the file sizes could be MUCH smaller.
Something that would really, really help as far as file size, and the nature of a Markup for 3d, would be an extended character set. Most OSes are at least 32 bit, so having a 32 bit character set would make the whole thing a lot easier. Think about it. We have characters for all the letters and symbols in the english language (as well as several others). But we don't have a character that means, for instance, sphere. And we wouldn't have to stop at primitives. We could have characters for advanced shape parts.
True, a lot of systems would have to be updated. Everything currently transfers at either 7 or 8 bits..so a lot of changes would have to be made. But they'd be good changes in my opinion.
1. Name, Size, Format Version, Layout
2. Base camera position, Minimal 3d data, Hyperlinks
3. Motion paths, Behaviors
3. Complex 3d data, Shape surface attributes, Light positions
4. Textures, Sounds, Movies, Media-feeds
(all of which after stage 1, could be hyperlinks to other files on the server or in the cache)
Netscape, aside from their practice of making their very own html tags, has done a pretty good job in the area of multi-platform development. Netscape is now the most widely used browser on the internet. A similar approach would be good for 3d browsers (or plug-ins there of). A 'standard' viewer from one company or individual written for at least the major platforms would be a nice thing to solidify the technology.
Lastly..another name would be good. VWML, VDML, 3DML, XYZL, FUBR... the possibilities are endless.
Created Dec 10, 1995