Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Robert Osfield]

Hi Stefan,

On Mon, May 18, 2009 at 3:21 PM, Stefan Eilemann  wrote:
> I'm wondering what the network load of such a distribution would be, and how
> one could cache the data. The beauty of the distributed scene graph is that
> on a static scene virtually no data has to be transmitted. It seems to me
> that the distributed render graph at least needs to transmit the equivalent
> of display list ID's.

Yes, a distributed render graph would be kinda equivalent to
distributing display list ID's.  One would be tied to display lists
though, immediate mode would be support far more efficiently that can
be achieved with distributed GL implementations as the data that is
dispatch to the graphics card is held on the slave, and only updated
when needed.

The distributed render graph should be considered a step up from
distributed GL's, but it's not as efficient as a distributed app
approach where you distribute just high level commands.  A distributed
scene graph would probably sit in between these two in terms of
efficiency, at best it might be as good as a distributed high level
app, at worst it could be worse than the distributed render graph (in
cases where they are many dynamic nodes.)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Stefan Eilemann]

On 17. May 2009, at 11:11, Robert Osfield wrote:


Hi Tim,

On Sat, May 16, 2009 at 2:37 PM, Tim Moore  wrote:
I've been thinking about this too, but without the global cull.   
Are you

trying to avoid having a real scene graph on the local nodes and keep
lists of drawables and StateSets instead? I would think that  
broadcasting

the dynamic changes to the scene graph would result in less network
traffic than broadcasting lists of drawables, but I suppose it  
depends

very much on the application.


A fully distributed scene graph would probably be more efficient that
a distributed render graph approach, but it'd be more intrusive to the
scene graph design and implementation as all nodes would need an
fomarlised update mechanism.  OpenSG has such support but is a more
complicated object model than the OSG, which makes it more involved to
use and extend than the OSG.


In fact the only thing needed for this is a change notification  
mechanism. The distribution can build a 'shadow' hierarchy, and update  
the remote copies based on the notifications.


The update mechanism and serialization can live outside the scene graph.



The distributed render graph approach is lighter weight as you are
only tracking changes to the drawable leaves and state which is more
constrained and well encapsulated than other parts of the scene graph.
I believe it'll be much easier to implement this approach in a non
intrusive way than a full blow distributed scene graph, which is
really why I suggest it, we'd be able to get much of scalability of
the cluster without the complexity that normally comes with doing a
distributed application or distributed scene graph.


I'm wondering what the network load of such a distribution would be,  
and how one could cache the data. The beauty of the distributed scene  
graph is that on a static scene virtually no data has to be  
transmitted. It seems to me that the distributed render graph at least  
needs to transmit the equivalent of display list ID's.


FYI: The Equalizer source tree has an example of an OSG/Eq integration  
relying on a shared filesystem to load the SG. We are thinking of  
extending this example (and OSG) towards using a distributed OSG,  
pending on time/financing.



Best,

Stefan.

--
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Martin Scheffler]

Distributing the scene graph is the approach Avango is taking - 
http://avango.org/.  Avango is based on OSG and allows scene graphs distributed 
across machines. The authoritative version of scene graph branches may lie on 
different machines. Transformation matrixes are automatically distributed. 
I noticed that the avango project has not had any publicity here. I wonder why? 
I had to work with Avango a few years back when it was still based on 
Performer, and found it quite nice.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12350#12350





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Robert Osfield]

Hi Tim,

On Sat, May 16, 2009 at 2:37 PM, Tim Moore  wrote:
> I've been thinking about this too, but without the global cull.  Are you
> trying to avoid having a real scene graph on the local nodes and keep
> lists of drawables and StateSets instead? I would think that broadcasting
> the dynamic changes to the scene graph would result in less network
> traffic than broadcasting lists of drawables, but I suppose it depends
> very much on the application.

A fully distributed scene graph would probably be more efficient that
a distributed render graph approach, but it'd be more intrusive to the
scene graph design and implementation as all nodes would need an
fomarlised update mechanism.  OpenSG has such support but is a more
complicated object model than the OSG, which makes it more involved to
use and extend than the OSG.

The distributed render graph approach is lighter weight as you are
only tracking changes to the drawable leaves and state which is more
constrained and well encapsulated than other parts of the scene graph.
 I believe it'll be much easier to implement this approach in a non
intrusive way than a full blow distributed scene graph, which is
really why I suggest it, we'd be able to get much of scalability of
the cluster without the complexity that normally comes with doing a
distributed application or distributed scene graph.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Ahmed Nawar]

Jie,

We are using Diverse (http://diverse.sourceforge.net/diverse/) for cluster 
purpose.
Give it a look. it is support OSG.
You don't have to change the code for desktop or cluster.
and it gives us the same performance in the two cases.

thanks,
Nawar

From: osg-users-boun...@lists.openscenegraph.org 
[osg-users-boun...@lists.openscenegraph.org] On Behalf Of Todd J. Furlong 
[t...@inv3rsion.com]
Sent: Sunday, May 17, 2009 3:10 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

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  <mailto:robert.osfi...@gmail.com>>
>
> 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  <mailto: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
> <mailto:osg-users@lists.openscenegraph.org>
> 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
>
>
> -

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Todd J. Furlong]

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 mailto:robert.osfi...@gmail.com>>

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 mailto: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




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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Tim Moore]

Robert Osfield wrote:

> On Fri, May 15, 2009 at 10:41 AM, Joe L  wrote:
>> In our plan, the TDW will have around 30 displays.
> 
> OK, you'll definitely need a cluster for this.
> 

> 
> 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.
> 
I've been thinking about this too, but without the global cull.  Are you
trying to avoid having a real scene graph on the local nodes and keep
lists of drawables and StateSets instead? I would think that broadcasting
the dynamic changes to the scene graph would result in less network
traffic than broadcasting lists of drawables, but I suppose it depends
very much on the application.
> 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.
Tim
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Martin Scheffler]

Philip,

The NVidia Quadro Plex D4 seems to handle eight display outputs 
(http://www.nvidia.com/object/product_quadroplex_2100_d4_us.html - sorry for 
posting a german language link before).

Has anybody tried that out? I would like to know how complex the geometry may 
be for the system to display at an acceptable frame rate. Having eight displays 
on one machine would make clustered IG systems unnecessary for some 
applications that have limited complexity geometry. I am thinking of using this 
for my stuff, but would like to hear from others about their experiences on the 
matter.

So, has anyone used systems like this with OSG?

Cheers,
Martin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12326#12326





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Jie Liu]

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 

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



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

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Philip Taylor]

Martin,

The most I have seen is four screens on one (Windows) PC powered by two SLI
graphic cards, where each card has two video outputs. To go beyond this is
possible with a linux os using remote displays (DISPLAY 0:0 etc) but you
don't get something for nothing. The network traffic is high and the
resulting graphics are slower as the network reaches saturation even using a
UDP connection. I have no idea what sort of workload it places on your host
(or master) compputer if it does all the graphics processing and pushes
commands on to your network, but I would suggest again that this is not the
way to go. If it was, all the various IG protocols such as CIGI (see
previous posting on this thread) would never have been invented.

So you have reached that crucial decision point - limit yourself to 4
displays assuming it all works or write a CIGI (for instance) interface for
each node type (host and IG) and attach as many displays as you like.

Philip Taylor


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org]on Behalf Of Martin
Scheffler
Sent: 15 May 2009 12:13
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Help: Using OSG To Build Tiled Display Wall


Hi,

I am currently thinking about how to do a multi-display simulation with OSG
that uses a single machine to feed all displays. The app I am currently
working on requires multiple views, but is difficult to distribute across
machines because of some randomness components in my graphics stuff.

My simulation requires at least four projectors (or eight if necessary and
possible). I am thinking about using a Nvidia Quadro Plex system
http://www.nvidia.de/page/quadroplex.html.

Has anyone here used heavy-duty graphics hardware to feed four or more views
from one machine? What hardware setup do you use, and are you able to render
reasonably complex scenes? Or can you point me in a good direction for more
info?

Looking forward to your responses -
Martin[/url]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12206#12206





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Martin Scheffler]

Hi,

I am currently thinking about how to do a multi-display simulation with OSG 
that uses a single machine to feed all displays. The app I am currently working 
on requires multiple views, but is difficult to distribute across machines 
because of some randomness components in my graphics stuff.

My simulation requires at least four projectors (or eight if necessary and 
possible). I am thinking about using a Nvidia Quadro Plex system 
http://www.nvidia.de/page/quadroplex.html.

Has anyone here used heavy-duty graphics hardware to feed four or more views 
from one machine? What hardware setup do you use, and are you able to render 
reasonably complex scenes? Or can you point me in a good direction for more 
info?

Looking forward to your responses -
Martin[/url]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12206#12206





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Pierre Bourdin (gmail)]

Hi,
an interesting approach for a distributed rendering system is FlowVR...
http://flowvr.sourceforge.net/


I know openscenegraph has been used with Delta3D team with CIGI Image
Generator: http://cigi.sourceforge.net/ 
To not only advertise for concurrent project ;-)


Pierre.

Le vendredi 15 mai 2009 à 10:56 +0100, Robert Osfield a écrit :
> 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  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

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Robert Osfield]

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

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Joe L]

Hi Robert,

Thanks for you quick reply.

In our plan, the TDW will have around 30 displays.

Indeed, we have tried other solutions based on a smaller system ( 6 displays
contained ).


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?

Thanks

2009/5/15 Robert Osfield 

> Hi Jie,
>
> On Fri, May 15, 2009 at 9:22 AM, Joe L  wrote:
> > We are going to build our Tiled Display Wall (TDW) system.
>
> What dimensions?
>
> > Is there any material about employing OSG to do so or to perform
> distributed
> > rendering?
> >
> > Do I have to code a lot by using OSG APIs, or there are already some
> > modules/frameworks to achieve this?
>
> If you are using a cluster then a 3rd party library like VR Juggler or
> Equalizer is probably worth looking at.  You could do the clustering
> yourself, but this will be more work.
>
> If you can drive the system entirely from one machine then you'll be
> able to just use the OSG's native multiple context/multi-threaded
> support built into osgVIewer.  In terms of software and hardware this
> will be the most straight forward solution.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help: Using OSG To Build Tiled Display Wall

[Robert Osfield]

Hi Jie,

On Fri, May 15, 2009 at 9:22 AM, Joe L  wrote:
> We are going to build our Tiled Display Wall (TDW) system.

What dimensions?

> Is there any material about employing OSG to do so or to perform distributed
> rendering?
>
> Do I have to code a lot by using OSG APIs, or there are already some
> modules/frameworks to achieve this?

If you are using a cluster then a 3rd party library like VR Juggler or
Equalizer is probably worth looking at.  You could do the clustering
yourself, but this will be more work.

If you can drive the system entirely from one machine then you'll be
able to just use the OSG's native multiple context/multi-threaded
support built into osgVIewer.  In terms of software and hardware this
will be the most straight forward solution.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Help: Using OSG To Build Tiled Display Wall

[Joe L]

Hi,

We are going to build our Tiled Display Wall (TDW) system.

Is there any material about employing OSG to do so or to perform distributed
rendering?

Do I have to code a lot by using OSG APIs, or there are already some
modules/frameworks to achieve this?

You help will be appreciated.


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