[osg-users] [3rdparty] Maintaining osgWidget Window aspect ratio on resize
Hi, I'm starting to use osgWidget to create a GUI in a GraphicsWindowWX and am attempting to figure out how to best get an osgWidget Window to maintain a defined aspect ratio on window resize. It appears that it's not possible to do this through subclassing as the only virtual functions are intended to handle internal redrawing internal widgets. I'm currently only using precompiled binaries and so would rather look for a quicker solution over setting up the proper build environment to build from source. Is this possible with osgWidget out of the box? Thanks, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45126#45126 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting osgWidget::Window to maintain aspect ratio on graphics context resize
Hi, First off, I accidentally created this topic initially in the 3rd Party subforum and can't seem to delete it on my own. I'm starting to use osgWidget to create some basic GUI elements in a GraphicsWindowWX and am attempting to figure out how to best get an osgWidget Window to maintain a defined aspect ratio on window resize. It appears that it's not possible to do this through subclassing as the only virtual functions are intended to handle redrawing internal widgets. I'm currently only using precompiled binaries and so would rather look for a quicker solution over setting up the proper build environment to build from source and modify osgWidget::Window. Is this possible with osgWidget out of the box? Or, alternately, are there any 2D GUI libraries that can be integrated with OSG that can easily interface with osg::Texture classes? Thanks, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45129#45129 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on osg::Cone
Hi, You'll need to add two things to the geode or drawable's state set: - An osg::BlendFunc with the proper arguments for the blend you want - Calling setRenderingHint() with osg::StateSet::TRANSPARENT_BIN so it's in the proper render bin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45101#45101 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render osgViewer::View main camera view solely to texture using FBO
Hi Tim, Thanks for the suggestion. I'll definitely take a look at it. I saw your response in another thread about RTT and was going to PM you before I saw you respond here. From reading the OpenGL specification, FBOs can't be shared between graphics contexts, so it doesn't look like I have an option, anyway. After making this change, everything looks as expected. I was just hesitant to attach a graphics context I didn't intend to draw to to the secondary view only to be used for RTT, but as its main camera is set to render to texture via FBO only, I suppose this isn't a problem. Is there anything wrong with this implementation? Thanks, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45083#45083 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render osgViewer::View main camera view solely to texture using FBO
Hi again, Thanks for following up. I've tried it before with an attached pbuffer, but was - and still have been - getting unpredictable results. As before, if I simply place a camera as a node in the scene and attach a texture with FBO implementation, it will render the subgraph to the texture no problem. If I attach a texture to the main or slave camera of a view, whether I use a pbuffer for offscreen rendering or have a separate window, the texture will simply be filled with random data in video memory. The camera will otherwise work properly, as if I comment out any RTT-related lines and change the graphics context to the window's, it will render to a viewport without issues. I would have simply used the currently working method and updated the camera's matrices directly, but we're using more complex manipulators and making that functionality redundant is an ugly solution. I took a look at examples like osgdistortion, and, implementation purposes aside, can't see any differences in camera and scene setup that might cause this. It clearly has to be me, given the fact that this exact functionality is used as an example and I've gotten the same result on two different computers (running Windows 7 on Nvidia GTX460/560). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45029#45029 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render osgViewer::View main camera view solely to texture using FBO
Hi, It's been a few weeks since I've exposed my lack of knowledge of OSG, so I figured I'd do it again. I'm having a bit of difficulty figuring out how to render a camera view to an FBO only when that camera is part of a View. I have no trouble in RTT when I simply place a camera in the graph manually, but I need it to be part of a view so that existing manipulators can be used. This could probably be done by attaching a pbuffer as a graphics context, but we're trying to not use deprecated functionality for the product. I also want to avoid drawing to any sort of hidden window, unless there's some sort of optimization under the hood that adds no performance overhead. Is there an easy way to have a View camera RTT using an FBO without the existing graphics contexts? Thanks, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44966#44966 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issues when creating seamless panorama using multiple cameras
Hi Robert, Thanks a lot for getting back to me. The main issue I had at the time was that, when using a single osgViewer and using slave cameras with view offsets, I was seemingly getting additional rotation about another axis inconsistent with a simple fixed post-multiplied rotation about a single axis. I'm absolutely certain it was an issue with my understanding of things, and will revisit this since it was my understanding as well that an osgViewer with slave cameras was the proper approach to this. Thanks a lot, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44822#44822 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Issues when creating seamless panorama using multiple cameras with arbitrary FOVs
Hi all, I'm (very) new to OSG, though do have some prior graphics experience (which could use brushing up, I'll admit). However, I just can't seem to determine the best solution to this problem. I'm working on an application where, in one window, an aircraft HUD view is being rendered. Originally, a single osg::Viewer with one camera was being used, which works fine. However, I'm trying to implement what are essentially peripheral views which are rendered to the same viewport as the same view, on the left and right sides (I'm not using a single camera as these peripheral views will be compressed horizontally and will allow the user to set an arbitrary FOV for these views, stretching up to 180 degrees across all three views). There is no issue with this part, per se - the problem arises from the fact that there are jarring issues at the seams between viewports. Objects which are partially drawn on each viewport have slight, though very clear, slight issues in offset and scale, such that when they're crossing the boundary, scale and immersion is broken. I've attempted two solutions to compare them. Currently, all views have the same field of view and are drawn with equal size in the viewport. In one method, I add two slave cameras to the viewer, which has its rotation set via a manipulator (this was the implementation before I started the project) with a view offset rotation of +/- main camera's horizontal field of view about the Y-axis (gained by multiplying the vertical FOV by the aspect ratio, all retrieved via getProjectionMatrixAsPerspective()) passed in as an argument. From my understanding, as the main camera's view matrix is post-multiplied by the slave's offset to get the final slave view matrix, this should be a rotation about the local axis and give the correct result. In fact, in this case, not only is there a slight scale/position issue, but there are odd issues with the angle of the horizon getting slightly more off as the roll increases (though the rotation itself seems to be about the correct axis, and tests with other axes are proven to be definitely incorrect). I've used both matrix and quaternion rotations in case there are precision/accuracy differences with no change in results. I've taken a look at setUpViewFor3DSphericalDisplay() which seems to use a very similar method (though I don't quite get the rotation about the Z-axis). In my other (naive, first) implementation, I use a composite viewer with three identical cameras each with their own manipulator, set each to identical rotations each frame, and calculate pitch and azimuth offsets for the peripheral views based on the aircraft roll which is also calculated each frame. This actually seems to work better than the single viewer solution, but is not what I want and certainly doesn't seem to be the correct solution. I'll add code if/when I can (need to clean it up quite a bit, as I've tried this about twenty different ways) and will add information as often as I can. Thanks for any help you can give! -Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44488#44488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
