From: michaels@vsl.com.AU (Michael Snoswell) Subject: INFO: Cyberterm Maillist, Feb 25 1993 Date: Thu, 25 Feb 93 13:02:22 CST Cyberterm Maillist - Feb 25th 1993 ---------------------------------- THE CONTINUING STORY... ==================== "Wow! Another Cyberterm mail list posting! I didn't know that thing was still going." NOTE: 1. Cyberterm will be referred to as CT hereafter. 2. The Cyberterm Protocol will be referred to as CTP The brief rundown: Yes the CT development is still going You can actually connect machines together with it now The graphics looks pretty bad There will be a release before June 26, 2071 This newsletter has similar headings as the last one, so that feeling of deja vu is well founded. THE PLAN ======== What is the plan to implementing CT? Well the design and programming phase got all mixed up, people didn't have the spare time they thought they had (including me!), the design goal moved so fast that Road Runner couldn't have tracked it, enthusiasm ebbed and flowed like a Mauritian tide (a lot) and many more coffees were consumed (oh, and cheese crackers) in the name of VR progress, discussing the meaning of the little hole in the side of pens and trying to get CT to work. In retrospect, we chewed off such a chunk that our little chipmunk cheeks were bulging to the brim, making progress a little tricky. We have, however, achieved a LOT and are very grateful to all concerned. A release will be made before 2071 and people can play with the code then (source and all). WHO GETS THE SOURCE CODE? ========================= As I said in the last newsletter: "Everyone receiving this mail will get the code. It's up to you to compile for your own machines. Binaries will not be made available. Documentation of undetermined quality/quantity will also be made available, but basically this is a system for programmers and you will have to read the code to find out how it really works." Well, I might make binaries available for PC and SUN Sparc only. I'm in the process of sorting out an anonymous ftp home site, probably in the USA. Eventually it should reside on all archive mirror sites. WHAT WILL IN RUN ON? ==================== Now here are a few changes from last time. We currently have PC and SUN versions running (that should include any X11 machine, but it hasn't been tested on anything else). An Amiga version should be ready by the release date. The Mac and Atari versions have fallen by the wayside, requiring graphics drivers for those systems (for the vogle graphics library). The code has been compiled with cc and gcc on the Sun. On PC, Borland C 3.1, Microsoft C 6.0 and 7.0 and DJGPP (1.8 I think). So it's all pretty stock standard stuff. System independant code is marked with glaring warnings and the appropriate #defines, so porting shouldn't be too much hassle. HArdware support os of now is just screen and keyboard. HMDs, gloves, LCD goggles and the like will require adept programmers with the appropriate hardware (something I haven't got!). WHAT WILL CYBERTERM CONSIST OF? =============================== This is divided into two parts: 1. What can it do RIGHT NOW?! ----------------------------- Development is being done mainly on a 486/33 and a 386SX/16 connected directly by serial link at 38.4 Kbaud. When you start the software the screen is blank. Default ASPECT objects in rend386 .plg format are read in and placed into the ASPECT database. All input is via the keyboard. Hit a 'c' and you, the LOCAL CLIENT connect to the LOCAL SERVER. The place you connect at is defined in ct.cfg, a text file with things like your name and a unique ID, entry point, default ASPECT distance update rate and update distance parameters, serial and tcp/ip connection details (including modem numbers and setup strings). A blue grid floor appears, showing the minimum height in a SECTOR and you have a default speed of 1 unit per second. Grid size is initially 1000x1000 units. What happened? Your CLIENT generated a REQUEST_TO_ENTER message. The SERVER checked to make sure you a) weren't already connected, and b) weren't trying to enter on top of someone elses PRIVATE_PERMASPACE (PPS). It created a PPS object with the default PPS ASPECT (a blue wire frame cube) and and created an object representing the CLIENT, with the default ASPECT (actually a cube as well, I haven't coded the 3D arrow for CLIENT default ASPECT yet) and the CLIENT's speed and name and ID info. The ASPECT description is a link to the appropriate entry in the ASPECT database. The SERVER then sent a MOVE_TO message and the CLIENT gets this and tells the graphics engine to update the screen for this MOVE_TO message. The keys u,d,l and r changed your motion vector up, down, left and right respectively. The keys U,D,L and R turn the viewpoint up, down, left and right respectively. Whoopee. If you turn all the way around and look at the place you entered (it's just blank space) and hit 'A' (REQUEST_ASPECT_DATA) the SERVER will search its object database, and find your PPS. If you're less than 100 units away from your PPS, the server sends the default ASPECT data, location and owner details of the object. This is used to create a graphics objects in the vogle object list, and the object number is linked to the client object data in the client's database. (which is seaparate from the server's database of objects and aspects) In the test system COM1 is currently hard coded to be the 1st remote connection. Hit 't' to transfer to the default REMOTE SERVER. A REQUEST_SECTOR_TRANSFER message goes from your LOCAL_CLIENT to the LOCAL SERVER which then creates a REQUEST_TO_ENTER message using details it gets from its object database and then sends the message to the REMOTE SERVER. The REMOTE SERVER treats the message just like a normal REQUEST_TO_ENTER and checks things (as before) then sends a MOVE_TO back to the LOCAL SERVER. The LOCAL SERVER, meanwhile has set a redirection flag on the virtual lines of each real connection (the one to the LOCAL CLIENT and the one to the REMOTE SERVER) so that all messages from the REMOTE SERVER, like the MOVE_TO get passed straight through to the LOCAL CLIENT and visa versa. The code actually explains this better, but you can get a headache trying to follow it if you're not carefull. Now at this point, if the guy sitting at the keyboard of the REMOTE SERVER hits 'c' to enter *his* LOCAL SERVER, then turns around and hits 'A' to REQUEST_ASPECT_DATA, he sees a blue cube for his PPS entry point, a cube for the remote guys PPS entry point and the remote CLIENT himself, moving along. Hit 's' to stop moving and ESC to quit the program. that's it thus far. Just to prove the concept, when someone is logged into your machine, you can log into theirs. There are also some help options to display a list of useable keys and your current local (PC only). The configuration file is set up to read in a whole host of initial parameters that are too numerous to mention here and are briefly mentioned elswhere in this file. 2. What will the beta release be able to do? -------------------------------------------- Main areas being worked on at the moment are : 1) Setting up the ASPECT handling so you can change your ASPECT on the fly. 2) Handling requests to enter someone's PPS and the subsequent SECTOR transfer. 3) Implementation of simple AGENTS 4) Send text messages 5) The construction of directory trees. These are trees that are created when the system is started and place a 3D representation of your current hard disk (or partition) into the LOCAL SERVER object database. So when you REQUEST_ASPECT_DATA you see a nice tree with branches for directories and leaves for files. This way the program might be vaguely useful as a standalone thing. 6) Implementation of elegant EXIT_SECTOR message handling. 7) (tentative) TCP/IP comms for unix systems. Other short term niceties: Bernie Roehl of REND386 fame has heroically offered to integrate the REND386 library into CT (on PCs only of course). This'll make the system almost useable on machines less than 486DXs. It will also enable glove and LCD glasses support to the system. More messages are defined and will be implemented time allowing. The most interesting of these include MAIL_MESSAGE, which can send just about any type of info, EXIT_SECTOR, for getting out of someone else's SECTOR gracefully, MOVE_FORWARD, MOVE_BACKWARD, REAR_VIEW (view yourself from up and behind your ASPECT). These are last ones mainly niceties of the graphics system and variations of the MOVE_TO message. WHAT IS THE CODE LIKE? ====================== Well...As mentioned above, the code should be close to ANSI standard. There are comments where things get cryptic and some long documentary paragraphs to explain why things are done the way they are (where it isn't obvious) and also when the code has shortfalls that must be reworked later to fully implement the system. There are about 10 modules (C and header files) with about 5000 lines total. WHAT IS THE MESSAGE FORMAT? =========================== So many people have asked me this! In short, I'm not going to write it down 'cause that'd take too long. To get the full details you'll have to read the code. However, just to give you an overview: Each message, at the lowest level, consists of a WORD (2 bytes) length and a 16 bit CRC, followed by the message itself. The msg is as follows, DWORD user id WORD msg size WORD msg type ... msg contents Msg contents, is for example of a MOVE_TO msg (the most common msg) XVECTOR position XVECTOR view vector XVECTOR velocity vector where XVECTOR is an (x,y,z) tuple of FIXED co-ords, where FIXED is a 32 bit fixed decimal (16 bit to left and right of decimal). Notice that each object and user has 3 vectors. Why separate view and velocity? Well, this is so that if you are flying along one way, you can look over your shoulder or behind you. The view vector should be controlled by an HMD position sensor and the velocity should be controlled by a glove etc. This amounts to riding an aircar. Your hands on the instruments control the direction you fly whilst you can look out through windows in any direction. Also this will allow later mods to the graphics engine viewpoint so you can view the world from outside your aircar (ie so you can see yourself). HOW FAST DOES IT RUN? ===================== On a 486DX-33 with a few dozen polygons you get about 10 frames per second. A 386SX-16 gets about 2 fps. A Sun IPC gets about 20 fps. Hence, you can see my desire to use Rend386 for PCs! I imagine Amigas, Macs and the like will get between 2 and 10 fps, which isn't really useful. If a better graphics engine exists in the public domain for those machines, then some kind person may port across to it, but the functionality of vogle will be tricky to emulate (as it emulates the Silicon Graphics Library, at least for the subset of functions which it supports). WHAT ABOUT THE FUTURE? ====================== I would love it if, say by the end of the year, there was an Internet SERVER available for anonymous serving to net users to log into and interact with others. The software isn't up to that yet but once the TCP/IP code is done, limited testing of this sort can begin. Half a dozen BBS type operators have expressed interest in using the system as a VR BBS, some for profit. Also I've had a few industry offers for commercialisation. But best of all, is that people are *talking* about all this stuff and what's involved, without that, ain't nothing gonna happen. I'd like it if the system got to pass it's infancy to a bootstraps stage where someone writes code to allow gloves to be used to draw 3D objects, maybe using an OBJECT that is a palette (with colours and buttons like "start a line", "define a surface point" etc). This would be more a graphics things than a CTP thing, but not a lot more is needed for such a system to be implemented using the current version of CTP. This would probably require the implementation of AGENTS, the OBJECT I've hinted at in the past. These are OBJECTS in the object database of a SERVER which have, in addition to an ASPECT, a program, which is really a list of rules describing how that OBJECT behaves in response to certain messages. For example: You, the CLIENT, send a DEFINE_AGENT message to the SERVER. This is essentially the same as an ASPECT_DATA message where you define an ASPECT (either for youself or a PPS area you own). The program may be something like "If you receive a MAIL_MESSAGE from someone who is not your owner and the message is text then change ASPECT to a flat rectangle and the text message itself". This AGENT would be like a blackboard. You could leave it residing at your PPS entry point. People send messages to the AGENT and the AGENT's shape changes so it looks like a piece of paper with the message on, which you could then read when you get back. This is a fairly simply example, but I hope you get the idea. More complex AGENTS may have the same ASPECT that you have, and you send it to a conference and program it to respond to MAIL_MESSAGES from other by replying in the same way you might (or better still, it sould then send a MAIL_MESSAGE back to you, wherever you are). The local database engines could be linked to hardware for telepresence work at remote sites. The strength here will be in the power of the AGENTS programming language obviously, but also in the CTPs ability to support this and a SERVER's ability to execute the AGENT's programs. Once we've gotten that far, then we would have a VR programmer's paradise, an application that allows all sorts of systems to be developed for specific areas. One thing this sytem relies heavily upon is network bandwidth. However, as it is, it is *useable*, a very important criteria a felt had to be met in the first incarnation. Another area many people have spoken to me about is sound. This could be implemented as part of the ASPECT, perhaps by defining aspect level 27 to always represent sound. If it's there you use it, if not, forget it. This brings up the issue of customisation of the CTs to specific machines, environments and applications. Although sound is a general feature, so few people could adaquetly use it at the moment, that I have left that issue to the side for the moment. The ASPECT levels of many such features will be reserved for future systems (if CT lasts that long!) so individuals may implement those features without risk of clashing or making their code incompatible. (Personally, I love the idea of sound attached to aspect, so as things approach from behind you can hear them coming) One area that has been glaringly omitted to date is the concept of DYNAMIC ASPECT. I've thought about this and, as for sound, ASPECT levels will be reserved for such implementations, but I haven't really thought about it in relation to CT, except to realise that it'd be pretty tricky. Some of my ideas briefly are for rotations and spline curve following of ASPECT SEGMENTS on a per unit time and per distance travelled basis. I have thought to use AGENTS to create multi-part ASPECTS, the AGENTS then have their motion programmed individually. To get a "walking dinosaur" ASPECT, you just download the AGENT definition from a public domain database of objects. I must may that this is very exciting stuff but unfortunately I haven't the time nor the experience to do this. I'm sure there are many of you with swaths of know-how about how to make this system better/faster etc. What I hope is that people will take CT, pull it apart, adapt it, discuss it, use it and generally get fired on to see that these things can be done and here's a few ideas to start with. Depending on the response, there may be further releases of CT, or someone else may offer to take over the show. Or, if anyone is willing to offer a position to pay me to work on this then I'd be thrilled :-) There *is* a lot of work to be done yet, but it's not *that* hard and I hope the many different ideas and practical applications people are working on can come together to make it all happen just a little faster. A WORD ABOUT MONEY AND LICENSING ================================ "Uh oh", I hear you say. The code will be FREE. Some sort of read.me file with the release code will make a humble plea for a pitiful recompense for the years I aged on this project (of the order of $US20) if you are feeling really rich and are a true philanthropist to the burgeoning VR development fraternity (or this tiny piece thereof) then you may be moved to respond. Otherwise, an acknowledgemnet if you use any of the code or the protocol later or a threat letter or two would be sufficient. (Well, maybe a postcard to stick on the fridge). Some people have actually asked about paying for this system, particularly some pay-BBSs that can see some awesome potential. Hmmm, I said to myself, I can get rich very quickly! Hmmm not! I replied. There will be no accounting features per se in the system. A given CLIENT can only connect up once to a REMOTE SERVER, so I guess that is something. It certainly wouldn't be hard to add some timing to CLIENT connections, but I'm not about to do that to a beta release. As I may have mentioned in private correspondence with some people, I would like the source for CT to be freely available, but if a company or individual rewrites it or supes it up for a particular machine, then they may well sell the binaries (in much the same way that X11 source is available but many companies sell customised binaries). If any interested parties really want a customised version for a BBS or Internet site (which isn't meant to be commercial anyway) then I'll consider all suggestions. RESPONSE AND COMMENTS AND OFFERS ================================ Many, many people have responded to previous postings and docs on Cyberterm. If you asked to be a beta tester please don't feel bad if I haven't responded because I had about 20 people offer and only wanted one or two. Also, many thanks to the programmers who have offered their services, many of whom I was unable to use due to time and organisational contraints at both ends. All contributors will be acknowledged in the release. Those of you whom I said I will use but haven't contacted, then hang in there as I may still require additional help before the release. Finally, many thanks to the interested parties and enthusiastic mail from supporters and well-wishers. This correspondance has been crucial to the system development in terms of sorting out ideas and concepts and design problems. Clearly many of you are interested in this area and are forced to admit that besides being interesting, it's just darn fun! So any comments will be graciously received and responded to. cheers Michael Snoswell PS Please note my new email address below for all correspondence. If you asked to be on the mail list and didn't get this posting (ie you read it in sci.virtual- worlds or elsewhere) then let me know because I may have been unable to send to the return address I got from your request mail. Or I just may have lost your reply with the 80 odd other peoples correspondence. Of course, if you're not on the list, then mail me anyway, or mail me if you *specifically do not want to receive the Cyberterm source code or want to be removed from the list*. -------------------------------------------------------------------------------- Michael Snoswell michaels@vsl.com.au Vision Systems Limited +61 8 343 0627 South Australia