From: broehl@sunee.waterloo.edu (Bernie Roehl) Subject: Re: TECH: My standard is better than your standard. Date: Sun, 26 Jul 1992 16:32:41 GMT Message-ID: Organization: University of Waterloo In article <1992Jul26.075108.9516@u.washington.edu> dlwood@mailbox.syr.edu (David L Wood) writes: >If the universe is defined by a message router [...] That's the point of contention, really... but more on this later... >that the message router should only inform you >(the client) of the existence of an object only if it occupies one or more >pixels after being projected with perspective shrinkage. Right. Of course, this depends on what your display's resolution is; do we want the router to have to deal with things like that? If it does, it isn't just a router... it's something else entirely. The other problem is that this still doesn't reduce the amount of data enough. If I look out my window right now, I can see the house across the street. Including the house in my rendering database is no problem; however, including all its contents (down to the forks and knives in the kitchen drawers) would be. Yet if it weren't for intervening walls, I could certain see a fork at that distance. With just size/distance clipping, most of the objects in the house wouldn't get clipped, even though I can't see them; more memory and more workload for my poor renderer to have to deal with. > store in the machine's memory only the geometry and attributes (and > ...behavior?) of those objects that contribute to a pixel or more after > perspective projection. Not clear if by "the machine's memory" you mean memory in the router or in the rendering station. The latter I would agree with, the former I wouldn't. In any case, I suspect that isn't enough. >I don't know about you, but objects flickering in and out in my peripheral >vision would be a bit distracting! :) But, clipping is best handled by the >renderer, not the message router. It's all related, though... If someone moves around in the hypothetical house across the street, do I need to know about it? Based on size/distance, yes... based on obstruction by walls, no. And even if I can see it, I can't necessarily interact with it (we need to reduce the number of object-object collision tests that must be done, since otherwise it's an N-squared problem and *very* expensive). >I really like the idea of a message router controlling the passing >of messages between objects in a world. Which raises all the problems of centralization. A new object enters the world, the router has to do size/distance testing between it and each of the 10,000 objects already there. >the clients should never be trusted to >perform any task that you can do yourself (where "you" is the server). That's a fundamental philosophical difference between us. The server should never do anything that can be handled by the clients, since there is far more computing power in the clients (of which there are many) that there is in the server (of which there is but one). The router should do as little as possible, and if we can figure out a way to eliminate it altogether, so much the better; otherwise, sooner or later, it will become the bottleneck. >128 bits is not enough. Not enough for *what*? Quantum-level descriptions of the *entire universe* can be handled in 128 bits. It's not like internet addresses or color palettes or DOS memory; we're talking the basic physical dimensions of the universe, here. >You could use a system of variable length coordinates. An id byte would >indicate how many bits (or bytes, take your choice) are used to locate a >coordinate. Really, anything to extend the ability of the protocol >is better than putting a limit like 16 bytes. I agree with this wholeheartedly. >I'll admit 16 bytes is >fairly hefty, but if you want to dump an entire universe into a file [...] Wow, between your high-capacity disk drives and Jeremy Lee's processor, you'd have one heck of a VR station! >Honestly, how much CPU time is burned up by sorting out messages and >occassionally computing a size over distance function? Not much. For 10,000 objects at 30 frames/sec? Using Cray XXII's as routers may be a swell idea, but here in Canada our research budgets are kind of limited right at the moment... >You NEED a central control by definition of DOMAIN. A fundamental centralization vs decentralization debate. I think we're zooming in on the most important issues here... let's keep at it. -- 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]