On Tue, Aug 9, 2011 at 3:40 PM, BGB <cr88...@gmail.com> wrote: > ideally, we should probably be working with higher-level "entities" instead > of lower-level geometry. >
I agree with rendering high-level concepts rather than low-level geometries. But I favor a more logical model - i.e. rendering a set of logical "predicates". Either way, we have a set of records to render. But predicates can be computed dynamically, a result of composing queries and computing views. Predicates lack identity or state. This greatly affects how we manage the opposite direction: modeling user input. > possibly, ultimately all levels should be expressed, but what should be > fundamental, what should be expressed in each map, ... is potentially a > subject of debate. > I wouldn't want to build in any 'fundamental' features, except maybe strings and numbers. But we should expect a lot of de-facto standards - including forms, rooms, avatars, clothing, doors, buildings, landscapes, materials, some SVG equivalent, common image formats, video, et cetera - as a natural consequence of the development model. It would pay to make sure we have a lot of *good* standards from the very start, along with a flexible model (e.g. supporting declarative mixins might be nice). > > I am not familiar with the Teatime protocol. apparently Wikipedia doesn't > really know about it either... > Teatime was developed for Croquet. You can look it up on the VPRI site. But the short summary is: * Each computer has a redundant copy of the world. * New (or recovering) participant gets snapshot + set of recent messages. * User input is sent to every computer by distributed transaction. * Messages generated within the world run normally. * Logical discrete clock with millisecond precision; you can schedule incremental events for future. * Smooth interpolation of more cyclic animations without discrete events is achieved indirectly: renderer provides render-time. This works well for medium-sized worlds and medium numbers of participants. It scales further by connecting a lot of smaller worlds together (via 'portals'), which will have separate transaction queues. It is feasible to make it scale further yet using specialized protocols for handling 'crowds', e.g. if we were to model 10k participants viewing a stage, we could model most of the crowd as relatively static NPCs, and use some content-distribution techniques. But at this point we're already fighting the technology, and there are still security concerns, disruption tolerance concerns, and so on. Regards, Dave
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
