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]> > 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]> 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] > 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
