Thursday, December 30, 2004

Ghost objects

Wicket requires that a normal TSpace be rendered with additional interleaved objects that are not actually in the scene. These are what I call "ghost" objects. They are not in the TSpace hierarchy, but they can be rendered and used as if they were. They are actually owned by the TPortal in the case of the filters, which allows the programmer to render a scene with additional content when scene through the portal. What this means for Wicket is that the CAD tools, such as the 2D draw surfaces and edit boxes would only be displayed through the portal.

A related issue is removing objects in a scene. This tends to be a bit more complex, as it would require every frame to be checked to see if it matches a particular characteristic. This might be better done as some kind of global flag that the objects themselves can test against.

2 comments:

Howard Stearns said...

I envision it being very common to have objects in a TSpace that are wrappers for objects in other TSpaces (and other tea parties). The wrapper object holds state related to position and orientation in the local TSpace, but geometry and most everything else are delegated to the "core" object elsewhere. The idea is that changes to the core in one space will appear in others of this kind of delegating copy in other spaces (and other tea parties). [When and how would the changes get propagated to other tea parties? I don't know!] I think there is some sense in which this is the same as any "remote application" object (e.g., VNC).

Does this have any bearing on the ghost objects you're describing here?

Croqueteer said...

It could easily be in a seperate TeaParty - or not. TeaParties do not have to have anything to do with geometrical or hierarchical relationships. They are an orthogonal concept - they are used to define collections of common shared objects with a particular group.