Jie, Robert gave you a lot of good info, but I just wanted to add a few things:
VR Juggler (http://www.vrjuggler.org) comes with an OSG-based application example if you are just looking to load & navigate OSG-compatible models on a cluster.
I'd advise against using Chromium based on the bandwidth requirements which translate into poor performance. However, if you go with Chromium on an X-Windows system, you might want to try DMX with a Chromium back-end to turn your tiled wall into one large desktop.
-Todd On 5/16/2009 2:47 AM, Jie Liu wrote:
Hi, thank you all, people. Your information are very important. I believe we have to re-evaluate our plan. I'd like to search for more information about multi-display wall stuff. Wish you all a good day~ :-) 2009/5/15 Robert Osfield <[email protected] <mailto:[email protected]>> Hi Joe? Jie, could you please sign with your first name so I know which one to use when addressing you rather than having to do a best guess, thanks, On Fri, May 15, 2009 at 10:41 AM, Joe L <[email protected] <mailto:[email protected]>> wrote: > In our plan, the TDW will have around 30 displays. OK, you'll definitely need a cluster for this. > Do you mean that : > If I would like to use OSG, I will have to additionally do the task > management, network synchronization, and distributed rendering? The OSG doesn't provide this cluster manage functionality, it's focused on rendering on a single image system, albeit with capabilities of doing multi-thread, multi-screen output. The two options you have right now are to go with a distributed GL implementation such as Chromium, or a distribution application implementation such as facilitated by libs like Equalizer. There is a third possible solution would require mods to the core OSG, or at least subclasses from it, and is something I've been wondering about for a while. The approach would be to do a distributed render graph, where you do a cull traversal (or several cull traversal) on the master for the whole view frustum that gives you a list of drawables, modelview+projection matrices and state inheritance graph, then you broad cast this list to slaves on the cluster. These then traverse this rendering graph and cull out what leaves aren't in their local view frustum. On each slave you'd cache the state and geometry and update this only when the master changes their value, to avoid having to dispatch all this data on each new frame. The distributed render graph proposal above sits between the low level distributed GL approach and the high level distributed application approach like done with Equalizer. The distributed GL approach requires more network and CPU bandwidth, most doesn't require any application modifications to do the cluster, while the distributed application approach minimizes network bandwidth but does require you to design your application with the cluster in mind. The later approach is more work, but provides better scalability. The distributed render graph approach has the potentially of scaling reasonable well, while at the same time need little more than a cluster specific cluster configuration being used in the viewer, so once you have this inbuilt capability it's would be easy to move from a single desktop display to a cluster by just changing a viewer configuration file. Robert. _______________________________________________ osg-users mailing list [email protected] <mailto:[email protected]> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jie Liu Visualization Research Group Center for Information Science, School of EECS, Room 2104, Science Building No.2, Peking University, Beijing 100871, China ------------------------------------------------------------------------ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
