Hello, thanks for the background, Adrian.
On 3. Dec 2008, at 10:14, 3dhelp (via Nabble) wrote: > The osgViewer::Viewer::frame does the whole mutlithreading stuff. > means the method sync the whole scene graph for a safe update pass, > then cull, draw, paging can continue in multithreaded passes, if the > user has setup one of the different mutlithreading modes. This makes > the integration into equalizer a hard stuff, but i am sure there are > really nice integration variants. actually i tough much > about the integartion but i don't get the time to implement it. i am > too snow with time critical work. But i can suggest to have a deaper > look into the osg::Camera / osg::CameraNode. May this would be the > easiest way to integrate the osg into eq. So my hunch was right. I think the integration should be done through the Camera(Node). You would basically have one camera per pipe (thread), which you setup at the beginning of Channel::frameDraw with the current contextual data, and then fire of the rendering. > May there will not be a eq. like integartion for osg. may we just > lunch a camera (part of the whole scene) on a rendering machine and > readback the framebuffer and transfer it to the eq engine, where eq > but to gether the parts. i am not yet sure how we should sync > it with eq. I think this would be suboptimal, as you have to duplicate things already done by Equalizer. Furthermore, it might prohibit some new features to work transparently. > as i think to understand eq, the eq manages the camera (main) and > then it can be splitted the view frustum (final rendered view) into > n cameras each of them render just a part, Depends what is called the 'camera'. Equalizer manages the projection (frustum) and view (head transform) part of the transformation chain. The application still manages the model part. > Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
