(Message inbox:92) Return-Path: pulkka@cs.washington.edu Received: from mail.fwi.uva.nl by gene.fwi.uva.nl with SMTP (5.65c(FWI)/3.0) id AA00580; Tue Feb 16 06:57:03 1993 Received: by mail.fwi.uva.nl from june.cs.washington.edu with SMTP (5.65c(FWI)/3.0) id AA07847; Wed, 17 Feb 1993 00:19:53 +0100 Received: by june.cs.washington.edu (5.65b/7.1ju) id AA16053; Tue, 16 Feb 93 15:19:53 -0800 Return-Path: Date: Tue, 16 Feb 1993 14:57:03 -0800 (PST) From: Aaron Pulkka Sender: Aaron Pulkka Reply-To: Aaron Pulkka Subject: Re: Regenesis To: Bram Cc: cschaffe@flounder.rutgers.edu, dove@well.sf.ca.us, edan@netcom.com, fontenot@comet.rice.edu, graham@cs.montana.edu, groenewo@fwi.uva.nl, hjtoi@jyu.fi, jw@ddsdx2.jhuapl.edu, lyn@matt.ksu.ksu.edu, peugh@wam.umd.edu, vexar@watserv.ucr.edu, wing@lysator.liu.se, pulkka@cs.washington.edu In-Reply-To: <199302150907.AA15137@carol.fwi.uva.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Greetings Mudders, From reading your messages I get the feeling I am not going be satisfied with the changes to Regenesis as they have been proposed. Maybe I'm wrong; can someone address these concerns? [ 1 ] Lack of depth is a serious problem. Without depth the backgrounds can only be for show and not ever be truly interactive. I always know what objects I can interact with since they are in the foreground. [ 2 ] No information is saved by the client between sessions. Without this, I must reload images everytime I logon, even though they may not have changed for weeks, months even. Without timestamps on images there is no way to reliably do this. [ 3 ] Client machine resources are not fully utilized. When I run on a PC, Amiga, Sparc, or SGI -- I get the same interface. With the SGI I could hook-up eyephones or get shutter-glasses for my Sparc, but there is no way to utilize these resources with only 2d information being sent. Number 3 is key. We need 3d information in order to move mudding into the next phase. Objects can be represented as sets of 3d polygons (players included). Views should be participant POV (point-of-view), not ethereal side view. Environment objects, such as rooms (players...) will define a local coordinate system for other objects to be placed in reference to. Player objects can have several environment objects defined inside them (hands, belt...) which move objects placed within. When an object moves, the client can decide how often it cares to update and in what manner to update. Likewise, the client can decide at what granularity to allow movements by its user. For example, if I am a 486 client, I will only allow my user to make large movements (like across the room to a table, or across the room out the door). When other objects make movements, I will only update once they have moved a significant amount. However, as an SGI client I will allow my user to make fine grained movements and update all movement changes of other objects that are available. The timing here to make everything look and feel right for different clients is tricky, but doable. Fine grained movements don't need to be sent across the network in their entirety. They can be used for local rendering, but only send the relevant info [ie (Xs,Ys,Zs,Ts) -> (Xf,Yf,Zf,Tf) would be sufficient for most moves]. Don't flame too hard on this paragraph, the details are numerous and hard to explain. There are obviously alot of details that come up when trying to use many different clients to their full potential, but alot of that work can be shuffled off to the clients. What is important is that there be enough general information available to be used in a number of ways. The trick will be to determine a minimal subset of general information to get the job done (without increasing network traffic exponentially). As far as clients saving things, this is a must to speed up rendering & to reduce network traffic. Many standard objects can be included with the client. When a user enters a room, the measurements of the room, the user's position/orientation in the local coordinate system, and the list of objects (with time-stamps) can be sent. The client can then query for any objects which are not stored in the local database (or are out of date). Objects can have multiple representations, the generic and close-up views. When running around between rooms you would see players as a generic object (maybe sex/race specific, preferebly not). Then if you want to see the details you 'look playerX' and see what they really look like, objects and all. The same can be done for generic objects laying around. Weapons, tools, books, etc. may all have generic objects for general use (all these could be included in the generic client database) when you create an instance of one you get the generic appearance, plus you get to add your close-up views. As a PC client, I may only rarely look at close-up views due to the slow rendering times. If I have a really hot client running on a RealityEngine, I may just say 'screw the generics -- show me only close-ups.' Remember, these close-ups are also 3d objects, not just pretty pictures. Maybe detail view is better than close-up . Anyway, I have spent enough bandwidth; all comments, replies are welcome, Aaron -- Graduate student (graphical human interfaces & robotics) Comp Sci & Engr Dept +--------------\ Univ of Washington, FR-35 | Aaron Pulkka > pulkka@cs.washington.edu Seattle, WA 98195 +--------------/