I've gone down this path - namely osgEarth in Equalizer. It gets a bit tricky,
and I'm not happy with what I've got so far but it kinda works (and looks great
on a 4x3 2560x1600 tile wall).
One problem is that in order for the EarthManipulator to work, it needs a full
copy of the SG (at least one with the elevation data, e.g. for world picking).
At least two choices here:
You could have the manipulator installed on all nodes and figure out which one is
"authoritative" and send eq::Config mouse events there.
Or you have the manipulator installed only on the appNode, but if you have the SG in the
appNode, and it doesn't have a render thread - it needs a "fake" render thread
in order to update the scene graph so the manipulator can do its thing.
I've hacked a scheme whereby if the appNode doesn't have a render thread, it
runs an OSG pbuffer context offscreen and mouse events are sent to an attached
osg viewer. Then the osg::camera matrix is extracted from the manipulator and
sent out in the eq::View to all the render nodes.
osgEarth requires a capable GL context, so this means the appNode has to have a
GPU - but it doesn't have to be a destination channel.
I even play games such that if the appNode *does* have an eq render thread,
this offscreen context is not used and it just uses the real context attached
to the destination channel. But its still ugly, e.g. it has to change the
viewport to the entire scene in order to, e.g., translate mouse events properly.
If osgEarth's SG could be serialized, then it could be much more like eqPly.
But for now I just have every eq node run a full OSG instance on all of its
defined pipes.
I'd love to see what you come up with, Harris. I'd even share what I have if
you're interested, understanding that its a bit of a mess. Its been a while
since I was neck deep in the details, there were a bunch of other gotchas if I
recall (like osgEarth creating its own GL contexts before Eq got fully started).
- Dardo
On 04/25/2014 06:47 AM, Stefan Eilemann wrote:
On 25. Apr 2014, at 12:24, "cpapado [via Software]"
<[email protected]> wrote:
My main concern with keeping a local copy of the scene graph in the config's main thread is the
"threat" of random OpenGL calls happening without the presence of an OpenGL context. Now,
my understanding is that OSG doesn't really do that without an explicit request for a frame, but it
still feels a bit "dirty" from a software engineering perspective to duplicate a piece of
information that exists on the same machine and in the same process if there is a way to cleanly
get access to it without hamstringing EQ's performance.
You could use the same copy of the SG if you use the default draw_sync threading model.
The copy would then be maintained by the config, and only the lazy-load access method
needs to be locked. eqPly uses a similar model, although with a static "SG" and
async thread model.
In draw_sync, frameFinish is only unlocked after your local Channel::frameDraw
are completed, therefore you can modify the manipulator in handleEvents without
locking. Using the Config to store and lazy load the SG would then even work
for appNodes without a pipe render thread, and no duplication does occur when
its not needed.
HTH,
Stefan.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
