Viewer v2.0

I'm just Braindumping here - so please don't wonder about the somewhat unstructured document this will change over time.

Interface

In the near future the Viewer will have a new Interface to other DWARF services. Since the planned changes are of mayor nature the old Interface will not be kept. So older Applications (ProjectArchie / ProjectHeart) must either be ported to the new Interface or just use the old version (will be tagged in the cvs). Until the new Version works properly no changes will be applied to the cvs trunk. For the time of development there will be a cvs branch.

The Interface will be designed following the command pattern (this is where we have to add UML diagrams soon) For now following commands (and their meanings) are planned:

• CreateObject: Add an 3D/2D Object with given geometry to the SceneGraph
• MoveObject: Move an Object from one place in the scenegraph to another (cut it off from old parent attach to new parent)
• ReplaceObject: Replace an Object in the scenegraph by another representation
• DeleteObject: Delete a 3D Object from the SceneGraph
• SetProperty: change arbitrary parameters - need to identify the shape node and the (key,value) pair.
• ConnectObject: Connect the Translation of one Object with the out Fields of a PoseData sink Object (SoTrackedObject)
• DisconnectObject: Disconnect the above made connection (maybe this is not necessary because we could implement a undo - stack)

• ReplaceScene: Replace the whole 3D Scene
• SuperImpose: Overlay the 3D Scene with 2D Information e.g. Text

• SetLayoutStrategy: set the layout strategy for the layout manager.
• SetIntrinsicCameraParameters: set the intrinsic camera parameters.

Possible commands that are not planned to be implemented immediatly:

• Group: Group several objects together.
• Highlight: To visualize that a SceneGraph Object is "selected" and thus changeable.

Events vs. Method Calls

See (ViewerWishList also). I have to think about the command pattern again and how to apply it in distributed environments before this section will be filled with content.

Anyways I've got some pro's for modelling the Viewer Interface with the command pattern encapsulating RPCs:

• Encapsulating the remote method call is good and makes coding easier for the service using the ServiceViewer.
• With a nicely designed command pattern we could encapsulate some sort of retry logic (to handle network errors and service startup issues)
• If all retries fail a clearly distinguishable Exception can be genereted inside the command object which makes error handling easier on applications side.
• The obvious ones (taken from Gamma et. al): The Command pattern encapsulates a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations.

As always some con's (or rather questions):

• Don't know how to implement the command pattern in the DWARF framework
• What about different programming languages

Encapsulating Geometry

Right now geometry is encapsulated in a SoAdvancedShapeKit - the main purpose of this custom node was the ability to set the PoseData directly at each object. This approach won't be used in the new version of the Viewer. That means we can "downgrade" to the standard SoShapeKit out of following reasons:

• It provides already light, material and translation nodes to influence the Properties of the encapsulated Geometry.
• It provides also a setProperty(key,value) method (although its not documented in the official coin3d docu - must be a doxygen issue)

That implies following changes in the Viewer class structure:

• The SoAdvancedShapeKit class is not needed anymore.
• The SceneGraphObjectFactory class has to be changed so that it uses the SoShapeKit. We could even go without a factory at all but we should use it to initialise the SoShapeKit instances with our wished default settings.
• We need a new custom Node that is inherits from both the POA_DWARF::SvcProtPushConsumer interface and Inventor SoNode class and just writes the values of incoming PoseData events into it's SoSFFields and thus makes them accessible to the SceneGraph. (see chapter moving geometry). This makes the PdataReceiver class obsolete (almost - propably it will be used to set the viewpoint).
• We need to come up with a solution how to process the above listed commands (most of the functionality can be found in SdataReceiver and UactionReceiver classes, those will be replaced)

Service Description

Since we're not sure how the command structure will look like I'll restrict myself to the processing of PoseData here (see ViewerWishList for more Info).

Since PoseData comes in very frequently we will stick with the event-based mechanism for that communication channel. In the actual version of the Viewer the number of PoseData receivers is determined on the basis of the needs in the xml description, this limits the granularity. Since we implement a new Hybrid node that inherits from SoNode and from POA_DWARF::SvcProtPushConsumer for each of those Nodes a new Need has to be generated dynamically and if a tracker wants to deliver PoseData the connection is set up by the servicemanager. That means that for every object that was inserted with the CreateObject command a new Node and a corresponding need will be generated. Later on Geometry can be moved according to the position of the tracker with the corresponding need using the MoveObject command.

However the need with the ThingType^? viewpoint has to be handeled separetly - I'd say: we'll just stick with the PdataReceiver class (btw we could rename it to PDataReceiver which would be the appropiate name)

Moving Geometry

The new mechanism for moving Geometry (not in the Scenegraph but in space) relies on two concepts:

• SoTrackedObject inherits from SoNode and from POA_DWARF::SvcProtPushConsumer it receives PoseData events delivered by trackers. It then extracts the remainder of body and writes the values (x,y,z)(x,y,z,w)(Timestamp)(Accuracy) into SoSFFields. Each SoTrackedObject is identified by the ThingID^? of the PoseData it receives.
• The Geometry SceneGraph and the dataflow graph are seperated. Moving Geometry in 3D space is realized by changing the topology of the dataflow graph. This is done utilizing OpenInventors natural methology of SoEngines . The SoEngines can be thought of arcs of the dataflow graph which can be inserted between one of the SoTrackedObject Nodes and one or many of the SoShapeKits encapsulating Geometry. The SoShapeKits with incoming arcs then move according to the position of the tracker in 3D space.
  

Q: A picture could help me understand this concept of changing the dataflow graph :)
In particular, i am interested in a hierarchy of trackers and tracked objects in 3D -- MartinBauer - 02 Dec 2003
A: Well I'll draw a picture when I got the time to do it :)
for your understanding: this concept is almost the same as outlined in ViewerWishList. If you wan't to move (in 3D Space) a object you make it a child of the Node receiving the corresponding PoseData, but only in the dataflowgraph (Read Chapter 13 of The Inventor Mentor). That means that the Node receiving the PoseData is not moving around but just passing the Position information, which prevents us from moving around lots of empty separators representing real world objects.

Q: What i am wondering is how to store this persitently, like in a database. I would think that you should be able to position something relative to something else and store this in a database. This is basically like deleting one object and inserting it on another location, but without deleting and regenerating the according infrastructure around it, e.g. connectors for incoming PoseData -- MartinBauer - 03 Dec 2003

A: I think the new meanings of MoveObject and Connect/DisconnectObject as described above should cover this issue since with those commands you can change the topology of the geometry and dataflow graph without interfering eachother.
And well about the persistency - the SceneGraph itself is a database and there are means of storing it e.g. in the file system etc. -- OtmarHilliges - 04 Dec 2003

A: With this approach you could build huge networks of SoTrackedObjects and/or 3D Objects - just a question how flexible the Interface is. Maybe you wan't to explain in more detail what you intent to do so the Interface can be designed according to your needs. -- OtmarHilliges - 03 Dec 2003

Q: Martin are you sure that building tracker and trackedobjects hierarchies inside the viewer makes much sense? Or wouldn't it be better solved with the new FilterServices developed in ProjectBar SEP? -- OtmarHilliges - 03 Dec 2003
A: I think i have to find somebody explain me that concept of the filter services in some more detail to answer that question :) -- MartinBauer - 03 Dec 2003