Hi Carsten, thank you very much for your comprehensive reply. I think we will set up our system with the master node solution, because the implementation of something like "tea time", which is used by Croquet, seems to complicated.
Cheers Philipp Am 24.04.2007, 13:20 Uhr, schrieb Carsten Neumann <[EMAIL PROTECTED]>: > Hello Philipp, > > Philipp Roßberger wrote: >> Hi, >> we want to build a distributed application with OpenSG that behaves like >> Croquet (http://www.opencroquet.org) regarding scene replication. > > hm, I don't know Croquet, but from quickly reading a few paragraphs on > their site the they seem to distribute a scene to a large number of > users and then coordinate changes from each user. Is this, the ability > to allow everyone on a network changing the scene, what you are after ? > >> We plan to have at least three computers in our setup, which share one >> scenegraph. Now it should be possible to manipulate the global shared >> scenegraph from every machine and replicate the changes to all other >> systems. Is it possible to do this with OpenSG? > > The usual scenario for OpenSG clusters is one client that creates and > modifies the scene and a number of servers that receive the changes and > render images (client/server are used in the X11 sense here). However, > this is not the only possible setup, since you can transmit changes > between arbitrary machines, but you have to coordinate them yourself > (the single client, multiple server setup is easy to coordinate because > you only have to merge changes from the client into each severs scene, > so that might explain its popularity ;) ) > >> I scanned the mail archives and found several threads about scene >> replication. So far my understanding is, that it is possible to >> propagate >> scene graph manipulations via sendSync(). Is this the right direction? > > Yes, but unlike Croquet there is no "universal time" that applies > changes in the correct chronological order. You will have to take care > of when to transmit changes to other machines and when and in what order > to apply them to the local copy of the scene. > >> Finally I wonder how an architecture for the described setup should look >> like. One node, that receives all chances and notifys all other nodes? >> Or >> should the other nodes be directly notified by the node, that changed >> the >> scene graph? > > Having a master node that collects all changes and then distributes an > up to date scene to the other nodes is probably much easier to implement > and seems to fit better with OpenSGs model. However, from what I've read > on the Croquet site their goal seems to avoid that master node and have > the slave nodes coordinate amongst themselves. This approach seems a lot > more difficult and you probably would have to implement similar > mechanisms as Croquet to coordinate changes between nodes. Basically > OpenSG provides the means to transmit changes to a scene over the > network, coordination of changes from multiple sources is up to the user. > > Maybe one of the users who run applications on a cluster can give you > some more information. > > Cheers, > Carsten > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
