From: Jeremy Lee Subject: Re: TECH: My standard is better than your standard. Date: Wed, 1 Jul 92 00:13:49 EST :r.letter In article Bernie Roehl writes: >In article<1992Jun27.041149.23307@u.washington.edu>vanderwerkend@LONEX.RL.AF.M >IL (Dan Vanderwerken) writes: >> >[Jeremy Lee writes:] >>>Now, what language are we going to write this in? Don't know. We are, >>>however, going to have to make a new one. It's not going to be C, or >>>C++ [...] None of these are adequate, >>>and I'm not going to argue on this point! Should have added the smileys :-) :-) :-) >All right, feel free not to argue. However, I suspect C and C++ will be >the languages used for VR work for years to to come. This will be true >whether you argue or not. :-) I think that we have different ideas here. I personally don't care what language you use to write the basic system, what I am arguing about is a language to be used *inside* the VR. While you are in there. Whether we will actually program or put coloured blocks together is still an undecided point. Once I'm in the VR I don't want to have to pop back outside and fire up vi and gcc to define a new object. How flexible will the system be then? >[Jeremy Lee continues:] >>>Note that these scripts >>>will be executed by whatever machine is running that environment >>>system, so you can have a lovely big cray acting as a dial-up server >>>with your little workstation taking care of the graphics. > >I see this as being a *very* unlikely scenario. The entire trend in the >computing world is in precisely the opposite direction; away from big central >mainframes that people dial into, and towards networks of smaller >machines working together. What you propose is the way VR would've been >done in the 1960's, if we'd had the fast graphics hardware then. The way >it'll be done in the 90's and beyond will be through distributed systems. >(In My Humble Opinion). Undoubtably. But currently, to implement the system I have described, you are going to need a *big* computer. A lot of processors connected together via lots of wires still constitutes a *big* computer for me. As far as I am concerned in a distributed environment, I can treat the whole of the internet as just one *very big* computer. >[Back to Dan:] >>I think this new language will probably be a descendent >>of one of the more popular languages of today (C, C++, etc) > >Agreed. Of course, the entire discussion of "what language do you implement >your objects in" is sort of peculiar, unless we're seriously looking at >timesharing on a Cray. If the virtual universe is distributed across a >number of machines, and objects communicate with each other by sending >messages, then everyone can implement their objects in whatever language they >feel like. The rest of the virtual universe doesn't need to know what >you code in, as long as the objects you create respond in a reasonable way to >the messages that get sent to you. Oh, yes it does. How else can you shove an object across to a different environment? If you run a distributed environment then you are going to have to have some sort of standard. If the objects that you created were confined to sitting only on your local machine, then things are not going to go well. And how will "visitors" to my local space know what to do? >>I agree with others, libraries >>will probably provide the means of doing VR for quite some time. > >I agree as well. Not inside the VR. Not for defining proper modifiable objects. I'm thinking a little broader than a hardwired system for one purpose. I'm tring to think of a system that can be used for any purpose, however impossible that seems. >>>[...] IRIS workstation for our kids to play around with. That is when VR >>>will take off > >I think it'll be a heck of a lot sooner than that. I think we'll see low-end, >commercial VR systems within the next 12 to 18 months. And what will you be able to do on it? Walk around a CAT scan image? Investigate the current state of your network connections and change the logical router connections? Interactivley debug an Artificial Neural Network? (My pet project). I stand by my conviction that we do not yet have the computing power, unless you have unlimited access to supercomputer, to do VR. Until then, an affordable VR system will be little more than a toy. Don't hype VR to be something it isn't yet. Remember AI. People came out with the first backprop networks and said "We now have AI, and it can do everything." People soon learned that you might be able to do anything with it, but with the limited computing power available to say, NASA, they still weren't able to do anything with it. I think that we are still a few years away from powerfull, useable ANN systems. >This is why I think it's critical for us to come up with standards *now*, >not later, and why those standards must be useable on *existing hardware* >(i.e. should not require everyone to have an IRIS on their end and a Cray >on the other). My suggestions, for example, will work on current systems, but they will be at a simple level, and you will pay a definite performance price for it's configurability. The point is that the same objects and scenes will still be useable on machines 20 years from now, and vice versa. You won't have to write new software to increace the performance, because scalability and enhancement is built into the system. Right now, it will be useless on anything below an IRIS, but the same software will be scaleble right up to a cray. If you will notice, I did not define a graphics standard, but the way the objects interact. Your view machine could be a Mac, but will only be able to handle a *very* simple scene. >If we fail to define workable standards soon, then we'll be faced with a >proliferation of incompatable proprietary standards that will hinder the >growth of VR while it's in its early, formative stages. Worse yet, a >defacto standard may emerge that will be driven forward by forces that don't >necessarily favor good design. Exactly. >I see a strong analogy to the development of personal computing. I still >remember when personal computer enthusiasts were discovering they could >build little circuits to let their S-100 bus systems display text on their >television screens; now VR enthusiasts are building little circuits to >interface Powergloves and Sega glasses to their 386's, Macs and Amigas. I don't care about hardware. >I think we can learn a lesson from the early days of computing, in terms of >how standards develop if left to themselves. Which is why you have to define a standard that is extensible. IF worse comes to worse, you can extend it to handle the objects used by another system. Name a standard to date that is extensible? Can you redefine C so that at the beginning of the compile you give it a whole bunch of EBNF diagrams which totally redefines the language? >The first standard operating system in the 8-bit world was CP/M. It wasn't >great, but it got there first and become widespread. We're still living >with it today; MS-DOS uses the same basic operating system >interface as CPM, right down to register values. You can take a program >you wrote in 1975 for an 8080-based CP/M system, not change one line of >code, and reassemble it to run on your 486 under OS/2. > >That's part of the reason MS-DOS is so kludgy; it's still living with some >bad design decisions made a long, long time ago. Yes and no. DOS5 is a hell of a lot better than the original PCDOS. It was extensible to a degree, but no further. >Once a standard is adopted, even if it's a *bad* standard, it tends to stick >like molasses. Getting there first is much, much more important than anything >else. NONONONONONO!! The first one there is traditionaly the one that fails. It's always the second or third which made a considered entry that became the standard. If you rush in "to be first" then you will fail. >We must develop *good* standards that work *now* -- a standard designed for >ten years from now will wind up being a footnote in the history of VR. OK. I'll do that. Right, everybody is now only allowed to work on IBM '286s, because that's the current level of widely accepted PC use. Anything else won't be available to the general public for, oh, two or three years! :-) Don't you think it is slightly better to develop a *brilliant* standard that works tommorow, knowing that tommorow will actually arrive in slighty under 24 hours? In any case, "Standard" is deceptive, because any "Standard" should be, but should allow modifications to be made and communicated through the "Standard". >-- > Bernie Roehl, University of Waterloo Electrical Engineering Dept > Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca > BangPath: uunet!watmath!sunee!broehl > Voice: (519) 885-1211 x 2607 [work] *********************************************************************** * . Jeremy Lee s047@sand.sics.bu.oz.au Student of Everything * * /| "Where the naked spotless intelect is without * * /_| center or circumference. Look to the light, * * / |rchimedes Leland, look to the light" - Dale Cooper * ***********************************************************************