On Wed, Jan 31, 2007 at 11:29:37AM +0100, Karsten Otto wrote: > The problem here is the clash of two different mindsets, computer > graphics people versus knowledge engineering people. The first prefer > scene graphs, which are well understood as Braden pointed out, and > are good for rendering. The second prefer semantic descriptions of > objects and their relationships, which is slightly less well > understood. Striving for a mix of both bears the potential for > disaster, or at least to bad compromises as you pointed out.
And just to make things more complicated, there's the networking aspect of all of this, which is if you're not very careful with the structure of your data model, latency is going to eat you alive ;-) > That said, I'm actually quite happy with the current VOS model. The > flexible typing allows a vobject to be both a semantic and geometric > entity. It can be a misc:Avatar with descriptive properties, and a > a3dl:Cone heading a scene graph structure. There are even child > vobjects which are useful to both aspects, e.g. a3dl:position & > friends. So far, this approach has worked out nicely, right? It has! Although as you pointed out in a previous email, a better design still may be to try and separate dynamic data (position, orientation, etc) and semi-static (appearance) a bit more, to facilitate sharing and caching. This is going to require quite a bit more design. > What I'd like to do is improve this model in a few places, from a > semantics point of view. For example, an a3dl:bounds child specifying > the rough size and shape of a 3D entity would be helpful. It could > give non-visual clients a better understanding of a scene, without > requiring them to understand the actual scene graph data in order to > compute this information. I agree. This would be useful for rendering as well -- one way of prioritizing downloads would be to get a list of bounding boxes and start with the ones that are closest to the camera and also work largest->smallest. You could also render transparent boxes as placeholders. > Another point is the relation between the sector and its contents. So > far, the relations only specify generic membership, as a set of > conceptually unsorted and arbitrarily chosen contextual names. This > does not mean anything to anybody, neither from a semantic nor scene > graph view. I'd like to see a more structured approach here, using > proper "role" names instead. For example, "m:avatar" for user > avatars, "m:scenery" for (static) background entities, and so on. > This makes it much easier for a client to select child vobjects of > interest for inspection and caching. Did I mention this in a previous email? I must have. Yes, I was thinking of just such a top-level organization, splitting mostly-static and mostly-dynamic entities into separate subgroups to facilitate caching (among other things). Also, our experience is that best practice VOS design is that mixing static (schema-defined) and dynamic entries in a vobject's child list is bad, and instead dynamic lists should be kept on a separate child vobject (these might be embedded vobjects in s5, though). -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
