From: Jeremy Lee Subject: Re: TECH: My standard is better than your standard. Date: Sun, 26 Jul 92 04:02:40 EST In article you write: >In article <1992Jul19.055422.12836@u.washington.edu> Jeremy Lee > writes: > >>>However, I still have to worry about all the stuff in the office next >>>to mine. >> >>Probably the best way to deal with this is to use a system where if an >>object doesn't get seen for one frame, then the chance of even >>attempting to render it for the next frame goes down. > >A good idea, but what do I do when I first enter the world? Do I have >a long start-up period while I receive and render the entire environment? >(Also, some graphics implementations will find it easy to keep track of >which objects are actually visible; others will find this very expensive >to do). Well, the "Start up time" should be on the order of a second or two, so it's not that bad. They way I'm thinking of it is this. Assume that you have a standard Z-buffer drawing system. You have objects that are within the field of view, but are obscured, say by a wall. If your Z-buffer drawing code (crude simplification, it may be a totally seperate section) keeps track of each polygon, and for one frame does not draw a single pixel (which is reasonably easy to check) of it, then the chance of drawing it for th next frame goes down. It might reduce the chance by 1/30 to a lower limit of 1/30, so that in a 30fps system, each object is attempted to be drawn at least once. That means that if the objects comes into view at any time within a second, then it will immediatley be resored to being attemped to be redrawn every frame. Of course, you might want to fiddle with values to get them right, but if you use this in conjunction with the other efficiency systems (not drawing objects that are behind you, objects with the surface normal facing away..) then it may increace the efficiency somewhat. >>I agree. It's easier to put the messages in a queue, with timestamp >>attached. If the object want to pay attention to the timestamp, then >>that is their business. > >Right. (Of course, sending a timestamp with every single message does >add to the overhead and lowers the performance). Not really. Most OS's and network systems put a timestamp on it anyway, so it's more like utilising a facility that is already there. >>I personally like the idea of 128 bit numbers to describe spatial >>co-ordinates. > >I still maintain that 128 bits is overkill. How often do you need to >model the entire universe at the quantum level? And having all that >extra data to send around the network would degrade performance even >further. I think we should start with something smaller, but that from >day one we should make provision for expansion. That's difficult, because we are defining such a basic parameter, that to make it extensible would drastically degrade performance (how would you like to have to do the extra checking every time you wanted to perform an arithmetic operation!) and to change it at a later date would break all current systems. It is said that there are only three numbers in CS. 0, 1, and infinity. (128 bits is the functional equivelant to infinity in this universe anyway) I have worked in depth with many many systems that both did and did not make provision for what, at the time, was considered ridiculously massive expansion (a 1981 computer with provision for a 24 bit pallete - the BBC micro, cf. the IBM pc, 640K limit) but which in a fairly short time has proved itself to be completely worthwhile. If your argument that the only reason to ditch 128 bit numbers is that it is not necessary *now*, then I would assert that your argument is invalid. How often do we need the entire universe at the quantum level? All the time! (In reality anyway, and I thought that VR was to go BEYOND the bounds of reality) I run a 32bit RISC computer. To do a 128 bit add would require, lets see, (tuneless humming and the sound of turning pages) 4 instructions. Iff the registers already contained the two numbers. (ps, that's 4 clock cycles.) ADD R0,R4,R8 ADC R1,R5,R9 ADC R2,R6,R10 ADC R3,R7,R11 (eqivelant to R0-3 = R4-7 + R8-11) To do it with two registers pointing to the address of the numbers it would take 6 instructions which is 6 clock cycles and 8 memory cycles. LDM R0,{R4-R7} LDM R1,{R8-R11} [ .. same as above .. ] To store the results somewhere, say at the position of R12: STM R12,{R0-R3} This can all be done in much less time than a floating point operation, with much more precision, mind you. Also, it can also be done faster and with more accuracy than using 32 bit numbers with a scaling factor. To use a scaling factor would take a multiply/divide, and would loose precision, so 32 bit numbers will end up with below 32 bit precision. If you are worried about storage space, or net bandwidth, then don't because 128 bit absolute positions will not be necessary that often, and any intelligent scheme will support delta encoding. You simply have to tell the other objects the *offsett* from the last position. Also, if you use a compression algorithm before sending-recieving (hardware is already here) then I'm sure that unused resolution will get compressed out. >>>>Extensiblity is a requirement for any protocol. >>> >>>Agreed!!! >> >>Of course. > >I think this is one of the points we *all* agree on! The problem is that how do you make your basic way of dealing with numbers extensible without drastically loosing portability or efficiency. I think that 128 bit numbers will solve that, and give us a lasting standard. >>Routing and all network stuff should be trasnparent and should have no >>bearing on what constitutes a world. In that sentence, you are basically >>saying that objects are restricted to worlds in close physical >>proximity, and I therefore wouldn't be able to connect to a world that's >>in Tokyo, for example. > >Not sure what you mean by "a world that's in Tokyo"? A virtual world doesn't >really *have* a physical location. But the description of message routers that was given was that it they were physically based, and relied on the topology of the connecting network. >As to why routers are important... even with very, very high-bandwidth >networks I don't think we want every object in the multiverse having to >broadcast to every other object. We need some way of limiting traffic >to those who are interested in it. (Broadband vs baseband, sort of). >Different "worlds" (and perhaps different regions within a world) are >different "channels". How does EMail work? I think that is the best model we have. >>Sounds like your routers are central controllers, and I thought we all >>agreed that they just won't be able to cope. > >Not central controllers; *distributed* controllers. Even "controllers" is >the wrong word. They're routers; they help objects communicate efficiently. The description posted indicated that the "routers" did much more than simply message routing, including deciding which objects other objects would talk to, based on whether the router believed they were relevant, in an effort to reduce traffic. That sounds like a controller to me! Of course message routing is needed, but the routers should only be passing the message on, deciding which router to give it to next as a simple excercise in quickest-path. The routers should NOT be deciding *whether* to pass it on or not! If the sending objects didn't think the message was necessary, then they wouldn't have sent it. Imagine an analogy. An EMail router somewhere began dropping messages because it decided that there was no need for someone in Australia to be conversing with someone in the USA, and besides, it would reduce net.traffic. Thinking about it, I can still see a need for a little more intelligent message routing along these lines: A message gets sent to 10 objects. With todays system I would have to send 10 messages, and these messages would follow the same path for quite a lot of the way. In other words, it would be redundant data. Surely a little intelligent routing can be done where the routers only fan out the messages when needed? >>See my paper. >>[...] >>See my paper. >>[...] >>See my paper. >>[...etc...] > >All right, I get the idea. You want me to see your paper, right? :-) >Looking forward to it. I posted it right after that. I expected the plain text to get posted to the newsgroup, but apparently the moderators have archived that as well. The postscript (complete with neat diagrams) should be somewhere as well. I suspect it will be in the archive at wheresitcalled along with everything else. Care to comment Mr. moderator??? >-- > 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] Interesting to converse with you Bernie. Together I think that a real good system will get hashed out. *********************************************************************** * . 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 * ***********************************************************************