Hello Dardo! Glad to see that there is someone sharing the pain :). Thank you for the very detailed response.
I don't like the "one manipulator per render node" solution that much. It requires both forwarding all the events to every render node and also communicating the changes to camera position/orientation back to the head node so that those get pushed to all the render nodes again for the actual rendering. It basically breaks the clean separation between application logic and application view that EQ has. The second solution that you and Stephan described seems more appropriate. Also, you bring up a very valid point of osgEarth requiring the existence of an OpenGL context. I fought that issue when putting my current integration together. Basically the reason why osgEarth requires (and actually tries to spawn) an OpenGL context is so that it can query for OpenGL capabilities. It is also not particularly clean when it does so I think (it doesn't restore the previously bound context) and it offers no direct way to "disable" the capability querying. The way I worked around it in my software (which uses osgViewer with a graphicsWindowEmbedded on each eq::Window) is by actually overriding the default OSG GraphicsContext with a stub implementation that basically does nothing. This way, when osgEarth tries to query for capabilities, it does so within the existing OpenGL context that has been graciously provided by Equalizer. Other than this point, the rest of my implementation is pretty standard (single distributed object for the camera state + other rendering parameters, all interactions are handled at the app node) but as I mentioned, this doesn't work that well with osgEarth since I can't directly use it with EarthManipulator. I'd love to see how you tackled this issue (accessing the render thread's gl context from within the Config main loop in a safe way, I would be happy with that solution since I always run the app node in head-full mode). I can share my implementation with you as well (with the same caveat of it being very dirty code at the moment :P), but as I mentioned, it is not particularly complex. -- View this message in context: http://software.1713.n2.nabble.com/Communicating-information-FROM-the-rendering-code-to-the-application-logic-tp7585385p7585391.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
