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 <liujie...@gmail.com> 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
