On Oct 25, 2:48pm, Linas Vepstas wrote:
> > Transcription is a very little-know feature of the Inventor
library,
> > (documentation other than the .h file would help), but I think it
> > proves you wrong that keeping a server/client in sync with scene
> > deltas is hard if you use Inventor.
>
> OK, I'll buy that. The next question then is:
>
> o What is the protocol sent & received?, or, at least, what would it
> look like if it were human-readable ASCII?
There are 7 commands:
insert(SoNode *node) : Specify a new root node
insert(SoNode *node, SoNode *parent, int n) : Insert a new child
remove(SoNode *parent, int n) : Remove a child
replace(SoNode *parent, int n, SoNode *newNode) : replace a child
modify(SoNode *node) : Change a node's fields
plus an END token send by a prepareToSend() routine, called when a
bundle of changes have been made to the graph
and a NUM token that precedes the other commands specifying how many
changes the receiver should expect.
References to nodes are written as the hexadecimal address of the node
in the sender's address space. The various commands send just a
reference, or both a reference and the ASCII file format for the node.
The receiver maintains a dictionary mapping the address of the node in
the sender's address space to the address of the node in the receiver's
address space.
A program that wants to keep sender/receiver in sync needs to add the
appropriate transcription command(s) wherever it modifies the scene
graph, Inventor has no automatic mechanism for detecting and
broadcasting changes.
> o What is the bare minumum of the protocol needed to do MUD?
You could probably get away with even fewer operations than the 7
described above, at the expense of making it harder to translate from
scene graph operations to transcription operations-- for example, a
group->replaceChild() maps nicely to a replace() operation, but could
also be done by a remove() followed by an insert().