Hi Preet, On 28 February 2012 09:16, Preet <[email protected]> wrote: > * What do the parameters passed to the > osgViewer::GraphicsWindowEmbedded constructor (x,y,w,h) actually do? I > played around with the values and it had no visible effect on my > displayed result
They tell the GraphicsWidnowEmedded object where about the window it's representing is in desktop coordinates. > * What does GraphicsWindowEmbedded do behind the scenes? Since you > don't explicitly specify a GraphicsContext for it, does that mean it > uses the OpenGL context of the framework you're embedding it into? GraphicsWindowEmbedded actually does nothing behind the scenes at all - it's a non op class designed to make it possible to reuse the osgViewer::Viewer and CompositeViewer classes in places that already provide the graphics context and are strictly single threaded and have a single window. It's really tricking these classes that a designed to work with multi-threading and multi-context capable systems where makeCurrent() and swapBuffers() implementations are accessible to work without doing this operations so when calls to makeCurrent() and swapBuffers() are made by the viewer classes nothing happens. Since nothing happens it's entirely up to the calling app to do it for the viewer because it can't do itself. Since GraphicsWindowEmbedded is design to avoid properly implementing the key context management functions on the OSG or a subclass side it does restrict how you can use the viewer classes. It's very much a crude approach to provide viewer functionality, easy to get working yes, fully capable no. You can't add the full capabilities back in when using GraphicsWindowEmbedded, if you don't need multi-threading or multi-context this will be fine, but if you do look elsewhere. Actually implementing a GraphicsWindow properly is the most powerful way to adapt 3rd party graphics contexts with the osgViewer, and this is done by the osgQt::GraphicsWindowQt class, as was as the GraphicsWindowX11, Win32, Cocoa and Carbon implementations found natively in osgViewer. > * I noticed that the viewport is rendered onto the window in absolute > coordinates. With QtQuick, when you create an item to display on the > screen, it has a child/parent relationship and coordinates are > relative to the parent. Moving the parent will also move the child as > you'd expect. This doesn't happen with GraphicsWindowEmbedded though, > probably because with QtQuick, all the elements are painted onto one > 'canvas' (I think), and GraphicsWindowEmbedded just paints straight > onto that. I know absolutely nothing about QtQuick or how you've implemented the integration with GraphicsWindowEmbedded so I can't say anything about this. > * If, instead of having GraphicsWindowEmbedded draw on my screen > whenever I call the viewer's frame() method, is it possible to render > the viewer camera's output to a texture that I could manually draw > onto a quad or something? This way I don't have to specify absolute > coordinates for the viewport like I mentioned above. I already tried > this by rendering to an osg::Image, then painting it on the screen > with Qt, but I have a relatively old computer and > osg::Image->readPixels() takes too much time. My results with the > osgscreencapture example were also pretty terrible (15-16 fps @ > 640x480). If you want to do off screen rendering then this is very different thing, GraphicsWindowEmedded is not the best thing to do this, what you'll want is a pbuffer, osgViewer provides this. I really don't have a clue what you are trying to achieve in the end with your application, or why you are attempting to use QtQuick. Might I suggest to explain to the community what type of application you are trying to develop, what platforms you are targeting and then let others suggest to you which route would be best rather than picking a non standard solution without actually saying why you've done this. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
