> Mitra writes:
> > Peter - dead reckoning works fine for dead-objects, but not nearly as well
> > when the objects are human controlled.
>
> To some extent, that's true. However, for the (fairly common) case of
> someone walking across the room, you're still farther ahead to send
> dead reckoning information. Of course, you really want something smarter
> than *just* dead reckoning.
Dead reckoning is an essential concept for a distributed environment.
Dead reckoning isn't for dead objects, it is for predicting the
intermediate movements of objects to lower bandwidth. It is like the
in-betweening between keyframes. Call it predictive algorithms, local
behaviors, or whatever.
Dead reckoning can always be overridden by a new message, and is an
essentially scalable concept. Since dead reckoning algorithms are
implemented as code (local behaviors) on client machines, they can be as
sophisticated as people figure out how to make them.
Of course, if you have the bandwidth, processor power, and application
reason to pass theough a complete set of movements, then dead reckoning
would not be necessary in that particular case. But I suggest that even
something as simple as a bouncing ball or flashing light would benefit
from dead reckoning.
>
> > With human controlled objects and
> > update times of that kind of frequency people are going to be walking
> > theough walls all the time.
>
> Right, but that can be handled by the browser; if it knows that there's
> a wall coming up, then it sends an "end-time" (or "end-location") for
> the object so that it's guaranteed to stop in time.
>
> > [...] you have to have a better scheme. DIS
> > with Multicast groups appears to do this until you start looking at the
> > assumptions. With update rates around 5 times per second you can't get
> > more than about 5 to 10 people in your Zone of interest, this means 1 or 2
> > per multicast group (assuming Don Brutzman's Hexagon approach), the problem
> > then is that people are switching groups all the time
>
> Which is why you wouldn't use hexagons. They work fine for battlefields
> (which is why military simulation board games use hexagons), but for real
> world simulations they're the wrong choice. A much better approach is to
> use the natural subdivisions that every world has; for example, an indoor
> scene (like the museums and galleries everyone seems to be building) it
> makes more sense to divide into rooms. For a jungle scene, you'd have
> irregularly-shaped areas; for a desert, by all means use hexagons.
>
Hexagons are gesat for some things, but a room is seldom a hexagon. I
think Bernie is right that a generalized solution is needed.
But the more general issue is identifying the real sources of
bottlenecks. Let's face it, we can't have a multiuser square dance with
distributed avatars with lots of dancers (maybe lots of watchers) over a
28.8 modem on todays computers. This is not the fault of hexagons, zones
of interest, or protocol packet size.
> > in our tests they
> > are switching multicast groups every few seconds, at which point the
> > Multicast group control messages kill you.
>
> Agesed! The trick is in how you partition the world.
>
> If the zones are too small, you wind up switching groups far too often.
> If the zones are too big, you run the risk of getting over-crowded
> (this assumes the use of "social protocols"; people will notice how
> crowded a room is, and think twice before entering it).
>
> > The architecture I'm trying to put together for the API is
> > designed so that you can have a DIS module, and other people can build a
> > server based module. Since these are plug-ins, or behaviors they don't have
> > to all be the same, they just have to talk to the browser theough the same
> > API.
>
> Yes! That's exactly the right way to handle it (IMHO).
Yes! Yes!
>
> > P.S. What is the average size of one of the entity state PDU's (including
> > packet overhead)?
>
> You mean the actual DIS PDU's? They're currently *way* too big, but
> some work is being done on that. In any case, we wouldn't actually *use*
> DIS; it would simply serve as a jumping-off point.
Sounds like generalizing DIS to non-military dual-uses to me. The World
Wide Web simply uses the military designed internet (check out DSI) as a
*jumping-off* point for uses beyond the original Arpanet. Hey, it looks
to me that multicasting protocols were put into the internet to support
distributed simulations (particularly military) in the first place (any
Internet design historians out there?)
>
> --
> Bernie Roehl
> University of Waterloo Dept of Electrical and Computer Engineering
> Mail: [email protected] Voice: (519) 888-4567 x 2607 [work]
> URL: http://sunee.uwaterloo.ca/~broehl
>