Object-Casted URLs (Resend)

Susan Loggiodice ([email protected])
Mon, 29 May 1995 21:30:39 +0300 (EET DST)

This is still in experiment on a closed network, but perhaps someone
will find some part of it helpful.

Noting that VRML is bulky and not what the average 14.4 cruiser wants to
download for every "world" chosen.

What we propose is being dubbed Object-casted URLs (a cheap-man's WWWVR).
It involves a depository for storing vast catagories for objects and their
characteristics along with standard HTML markup making the calls to the
server.

Let's say we want to draw a volkswagon that has seen better days in a
junkyard and that the viewer can walk all around the junk car to see the
effects of some great finish restorer. The page would look somewhat like:
(Please note I took liberties not including all the standard tags for
brevity)

Blooza Car Finish Ad1 [....] (introduction text) //* This is the sensitive layer that tells the server what page to serve according to where the user clicked *// //* This image displays layers of details (vector graphics) the server pushes as much layer detail in a fixed time period - fewer layers for those with slow connections, more with faster *// //* This is the final layer pushed from the server, regardless of the previous layer's detail level, this is also the layer subject to altercations by user interaction, this provides the creator with flexibility in customizing a "universal image" stored in the static URL machine. It would be up to the creator to add custom overlays to add effects such as our rust on the car. (One could download the frame from the frameserver to accurately place rust spots then use something like LViewPro to create transparent background and to add broken windows) *// As the user clicks on the first page, the server builds the page adding the frame and the overlays. (We are still using something like Netscape's browser) The user clicks on the front bumper. The server opens the port to feed through all intermediatory frames based upon the information contained in the original Object-cast (Server push). The last page fed to the client would be the bumper view. I---1---2---3---4---5---6---7---8---9---0 ^ ^ first page user selects frame 8 The server follows logical path (frames 1-8) pushing all the preceeding pages to the client using the X-axis path. (If the user selected the hood of the car, a frame not defined since a human cannot walk over a car in this instance, just a close-up view of the car could be shown) In objects where views can be more complicated the server would need to define the optimal path using the X,Y,Z axis paths, pushing the least amount of pages to the client (using shortest logical path). Of course this does lack any VRML but it also requires no special viewer but knowledge of cgi-bin and fuzzy logic (to give optimal, logical axis paths) is required. It also saves on user download time as the images are still stored on a static frameserver dedicated to serving image frames and object surfaces. The host serves the custom image overlays and relays coordinates to the frameserver to which the frameserver serves to the client appropriate images. Custom tags such as image size and page location will still be needed to be included to understand relative image-hotspots. Further expansion could be attaching a limited AI tag to objects (say the imagemap tag could also include motion paths from the frameserver). Also, CUCMe could include other users viewing the same main page represented by a preselected image identifier for other users. These are just brainstorm level thoughts about a possible method to approach VR in the Inet - affordably, without adding more specialized viewers or browsers for the penny-conscious consumer. I am *not* saying that VRML is a _bad_ method just to suggest a low-end solution for today's users who can't run out to buy Web browsers/viewers or software/hardware specific to purpose such as VRML currently requires. SR Loggiodice VRAINN Development Centre, Inc.