-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Anders Backman wrote: > Its called osgVR > > http://www.nbi.dk/~gronager/osgVR.html > > Now I know that Michael hasn't updated the code for a while, but this > should > certainly work as a good starting point on what you want Jan. Thanks for the pointer, it looks good. I will have a look at it - it may be actually enough for what we need. > I use to have the same issues when we were discussing the clustering of > some > of our applications. > The problem in our apps were that the scenegraph itself was very dynamic > both in terms of adding/removing nodes but also in change of > transformations > for many objects, interaction (events) etc... > > So I felt a slight burden on explicitly "cluster" such an application, in > comparison of writing one app, and just specifying where the renderingnodes > were. This is also my feeling. Even though the scene graph will probably not have nodes added and removed on the fly, there will be plenty of position updates and such. Cluster is not really an optimal architecture for such application, but you have to work with what you have. > OpenSG has implemented clustering on a broad level. The whole scenegraph is > designed for parallellism. That was an early decision from them. That also > had a large impact on the usability and the complexity of the code, > whenever > a part of the scene is changed it is copied and the copies has to be > syncronized, a lot of work. That's exactly why I would prefer to use OSG than to port your Replicant code or osgCal to OpenSG in order to be able to do character animation we need. I am not fancying having to deal with some heavy access synchronization code. > I said in the beginning we had some issues with the thought of having to do > explicit clustering, but now with Quad DualCore, multiGPU machines, who > needs clustering? > > I told myself in the beginning of 2001, dont do clustering, just wait for > the next generation onyx, and now they are here! > For a small sub-fraction of the price :-) Well, most multi-gpu machines can host at most two PCI-E cards (these sold as SLI-ready). That means at most 4 video outputs. A CAVE still needs 6 + a console. You could do that with the quad-sli mainboards, but these systems are rare and hugely expensive. Not to mention cooling and general stability issues. I think that the clusters are here to stay for the foreseeable future. Agreed, Onyx was by far the best solution for this - put as many pipes in as you want (up to 8 was the limit?), 128 CPUs should be more than enough and the geek factor is hard to beat :) Unfortunately it also blew one's budget several times over :(( We used to pay over 75000 Swiss franks annual maintenance for a small one - just two pipes and 6 CPUs. For that money you can build one hell of a cluster already. Regards, Jan - -- Jan Ciger GPG public key: http://www.keyserver.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFFK+A1n11XseNj94gRAq4mAJ97S/ZprbkQiZoQE1O83Y/BecHJFgCg4P4/ 4leKwOzzI71GFt2tvAaXGTw= =7oqY -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
