Re: [osg-users] OSG website unresponsive
Same problem in New Jersey, about halfway between Colorodo and South Africa. -Don osg-users-requ...@lists.openscenegraph.org wrote: Send osg-users mailing list submissions to osg-users@lists.openscenegraph.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org or, via email, send a message with subject or body 'help' to osg-users-requ...@lists.openscenegraph.org You can reach the person managing the list at osg-users-ow...@lists.openscenegraph.org When replying, please edit your Subject line so it is more specific than Re: Contents of osg-users digest... Today's Topics: 1. Re: OSG website unresponsive (Chris Jaquet) Subject: Re: [osg-users] OSG website unresponsive From: Chris Jaquet chrisjaq...@gmail.com Date: Mon, 14 Nov 2011 21:53:20 +0200 To: osg-users@lists.openscenegraph.org Hi, The OpenSceneGraph logo loads, but the redirection to the wiki, and the wiki link itself (www.openscenegraph.org/projecst/osg http://www.openscenegraph.org/projecst/osg), does not work (from South Africa). Cheers, Chris On Mon, Nov 14, 2011 at 9:42 PM, Scott Wasinger swasin...@comcast.net mailto:swasin...@comcast.net wrote: Still Not able to connect to the osg homepage. I don't know if this is related but I'm located in Colorado like Chris 'Xenon' Hanson. Is anybody else having this problem? Here is the screen capture from my web browser: http://forum.openscenegraph.org/files/screenshot_mozilla_106.png -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43868#43868 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0-rc3 tagged, and plan to final 3.0.0 release
Hi Robert, A rebuild today was quick to flag that JPEG and TIFF components were missing. This was quickly fixed by installing the development tools for both. (This system was Windows-XP until recently designated to take over for my departed linux box.) This solved the problem with osglogo and other examples that couldn't read JPEGs. The source of the osgviewerQt problem is that I don't yet have the standard .osgt files on my system. I hadn't noticed that OpenSceneGraph-Data had changed since the 2.8.0 version. Otherwise, our project has been using osg-2.9.8. -Don Leich Robert Osfield wrote: Hi Don, On Wed, Jun 22, 2011 at 10:59 PM, Don Leich d...@ilight.com wrote: I gave 3.0.0-rc3 a check out here and found a few problems. These are quite possibly due to the atypical setup here, particularly the farily old version of Qt installed and possibly other factors. system:x86_64 SuSE 11.01 graphics: NVIDIA Quadro FX 1800 270.41.19 gcc: 4.3.1 Qt: 3.3.3 The example osgviewerQt comes up with solid blue background in all viewports and not other graphics. I'm unable to run the other Qt examples since we don't compile for QT_QTWEBKIT_LIBRARY. We've got Qt-4.4.3 so this could be a version mismatch. I'm afraid I'm not Qt expert so have to rely upon members of the community for improving the osgQt lib, however, even with those of the community who have greater Qt skills I suspect most will be using more modern Qt versions so might not be able to help debug your situation directly. On the possibility of a Qt version mis-match, the thing to look at is what Cmake has picked up. Running ccmake . in the OpenSceneGraph/ directory and see what QT_ libs and headers it's picked up. You'll need to press 't' in ccmake to toggle on the advanced options so you can see all the QT_ variables. A number of other examples failed due a missing jpeg plugin. I don't know why this is a problem and haven't invesitgated it yet. Otherwise, the build seemed to go without a hickup and other then the problems mentioned the examples were working. Could you check to see if the jpeg plugin didn't compile? Could you check what version of jpeg worked? Also have you been using a previous version of the OSG without these problems? If so which version? On a very positive note 3.0.0-rc3 did quite well in the 20 year old legacy application we've recently ported to osg. Now that's the news I like :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0-rc3 tagged, and plan to final 3.0.0 release
Hi all, I gave 3.0.0-rc3 a check out here and found a few problems. These are quite possibly due to the atypical setup here, particularly the farily old version of Qt installed and possibly other factors. system:x86_64 SuSE 11.01 graphics: NVIDIA Quadro FX 1800 270.41.19 gcc: 4.3.1 Qt: 3.3.3 The example osgviewerQt comes up with solid blue background in all viewports and not other graphics. I'm unable to run the other Qt examples since we don't compile for QT_QTWEBKIT_LIBRARY. We've got Qt-4.4.3 so this could be a version mismatch. A number of other examples failed due a missing jpeg plugin. I don't know why this is a problem and haven't invesitgated it yet. Otherwise, the build seemed to go without a hickup and other then the problems mentioned the examples were working. On a very positive note 3.0.0-rc3 did quite well in the 20 year old legacy application we've recently ported to osg. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crashing when calling viewer-done()
Hello Robert,
I may be a couple of days late, but I have a suggestion to solve your
crashing problem. Instead of s dynamically allocated viewer use a
static object.
osgViewer::Viewer viewer;
...
//don't want this: viewer = new osgViewer::Viewer();
...
viewer.realize();
int iter = 0;
while( !viewer.done() )
{
coutiter: iterendl;
iter++;
viewer.frame();
}
return 0;
}
-Don Leich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] memory leak resizing osgoit
Hi all,
The osgoit example program exhibits a large memory leak when the
window is continually resized causing the depth peel cameras
to be recreated over and over. This leak is made much worse
when the program is modified for multi-sampled antialiasing...
// camera-attach(osg::Camera::COLOR_BUFFER, colorTexture.get());
camera-attach(osg::Camera::COLOR_BUFFER, colorTexture.get(),
0, 0, false, 4, 4);
I suspect that each time it sets up the cameras a new FBO is allocated
without releasing previously used FBO resources as described in
the threads FBO resizing problem and [osgPPU] Problems with resizing.
How would one go about managing FBOs without leaking memory in the context
of osgoit? A callback on resize such as the one below was suggested in
one (actually both) of the threads mentioned. If this is appropriate,
where does it fit in?
class detachFBOCallback : public osg::NodeCallback {
public:
detachFBOCallback( ) {}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osg::Camera* fboCam = dynamic_castosg::Camera*( node );
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*( nv );
if ( fboCam cv )
{
// Cause the FBO to be recreated.
cv-getCurrentRenderBin()-getStage()-setFrameBufferObject(NULL);
// Ensure that runCameraSetUp is called.
cv-getCurrentRenderBin()-getStage()-setCameraRequiresSetUp(true);
}
traverse( node, nv );
}
};
-Don Leich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] background visible on point sprite spheres
Hi all, I've got a problem that I haven't been able to find a solution for and could use some help. I'm using the standard texture file OpenSceneGraph-Data/Images/sphere.gif as the source image for point sprites. The file is an image of a shaded sphere against a fully transparent background. I can set a state to properly render small 2-D sphere images with GL_POINTS primitive type. I needed to add sprites to my scene graph after some other content that requires setting a different state first. The point sprites after this other content will show the shaded sphere image correctly, but will now also render the sphere image background even though it should be fully transparent. Adding osg::StateAttribute::OVERRIDE to the blend function state was a thought, but no help. fn-setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::ONE_MINUS_SRC_ALPHA); _state-setAttributeAndModes(fn, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON); A dump and compare of .osg files didn't yield any insight. Does anyone have a suggestion for a possible fix here or maybe a way to debug the state with OSG internals? What besides BlendFunc should be in influence here? Does it sound like I'm just not applying the state where I think I am? Thanks, -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] background visible on point sprite spheres
Thanks Yurii, I did have that, also with OVERRIDE | ON. _state-setMode( GL_BLEND, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON ); _state-setRenderBinDetails(10, DepthSortedBin, osg::StateSet::OVERRIDE_RENDERBIN_DETAILS ); Still stumped, but distracted by other things today. -Don Yurii Monakov wrote: Hi Don! I think that you can try enabling GL_BLEND mode in your StateSet (if it is not already enabled). Best regards, Yurii Monakov 2010/12/16 Don Leich d...@ilight.com: Hi all, I've got a problem that I haven't been able to find a solution for and could use some help. I'm using the standard texture file OpenSceneGraph-Data/Images/sphere.gif as the source image for point sprites. The file is an image of a shaded sphere against a fully transparent background. I can set a state to properly render small 2-D sphere images with GL_POINTS primitive type. I needed to add sprites to my scene graph after some other content that requires setting a different state first. The point sprites after this other content will show the shaded sphere image correctly, but will now also render the sphere image background even though it should be fully transparent. Adding osg::StateAttribute::OVERRIDE to the blend function state was a thought, but no help. fn-setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::ONE_MINUS_SRC_ALPHA); _state-setAttributeAndModes(fn, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON); A dump and compare of .osg files didn't yield any insight. Does anyone have a suggestion for a possible fix here or maybe a way to debug the state with OSG internals? What besides BlendFunc should be in influence here? Does it sound like I'm just not applying the state where I think I am? Thanks, -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] lighting for point sprites
Hi all, I've been using point sprites with a small 2-d texture map of a sphere for some time now with great results. I'd like to be able to vary the lighting on my spheres and was hoping that I'd be able to replace the picture of the sphere with a flat disc and use a bump map to affect lighting. Is this a direction worth persuing? It looks like the internals of the BumpMapping class in osgFX are doing some BIND_PER_VERTEX assignments. Will everything bind to the single vertex of the point sprite? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert,
I am now able to set an overall color for otherwise uncolored
geometries with your suggested fix. I still don't understand why this
is correct. I thought that the setStateSet would set a current color
from it's material which is now OSG seemed to behave until 2.9.3.
osg::Group *primary = gg.getPrimarySurface();
// This used to specify an overall color for otherwise uncolored geometries.
primary-setStateSet( _state.get() );
// Now required to set the overall color directly in the Geode.
// Uses the material associated with the state.
osg::Geode *gg = dynamic_castosg::Geode*(primary-getChild(0));
if ( gg )
_applyColor( gg, _material-getDiffuse(osg::Material::FRONT_AND_BACK));
...
void Material::_applyColor( osg::Geode *gg, osg::Vec4 color )
{
osg::ref_ptrosg::Geode geode = gg;
osg::ref_ptrosg::Vec4Array colors = new osg::Vec4Array( 1 );
(*colors)[ 0 ] = color;
for ( unsigned int ii=0; iigeode-getNumDrawables(); ii++ )
{
osg::Geometry *geom = dynamic_castosg::Geometry*(geode-getDrawable(
ii ));
geom-setColorArray( colors.get() );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
}
}
-Don
Robert Osfield wrote:
Hi Don,
On Tue, Sep 21, 2010 at 12:13 AM, Don Leich d...@ilight.com wrote:
I confirmed that the bug persists in today's SVN trunk. In the example
already supplied the overall color is not applied when normals are
given as BIND_PER_PRIMITIVE.
I've just tested svn/trunk and 2.9.3 and can confirm that there is
different behaviour.
I've also isolated the two geometries that use BIND_PER_PRIMITIVE and
they just use this binding for normals, but have no colour array
assigned at all. So... they will be inheriting their colour from
other geometries in a completely undefined way.
This to me doesn't look like a bug at all, but an issue with a
under-defined scene graph, and just by luck it's worked before.
Please assign colours to all the geometries that need it and then
re-test.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] file name case changes
Hi all, Now that I'm back after a short vacation I fully intend to see if the BIND_PER_PRIMITIVE bug is in the SVN trunk. As a sporatic user of SVN I find that each time I try to use it is a challenge. I've now come across something odd that may well be a quirk of TortoiseSVN or might be an indication on something funky with the SVN code base. I found that I had to change the case of several OSG files before I could build. The first indication was this error generating the cmake configuration... CMake Error in src/osg/CMakeLists.txt: Cannot find source file GL. Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx After some trial and error I found that I could build if I changed these files and the directory x11 to upper-case: src/include/gl src/include/glu src/include/lod src/osg/lod.cpp src/include/osgViewer/api/x11 src/osgPlugins/ive/lod.cpp src/osgPlugins/ive/lod.h src/osgPlugins/bsp/bitset.cpp src/osgPlugins/bsp/bitset.h -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
I confirmed that the bug persists in today's SVN trunk. In the example already supplied the overall color is not applied when normals are given as BIND_PER_PRIMITIVE. -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi J-S, I'm using TortoiseSVN on a Windows system. This has a right-click menu entry for SVN Checkout. The GUI can only handle the URL and was confused by the spaceOpenSceneGraph after trunk. You're exactly right that I was pulling down and eternity and a half. Today, after contemplating installing svn on a SuSE linux system, I got what I wanted with http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk which I swear I tried Friday. Thanks for keeping an eye out. -Don Jean-Sébastien Guay wrote: Hi Don, I bailed on my svn import. TortoiseSVN wouldn't work with the checkout command as documented. I got the checkout going, but I seemed to be getting way more than I wanted. After more time than I had to spend I still didn't have the OSG source. What command did you try? This page gives you the command you should have been using: http://www.openscenegraph.org/projects/osg/wiki/Downloads/SVN which is: svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph That gets you only the trunk source tree, i.e. what you need. It should be a pretty speedy checkout, at least it is whenever I do it on a new machine (which I've done a few times in the past month or two). I would understand it taking a lot of time if you had removed one or especially two levels from the path, i.e. if you did svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/ That would checkout all the branches, tags and trunk, i.e. it would take an eternity and a half, in addition to taking more disk space than you probably have... SVN branches and tags are shallow copies unless something changes, so they're lightweight on the server, but as soon as you download them on your machine they take the full size of all files. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert,
I bailed on my svn import. TortoiseSVN wouldn't work with the checkout
command as documented. I got the checkout going, but I seemed to be getting way
more than I wanted. After more time than I had to spend I still didn't
have the OSG source.
I did manage to produce a test file. There are two small meshes, one colored
overall magenta, the other cyan. Both are 50% transparent. This is
what I see in a 2.8.3 viewer. The magenta mesh BIND_PER_VERTEX normals.
The cyan has BIND_PER_PRIMITIVE. With a 2.9.8 viewer the semi-tranparent
magenta mesh shows as opaque gray.
-Don Leich
MatrixTransform {
UniqueID MatrixTransform_0
name il::Scene
nodeMask 0x
cullingActive TRUE
UpdateCallbacks {
NodeCallback {
}
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Group {
UniqueID Group_1
name scene
nodeMask 0x
cullingActive TRUE
num_children 4
MatrixTransform {
UniqueID MatrixTransform_2
name il::LightManager
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
name il::Light
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
LightSource {
UniqueID LightSource_4
nodeMask 0x
cullingActive FALSE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
}
referenceFrame RELATIVE
Light {
UniqueID Light_5
DataVariance DYNAMIC
light_num 0
ambient 0.15 0.15 0.15 1
diffuse 0.7 0.7 0.7 1
specular 1 1 1 1
position -0.57735 -0.57735 -0.57735 0
direction 0.57735 0.57735 0.57735
constant_attenuation 1
linear_attenuation 0
quadratic_attenuation 0
spot_exponent 0
spot_cutoff 180
}
}
}
MatrixTransform {
UniqueID MatrixTransform_6
name il::Light
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
LightSource {
UniqueID LightSource_7
nodeMask 0x
cullingActive FALSE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
}
referenceFrame RELATIVE
Light {
UniqueID Light_8
DataVariance DYNAMIC
light_num 1
ambient 0.15 0.15 0.15 1
diffuse 0.7 0.7 0.7 1
specular 1 1 1 1
position 0.57735 0.57735 0.57735 0
direction -0.57735 -0.57735 -0.57735
constant_attenuation 1
linear_attenuation 0
quadratic_attenuation 0
spot_exponent 0
spot_cutoff 180
}
}
}
}
MatrixTransform {
UniqueID MatrixTransform_9
name scene world transform
nodeMask 0x
cullingActive TRUE
StateSet {
UniqueID StateSet_10
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_LIGHT0 ON
GL_LIGHT1 ON
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
MatrixTransform {
UniqueID MatrixTransform_11
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 8
MatrixTransform {
name id:-216
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
}
MatrixTransform {
name id:-206
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
[osg-users] BIND_PER_PRIMITIVE broken?
I know it's slow, but we'd been using BIND_PER_PRIMITIVE mainly for backward compatibility for faceted shading and coloring occasionally. After our recent upgrade from osg-2.8.3 to 2.9.8 everything rendered with BIND_PER_PRIMITIVE is wrong -- bad colors or material properties ignored. Is this change known? Is there any magic that may make it behave? Am I going to have to bit the bullet and duplicate vertices to match the normal per facet I've got? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and QT example
The best overview comes from examples/osgQtWidgets/osgQtWidgets.cpp... //We would need to document the following somewhere in order to guide people on //what they need to use... // //-- //There are two angles to consider. // //1. If someone wants a widget in their Qt app to be an OSG-rendered scene, they //need GraphicsWindowQt (in the osgViewerQtContext example) or QOSGWidget (in the //osgViewerQt example). These two allow both OSG and Qt to manage their threads //in a way which is optimal to them. We've used QOSGWidget in the past and had //trouble when Qt tried to overlay other widgets over the QOSGWidget (since OSG //did its rendering independently of Qt, it would overwrite what Qt had drawn). I //haven't tried GraphicsWindowQt yet, but I expect since it uses QGLWidget, it //will result in Qt knowing when OSG has drawn and be able to do overlays at the //right time. Eventually GraphicsWindowQt can be brought into osgViewer I imagine... // //2. If someone wants to bring Qt widgets inside their OSG scene (to do HUDs or //an interface on a computer screen which is inside the 3D scene, or even //floating Qt widgets, for example). That's where QGraphicsViewAdapter + //QWidgetImage will be useful. //-- I've used both QOSGWidget and GraphicsWindowQt in full blown Qt applications. In both cases I made classes that inherited one of the above along with osgViewer::View. QOSGWidget works pretty well as is. I had to break the GraphicsWindowQt constructor into parts to use a QWidget created elsewhere in the Qt application. -Don Leich Hi, is there meanwhile a sort of standard way of integration osg views as qt widgets in a way that allows to handle them like normal widgets on the qt side ? Thank you! Cheers, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] screen grabs with overlapping windows
Hi all, I've got a Qt GUI with multiple graphics windows doing OSG rendering. When doing screen grabs there is a problem where windows that overlap the graphics will corrupt the rendered pixels. What would be a resonable way to avoid the problem and reliably grab uncorrupted pixels? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi-sample buffer ignored?
I've been watching the osgQt developments with interest here. I'm involved in porting a large application to OSG Qt and I've been concerned for some time now with the platform dependencies and other messiness of the osgviewerQtWidget based code we'd been using. The osgQt code seemed too different (we followed a QWidgetrather than QObject implementation) and it not quite ready for prime time for production code. We're not using Qt for any graphic rendering, just the window management frame for several windows of OSG graphics so mixing Qt OSG rendering wasn't a concern. I found that it was fairly straight to substitute the osgviewerQtContext based code. The API is more complete, the multi-sample problem request takes, and the X11/Win32/Mac porting issues are moot (love that word). I think osgviewerQtContext is the clear winner over osgviewerQtWidget. Jeremy -- great news on your recovery! -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multi-sample buffer ignored?
Hi all, I've been wondering why my settings for multi-sampled anti-aliasing were being ignored since porting my GUI code to Qt. I've since discovered the same behavior in the osgviewerQT example. Since this program does not accept the --samples argument I altered QOSGWidget::createContext to explicitly set: ds-setNumMultiSamples( 4 ); Where we choose a visual in osgViewer::GraphicsWindowX11 I've confirmed that the visual number in the visual info indicates 4 samples... visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x30 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon However, there are jaggies all over the place -- no appearant anti-aliasing. Does anyone have an idea why this is so? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't pick HUD geometry under perspective projection
Now that my problem is resolved, I thought about why I was having so much trouble finding the resolution. It occured to me early on that my near/far settings might be involved early on and appearently my attempt to override what I was setting was ineffective. The problem was ultimately something along the lines of what Frank suggested, only simpler. The HUD geometries are rendered with depth OFF, so they're visible despite the near/far settings of the projection matrix. However, when picking the near/far settings would cause the HUD geometries to be culled and would never register a pick hit. There seems to be no reason not to keep near/far wide open (-1., 1.) in the HUD camera projection. -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't pick HUD geometry under perspective projection
hi all, I found a fix for my problem. After making only very slow progress trying to debug actions mainly taking place in inline functions, I found that I merely needed to open up the near and far distances in setProjectionMatrixAsOrtho for my HUD camera. If anyone has advice on debugging inline functions, I'm all ears. Thanks to those who offered up possible solutions for this problem. -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't pick HUD geometry under perspective projection
Thanks Frank. I don't think I'm having the same problem. I fail to
get an interestion hit of my HUD geometry when it's over the background.
I don't get 3-D geometry instead. I get nothing.
I'm not sure if J-S's idea that something in changing between the
perspective and orthogonal cameras is the problem either. I saw no
improvement running accept on the HUD camera first. It seems we wouldn't
be changing in that case.
It looks like I need some quality debugging time.
-Don
Frank Miller wrote:
I had a problem in my application some time ago that sounds similar. I
have worked around the issue in a way not unlike Jean-Sébastien Guay.
If I remember correctly, the problem I was experiencing was due to the
fact that the intersections are sorted by depth without regard to
viewports. So even though the HUD geometry is rendered ontop of the
perspective geometry it could have a larger depth and thus ends up
further down the list. You can easily check if this is your issue by
printing all of the intersections.
Frank
On Wed, 2010-06-30 at 19:17 -0400, Don Leich wrote:
Hi J-S,
Thanks for your suggestion, but your workaround didn't work for me.
I've been running OSG 2.8.3 and also tried 2.9.7 with no improvement.
In my code _s_scene-getHUDCamera() returns the post render camera for
my HUD geometry. I also have a pre render camera used for a background
image that I skip with a NodeMask. If I disable the NodeMask the only
node I intersect with the perspective camera is my background image quad.
Could this be a clue, or is it just a side issue?
-Don
class Picking : public osg::Referenced
{
public:
Picking() {}
~Picking() {}
// Pick at the given mouse coordinates
void pick( int mx, int my,
osgViewer::View* view, osg::Node *skipNode,
int id, int seed, float3 lcs, float3 wcs )
{
id = -1;
seed = -1;
lcs[0] = lcs[1] = lcs[2] = 0.;
wcs[0] = wcs[1] = wcs[2] = 0.;
osg::Drawable* drawable = 0;
osg::Node* node = 0;
osg::Group* parent = 0;
osg::Viewport* viewport = view-getCamera()-getViewport();
// Save and replace the node mask for a node to skip here,
// typically the background image quad.
osg::Node::NodeMask origNodeMask = skipNode-getNodeMask();
skipNode-setNodeMask( 0x );
bool gotPick = false;
// Use PolytopeIntersector exclusively. Works on all primitive types.
if ( viewport != NULL )
{
osgUtil::PolytopeIntersector* picker;
{
// use window coordinates
double fx = viewport-x() + mx;
double fy = viewport-y() + (viewport-height()-1) - my; //
invert Y
double ap = 2.; // pick frustum aperture radius
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::WINDOW, fx-ap, fy-ap, fx+ap,
fy+ap );
}
osgUtil::IntersectionVisitor iv(picker);
view-getCamera()-accept(iv);
//
// If we fail to find any intersections with the main camera, run the
// accept on the HUD camera. This didn't help. With a perspective main
// camera we never see the HUD geometry.
//
if (! picker-containsIntersections())
_s_scene-getHUDCamera()-accept(iv);
if (picker-containsIntersections())
{
osgUtil::PolytopeIntersector::Intersection intersection =
picker-getFirstIntersection();
// Removed application stuff here.
// Local coordinate system point (really the average of all
hits).
osg::Vec3 lip;
lip[0] = intersection.localIntersectionPoint[0];
lip[1] = intersection.localIntersectionPoint[1];
lip[2] = intersection.localIntersectionPoint[2];
lcs[0] = lip[0];
lcs[1] = lip[1];
lcs[2] = lip[2];
// Transform local coordinate system point into world
coordinate system point.
osg::Vec3 wip = lip * (*intersection.matrix.get());
wcs[0] = wip[0];
wcs[1] = wip[1];
wcs[2] = wip[2];
drawable = intersection.drawable;
gotPick = true;
}
}
// Removed application stuff here.
skipNode-setNodeMask( origNodeMask ); // restore
}
// Removed application stuff here.
};
Jean-Sébastien Guay wrote:
Hi Don,
I'm having a problem with not being able to pick on my HUD geometry when
the main camera has a perspective projection. My app is able to toggle
between
perspective and orthographic. Picking on the HUD geometry works fine
Re: [osg-users] Can't pick HUD geometry under perspective projection
Hey guys, I managed to squeeze in a little debugging on this problem. Here's what I've got so far. I've pared down my scene to a small set 3-D lines and a single annotation arrow in my HUD camera. If I pick on the arrow when the main camera is orthogonal I can see than inside PolytopeIntersector::enter _polytope.contains() evaluates to either true or false depending on where we are in the scene graph. If I pick on the arrow when the main camera is perspective _polytope.contains() will always evaluate false. Whatever this means will have to wait over the long weekend. Thanks for the help, and have a good one yourselves. -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can't pick HUD geometry under perspective projection
hi all, I'm having a problem with not being able to pick on my HUD geometry when the main camera has a perspective projection. My app is able to toggle between perspective and orthographic. Picking on the HUD geometry works fine with orthographic, and the HUDs are visible in both projections. I am setting near far for the perspective projection, an obvious difference from orthographic. I tried altering the camera to set setComputeNearFarMode( osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR) just prior to picking with no change. The same problem occurs with osgUtil::LineSegmentIntersector and osgUtil::PolytopeIntersector. Does anyone have an idea what's going on here? The archives were very helpful. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't pick HUD geometry under perspective projection
I meant to say the archives *weren't* very helpful. -Don Don Leich wrote: hi all, I'm having a problem with not being able to pick on my HUD geometry when the main camera has a perspective projection. My app is able to toggle between perspective and orthographic. Picking on the HUD geometry works fine with orthographic, and the HUDs are visible in both projections. I am setting near far for the perspective projection, an obvious difference from orthographic. I tried altering the camera to set setComputeNearFarMode( osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR) just prior to picking with no change. The same problem occurs with osgUtil::LineSegmentIntersector and osgUtil::PolytopeIntersector. Does anyone have an idea what's going on here? The archives were very helpful. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't pick HUD geometry under perspective projection
Hi J-S,
Thanks for your suggestion, but your workaround didn't work for me.
I've been running OSG 2.8.3 and also tried 2.9.7 with no improvement.
In my code _s_scene-getHUDCamera() returns the post render camera for
my HUD geometry. I also have a pre render camera used for a background
image that I skip with a NodeMask. If I disable the NodeMask the only
node I intersect with the perspective camera is my background image quad.
Could this be a clue, or is it just a side issue?
-Don
class Picking : public osg::Referenced
{
public:
Picking() {}
~Picking() {}
// Pick at the given mouse coordinates
void pick( int mx, int my,
osgViewer::View* view, osg::Node *skipNode,
int id, int seed, float3 lcs, float3 wcs )
{
id = -1;
seed = -1;
lcs[0] = lcs[1] = lcs[2] = 0.;
wcs[0] = wcs[1] = wcs[2] = 0.;
osg::Drawable* drawable = 0;
osg::Node* node = 0;
osg::Group* parent = 0;
osg::Viewport* viewport = view-getCamera()-getViewport();
// Save and replace the node mask for a node to skip here,
// typically the background image quad.
osg::Node::NodeMask origNodeMask = skipNode-getNodeMask();
skipNode-setNodeMask( 0x );
bool gotPick = false;
// Use PolytopeIntersector exclusively. Works on all primitive types.
if ( viewport != NULL )
{
osgUtil::PolytopeIntersector* picker;
{
// use window coordinates
double fx = viewport-x() + mx;
double fy = viewport-y() + (viewport-height()-1) - my; //
invert Y
double ap = 2.; // pick frustum aperture radius
picker = new osgUtil::PolytopeIntersector(
osgUtil::Intersector::WINDOW, fx-ap, fy-ap, fx+ap,
fy+ap );
}
osgUtil::IntersectionVisitor iv(picker);
view-getCamera()-accept(iv);
//
// If we fail to find any intersections with the main camera, run the
// accept on the HUD camera. This didn't help. With a perspective main
// camera we never see the HUD geometry.
//
if (! picker-containsIntersections())
_s_scene-getHUDCamera()-accept(iv);
if (picker-containsIntersections())
{
osgUtil::PolytopeIntersector::Intersection intersection =
picker-getFirstIntersection();
// Removed application stuff here.
// Local coordinate system point (really the average of all
hits).
osg::Vec3 lip;
lip[0] = intersection.localIntersectionPoint[0];
lip[1] = intersection.localIntersectionPoint[1];
lip[2] = intersection.localIntersectionPoint[2];
lcs[0] = lip[0];
lcs[1] = lip[1];
lcs[2] = lip[2];
// Transform local coordinate system point into world
coordinate system point.
osg::Vec3 wip = lip * (*intersection.matrix.get());
wcs[0] = wip[0];
wcs[1] = wip[1];
wcs[2] = wip[2];
drawable = intersection.drawable;
gotPick = true;
}
}
// Removed application stuff here.
skipNode-setNodeMask( origNodeMask ); // restore
}
// Removed application stuff here.
};
Jean-Sébastien Guay wrote:
Hi Don,
I'm having a problem with not being able to pick on my HUD geometry when
the main camera has a perspective projection. My app is able to toggle
between
perspective and orthographic. Picking on the HUD geometry works fine with
orthographic, and the HUDs are visible in both projections.
This sounds a bit like the reason why in the example I sent a little
while ago to test out the changed I had made to QWidgetImage, I had to
customize the computeIntersections() method when my widget was under an
ortho projection (i.e. displayed fullscreen). Unfortunately I didn't get
to look into why that was, I just worked around it.
The workaround I used was to give the IntersectionVisitor directly to
the ortho camera instead of starting it from the root (the viewer's main
camera, which is the perspective one).
If I had to venture a guess I'd say it looks like some values are
lingering around from the perspective projection once the
IntersectionVisitor gets to the ortho camera, almost as if it hadn't
seen that the ortho camera is in referenceFrame ABSOLUTE_RF (which means
it should start over fresh, not multiply by the previous matrix). But as
I said, I haven't dug any deeper, so that's just a hunch.
Hope this helps in some small way,
J-S
___
osg-users
Re: [osg-users] Trying to render an ortogonal scene (J.P. Delport)
This variation on the osgthirdpersonview example may help in sorting
out the issues with an orthogonal projection. Run as shown to get the
new behavior:
osgthirdpersonview --isOrthog
-Don
/* OpenSceneGraph example, osgthirdpersonview.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
// This code is originally Copyright (c) 2008 Skew Matrix Software LLC,
// but you may use the code under the terms of the OSGPL as described above.
// This example demonstrates how CompositeViewer can be used to
// provide a third person view of another view, including eyepoint and
// view frustum.
//
// The code creates a CompositeViewer with two Views. Each of the two
// Views has its own window. One View is the typical scene view,
// showing the loaded model(s).
//
// The second View is a third person view showing not just the loaded
// model(s), but also a wireframe representation of the first View's
// frustum. Interactions with the first View are reflect5ed in the
// second View's displayed frustum.
//
// Command line arguments are taken to be models for display. If you
// specify no command line arguments, the code attempts to load cow.osg.
#include osg/Geometry
#include osg/DisplaySettings
#include osg/MatrixTransform
#include osg/LineWidth
#include osgDB/ReadFile
#include osgViewer/CompositeViewer
#include osgGA/TrackballManipulator
const double _fov = 30.;
const double _aspectRatio = 640. / 480.;
const double _oHeight = 1./_aspectRatio;
const double _near = 1.;
const double _far = 10.;
const double _scl = 4.;
// Given a Camera, create a wireframe representation of its
// view frustum. Create a default representation if camera==NULL.
osg::Node*
makeFrustumFromCamera( osg::Camera* camera, bool isPerspective )
{
// Projection and ModelView matrices
osg::Matrixd proj;
osg::Matrixd mv;
if (camera)
{
proj = camera-getProjectionMatrix();
mv = camera-getViewMatrix();
}
else
{
// Create some kind of reasonable default Projection matrix.
if (isPerspective)
proj.makePerspective( _fov, _aspectRatio, _near, _far );
else
proj.makeOrtho( _scl*-1., _scl*1., _scl*-_oHeight, _scl*_oHeight,
_near, _far );
// leave mv as identity
}
// Get near and far from the Projection matrix.
double near = proj(3,2) / (proj(2,2)-1.0);
double far = proj(3,2) / (1.0+proj(2,2));
// Get the sides of the near plane.
double nLeft = near * (proj(2,0)-1.0) / proj(0,0);
double nRight = near * (1.0+proj(2,0)) / proj(0,0);
double nTop = near * (1.0+proj(2,1)) / proj(1,1);
double nBottom = near * (proj(2,1)-1.0) / proj(1,1);
// Get the sides of the far plane.
double fLeft = far * (proj(2,0)-1.0) / proj(0,0);
double fRight = far * (1.0+proj(2,0)) / proj(0,0);
double fTop = far * (1.0+proj(2,1)) / proj(1,1);
double fBottom = far * (proj(2,1)-1.0) / proj(1,1);
// Clobber if orthographic
if (! isPerspective)
{
proj.getOrtho(nLeft, nRight, nBottom, nTop, near, far);
proj.getOrtho(fLeft, fRight, fBottom, fTop, near, far);
}
// Our vertex array needs only 9 vertices: The origin, and the
// eight corners of the near and far planes.
osg::Vec3Array* v = new osg::Vec3Array;
v-resize( 9 );
(*v)[0].set( 0., 0., 0. );
(*v)[1].set( nLeft, nBottom, -near );
(*v)[2].set( nRight, nBottom, -near );
(*v)[3].set( nRight, nTop, -near );
(*v)[4].set( nLeft, nTop, -near );
(*v)[5].set( fLeft, fBottom, -far );
(*v)[6].set( fRight, fBottom, -far );
(*v)[7].set( fRight, fTop, -far );
(*v)[8].set( fLeft, fTop, -far );
osg::Geometry* geom = new osg::Geometry;
geom-setUseDisplayList( false );
geom-setVertexArray( v );
osg::Vec4Array* c = new osg::Vec4Array;
c-push_back( osg::Vec4( 1., 1., 1., 1. ) );
geom-setColorArray( c );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
GLushort idxLines[8] = {
0, 5, 0, 6, 0, 7, 0, 8 };
GLushort idxLinesOrtho[8] = {
1, 5, 2, 6, 3, 7, 4, 8 };
GLushort
[osg-users] HUD camera and depth
Hi all,
I needed to change an HUD camera so that it would write into the depth
buffer. To get it to work I had to do something that I don't understand.
I thought that a depth range of (0.,0.) and function of ALWAYS should cause
all subsequent rendering to write at the minimum depth value. Doing so
would render lines OK but all filled polys and text went missing. I found
that I had to open up the range a bit in order to see these too.
Does anyone have an idea why I needed to cheat the range here?
-Don
void Scene::createHUDCamera()
{
_hud = new osg::Camera;
_hud-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
_hud-setClearMask( 0 );
_hud-setRenderOrder(osg::Camera::POST_RENDER);
_hud-getOrCreateStateSet()-setMode( GL_BLEND, osg::StateAttribute::ON );
_hud-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF
);
// Instead of turing off hidden surface (depth test) use a depth func
// to push the hud children in front of everything else.
osg::Depth* depth = new osg::Depth;
depth-setFunction( osg::Depth::ALWAYS );
// setRange(.0, .0) should write all pixels at the minimum depth value.
// depth-setRange( .0, .0 ); //### Loses all filled polys and text...
depth-setRange( .0, .0001 ); // ...unless I do this. ###
_hud-getOrCreateStateSet()-setAttributeAndModes( depth,
osg::StateAttribute::ON );
_hud-setAllowEventFocus(false);
_hudMembers = new osg::Group;
_hud-addChild( _hudMembers.get() );
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgposter and HUD cameras
Hello Wang Rui, Thank you for this information. I do have the newer version, but started working with the older one since it did basically what I needed it to do and it was quite a bit simpler. I see how you've uncoupled from the GUIEventHandler. -Don Wang Rui wrote: Hi Don, Sorry for the delay. I'm just back from vacation. It seems that you are using the origin version of osgposter. I've submitted a newer one which could manage the PosterPrinter object with GUIEventhandler or your own handlers in a much simpler way. It has not been merged into the SVN but you could find it in the osg-submissions. Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgposter and HUD cameras
Hi all,
I'm hoping someone has a good suggestion of what direction to take this problem.
I've been working on integrating the guts of osgposter into an large existing
application. This application has a live graphics window. The osgposter
portion is intended to produce a high-resolution snap shot file on demand.
The GUIEventHandler model doesn't work so well in this application, so I managed
to recast the osgposter stages into a 2-pass DrawCallback - 1st pass for setup
and bindCameraToImage, 2nd pass for recordImages and osgDB::writeImageFile).
This is all working fine for the main scene graph. My problem has to do with
my HUD cameras. I have a pre-render camera to manage a background image and
2 post render cameras for axes markers and annotations.
I'm changing setRenderOrder for the HUD cameras to NESTED_RENDER to render
to get them to appear at all in the osgposter image. The remaining problem here
is that the HUD contents are always the size of a single tile. The image file
ends up looking like a sheet of stamps. Also, the size of the HUDs in the
live graphics window are inadvertently changed to the size of a single tile.
The HUD cameras need the offsetMatrix that is being applied to the poster
cameras. Is this something that I should expect a slave camera to do?
Is there some other way to communicate the offsetMatrix to the HUD cameras?
Thanks,
Don Leich
/* OpenSceneGraph example, osgposter.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
struct PosterDrawCB : public osg::Camera::DrawCallback
{
public:
typedef std::pairunsigned int, unsigned int TilePosition;
typedef std::map TilePosition, osg::ref_ptrosg::Image TileImages;
PosterDrawCB()
: _isRunning(false), _isFinished(false),
_outputPoster(true), _outputPosterName(poster.bmp),
_outputTiles(false), _outputTileExt(bmp),
_currentRow(0), _currentColumn(0),
_cameraIndex(0), _cameraRoot(0), _finalPoster(0),
_pass(0), _written(false)
{}
bool getWasWritten() { return _written; }
inline void setOutputPoster( bool b ) { _outputPoster= b; }
inline bool getOutputPoster() const { return _outputPoster; }
inline void setOutputPosterName( const std::string name ) {
_outputPosterName = name; }
inline const std::string getOutputPosterName() const { return
_outputPosterName; }
inline void setOutputTiles( bool b ) { _outputTiles = b; }
inline bool getOutputTiles() const { return _outputTiles; }
inline void setOutputTileExtension( const std::string ext ) {
_outputTileExt = ext; }
inline const std::string getOutputTileExtension() const { return
_outputTileExt; }
inline void setTileSize( int w, int h ) { _tileSize.set(w, h); }
inline const osg::Vec2 getTileSize() const { return _tileSize; }
inline void setPosterSize( int w, int h ) { _posterSize.set(w, h); }
inline const osg::Vec2 getPosterSize() const { return _posterSize; }
inline void setCameraRoot( osg::Group* root ) { _cameraRoot = root; }
inline const osg::Group* getCameraRoot() const { return _cameraRoot.get(); }
inline void setFinalPoster( osg::Image* image ) { _finalPoster = image; }
inline const osg::Image* getFinalPoster() const { return
_finalPoster.get(); }
virtual void operator () (osg::RenderInfo renderInfo) const
{
osg::Camera* camera = renderInfo.getCurrentCamera();
switch ( _pass++ )
{
case 0:
{
startPosterRecording( camera );
osg::Camera* subCamera = 0;
while ( (subCamera=getAvailableCamera())!=NULL )
{
std::cout Binding sub-camera _currentRow
_ _currentColumn
to image... std::endl;
bindCameraToImage( subCamera, _currentRow, _currentColumn );
if ( _currentColumn_tileColumns-1 )
_currentColumn++;
else
{
if ( _currentRow_tileRows-1
Re: [osg-users] osgDB::writeImageFile() jpg vs png
Hi Jim, I've been bit by this one. It seems that osgDB::writeImageFile does not correctly support images with pixelFormat = GL_RGBA for JPEG files. I think you'll find that changing to GL_RGB will get you a good file. -Don Leich Trying to save an osg::Image as a .jpg file malfunctions. Either false is returned or .jpg file has weird colors. But .png format works ok. osg::ref_ptrosg::Image image = mTextureObject-getImage(); //osgDB::writeImageFile( *image, file.jpg ); osgDB::writeImageFile( *image, file.png ); Tried OSG 2.8.1, 2.8.2, 2.9.6 on Linux, FreeBSD, and that thing from Redmond. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT and QOSGWidget issues
Hi Ant, This has come up before and there are a few changes that should fix this. I think it's possible that one or the other fix will solve your problem. It was inconclusive if one or the other works in all or just some cases, but it seems safe to do both fixes. 1) Override virtual function QPaintEngine to do nothing. 2) Remove the setting for Qt::WA_NoSystemBackground and replace with Qt::WA_OpaquePaintEvent and Qt::WA_PaintOnScreen. Also, look at this thread: http://forum.openscenegraph.org/viewtopic.php?p=21688#21688 -Don ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QOSGWidget display problem
I've run across the flickering problem before. There seems to be various side effects with certain Qt attributes, but I got better results changing setAttribute(Qt::WA_NoSystemBackground); to setAttribute(Qt::WA_OpaquePaintEvent); in QOSGWidget.cpp. You can follow the thread below or dig up the QOSGWidget demo with a 4-way split window I submitted for more help with Qt atttributes. // Date: Tue, 16 Jun 2009 10:07:16 + // From: Eric Pouliquen epouliq...@silicon-worlds.fr // Subject: Re: [osg-submissions] New QOSGWidget demo with a 4-way split // windowand bonus outboard window. // Suggested replacing the two setAttribute calls with this... //setAttribute(Qt::WA_OpaquePaintEvent); // This solverd a flickering problem on Windows // 8600 GT (185.85) and a Quadro FX1400 (182.65) // but causes a visible black border to be visible in the rendering // windows on Linux. This problem gone when WA_PaintOnScreen // is used in combination. // Hmmm... // According to Qt doc, WA_PaintOnScreen is X11 only and disables // double-buffering. I think this just means it disables a // buffer swap under Qt control. We want OSG to have full control. // // Equivalent to qt_x11_set_global_double_buffer(false)? // // Tried turning it off and got severe flashing on Linux. // Looks like without this we get an extraneous clear and // buffer swap form Qt. setAttribute(Qt::WA_PaintOnScreen); // This flags that something other than Qt is responsible for // all rendering in the window under the widget's control. setAttribute(Qt::WA_OpaquePaintEvent); // This seems superfluous now. // setAttribute(Qt::WA_NoSystemBackground); -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Building a Simple Viewer
Hi David, It looks like you did an out of source build, where your cmake, object, and other files are put in a directory seperate from the source code. Since the OpenThreads/Config file created by cmake it is written to the build directory. I've defined my include path for my development work to look first in a release tree, a debug tree, and lastly source tree, something like this: -I$OSG/build_release/include -I$OSG/build_debug/include -I$OSG/include -Don I now solved the problem turning off precompiled headers. Now I get this Error: C:\Praktikum\OpenSceneGraph\OSG\include\OpenThreads\Exports(17): fatal error C1083: Include-Datei kann nicht geöffnet werden: 'OpenThreads/Config': No such file or directory And there really isnt a Config File in Openthreads, is there supposed to be? And if yes what did I do wrong that it is not there? What I did find was: C:\Praktikum\OpenSceneGraph\OSG\build\include\OpenThreads\Config Is that the file it wants? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQtWidget example issues (UNCLASSIFIED)
Hi Lee, The sample code is a work in progress which I posted. It's based on the previous osgviewerQt example with an added Qt Designer generated interface description developed by a co-worked of mine, and miscellaneous patches and fixes I found in the OSG archives. The Bad Window errors are noted in a comment in the example code... We may have just gotten some Bad Window errors from X11 calling XGetWindowAttributes before the Window has been realized. We'll also have garbage in the traits which get fixed up next. I think these arise as a result of OSG trying to get the size of an X Window before it's been realized. These are nuisance errors that I'd like to see go away before my code goes production, but don't really affect the behavior of the example. I haven't seen the lock up on resize under Qt-4.4.3 and don't have a clue why this is a problem under Kde and not Gnome. I do see the frozen Outboard window. This is not buggy behavior but a deficiency in the example code, i.e. a logic error. -Don Subject: [osg-users] osgviewerQtWidget example issues (UNCLASSIFIED) From: Butler, Lee Mr CIV USA USAMC lee.but...@us.army.mil Date: Mon, 27 Jul 2009 16:52:54 -0400 To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Classification: UNCLASSIFIED Caveats: NONE The example code has problems on my machine (RedHat 5, Qt 4.5.2, NVidia 185.18.14, KDE). I've got svn revision 10512 from HEAD. The code compiles just fine (using qmake) but on startup I get: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 I can resize the outboard window without any problem, but attempting to resize the main window causes X11 to lock up. If I switch to gnome, it runs OK. Under either Gnome or KDE, selecting Main-Exit from the application causes the main window to close, but leaves a frozen Outboard window behind. The application does not quit until the outboard window is closed. Lee Classification: UNCLASSIFIED Caveats: NONE ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQtWidget example issues
Lee, Btw, the BadWindow errors are not new: % osgviewerQT cow.osg --QOSGWidget --MTCompositeViewer Using QOSGWidget - QWidget + osgViewer creating the graphics context. + using standard CompositeViewer with seperate contexts (Multithreaded mode / EXPERIMENTAL !) X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x58b X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x58b X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x58b X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x58f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x58f ... -Don Butler, Lee Mr CIV USA USAMC wrote: Thanks. I realize that this is not part of a release yet. Just wanted folks to know that it wasn't Produciton ready yet. Lee - Original Message - From: Don Leich d...@ilight.com Date: Tuesday, July 28, 2009 12:23 Subject: Re: [osg-users] osgviewerQtWidget example issues (UNCLASSIFIED) To: osg-users@lists.openscenegraph.org, Butler, Lee Mr CIV USA USAMC lee.but...@us.army.mil Hi Lee, The sample code is a work in progress which I posted. It's based on the previous osgviewerQt example with an added Qt Designer generated interfacedescription developed by a co-worked of mine, and miscellaneouspatches and fixes I found in the OSG archives. The Bad Window errors are noted in a comment in the example code... We may have just gotten some Bad Window errors from X11 calling XGetWindowAttributes before the Window has been realized. We'll also have garbage in the traits which get fixed up next. I think these arise as a result of OSG trying to get the size of an X Window before it's been realized. These are nuisance errors that I'd like to see go away before my code goes production, but don't really affect the behaviorof the example. I haven't seen the lock up on resize under Qt-4.4.3 and don't have a clue why this is a problem under Kde and not Gnome. I do see the frozen Outboard window. This is not buggy behavior but a deficiency in the example code, i.e. a logic error. -Don -- -- Subject: [osg-users] osgviewerQtWidget example issues (UNCLASSIFIED) From: Butler, Lee Mr CIV USA USAMC Date: Mon, 27 Jul 2009 16:52:54 -0400 To: 'OpenSceneGraph Users' Classification: UNCLASSIFIED Caveats: NONE The example code has problems on my machine (RedHat 5, Qt 4.5.2, NVidia 185.18.14, KDE). I've got svn revision 10512 from HEAD. The code compiles just fine (using qmake) but on startup I get: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200017 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200043 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200045 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x220004f X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 (X_GetWindowAttributes) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 (X_ChangeProperty) Resource id: 0x2200051 I can resize the outboard window without any problem, but attempting to resize the main window causes X11 to lock up. If I switch to gnome, it runs OK. Under either Gnome or KDE, selecting Main-Exit from the application causes the main window to close, but leaves a frozen Outboard window behind. The application does not quit until the outboard window is closed. Lee Classification: UNCLASSIFIED Caveats: NONE ___ osg-users mailing list osg-users
Re: [osg-users] Remote execution and OSG
Paul, I recently submitted some example code based on osgviewerQT that I think will solve your problem of setting the traits correctly in order to run to a remote display. It also addresses a number of issues having to do with Qt/OSG integration, including some unresolved issues. I hope a Qt expert or two can take a look as this is something we've been struggling with as well. -Don Leich -- next part -- A non-text attachment was scrubbed... Name: qosgwidget.tar.gz Type: application/gzip Size: 14851 bytes Desc: not available URL: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20090519/0f5e67ce/attachment-0001.bin -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development of Qt support as part of osgViewer
Hi all, I just posted some code to osg-submissions that may be of interest here. This is something that has been our Qt/OSG integration testbed here for a couple of months. We just dusted it off recently and got permission to post it and some time to clean it up. This demo uses Qt .ui files to define the basic GUI and re-works the object heirarchy from the osgviewerQT example so we can have a 4-way split window with a different scene graph in each of the 4 views, and an optional 5th view in it's own window. All is managed by a CompositeViewer. We've incorporated Martin Beckett's recent fix for WIN32 event queue handling. There are plenty of issues still to be dealt with, among which are the issues with tab-ing from view to view and which view is current in the Qt vs. OSG context. --Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT example
Thanks J-S, Updating the driver fixed the problem on two systems. I don't have access to the third system yet, but it's likely that a new driver will fix that one too. It's not always practical to install new software on other peoples systems. I own you at least 2 beers. I went to school close to Canada. Do they still make Old Vienna up there? -Don Jean-Sébastien Guay wrote: Hi Don, There's a significant new clue here. Two of my three systems that crash with osgviewerQT --QOSGWidget cow.osg are multi-processor systems. The third is a very fast single core Xenon. All they systems where there's no crash are single processor systems. Is anyone else able to run this demo on a multi-core system? I just ran osgviewerQT --QOSGWidget cow.osg on my Windows Vista SP1 machine here, which is a quad-core Intel Q6600 with 3GB RAM. Qt 4.4.3, NVidia driver 182.06, OSG from SVN (today). No crash here everything looks good. Of course none of your machines is Windows so that doesn't help you much. :-( Sounds to me like a driver problem. That'll usually be the case when the exact same program runs fine on a certain number of machines but not on others. Any chance you can try to revert to a previous driver or try a new one? If it feels to you like it could be related to multi-processor or multi-core, I know for a fact that NVidia corrected some bugs in the threading of their drivers lately, so perhaps a newer driver would get you those fixes. I know installing drivers manually is a hassle but at least it will give you an idea of whether that's the problem, until the given driver version filters down from the package repositories... Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT example
Hi all, There's a significant new clue here. Two of my three systems that crash with osgviewerQT --QOSGWidget cow.osg are multi-processor systems. The third is a very fast single core Xenon. All they systems where there's no crash are single processor systems. Is anyone else able to run this demo on a multi-core system? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT example
I looked into some odd behavior with an OSG/Qt based application at my place and traced this behavior back to an old favorite... osgviewerQT --QOSGWidget cow.osg This crashes on some systems, runs fine on others. This seems to be true for both OSG versions 2.8.1-rc2 and 2.9.2, Qt version 4.4.3 . We crash soon after we get a message: OpenGL version test failed, requires valid graphics context. Since there is no context glGetString returns NULL and we crash in osg::some class::Extensions::setupGLExtensions. Crashes on these systems: ghanima - SUSE LINUX 10.0 (X86-64) Quadro FX 4500 / PCI / SSE2 2.0.0 NVIDIA 76.67 bubba - Red Hat Enterprise Linux Client release 5 (Tikanga) X86-64 Quadro FX 4500 / PCI / SSE2 2.1.1 NVIDIA 100.14.19 cartman - Red Hat Enterprise Linux WS release 4 (Nahant) Quadro FX 3450/4000 SDI / PCI / SSE2 2.0.0 NVIDIA 76.76 There is no problem with the same test on these systems: dilbert - SUSE LINUX 10.1 (X86-64) Quadro FX 3400 / PCI / SSE2 2.1.2 NVIDIA 180.29 jeckle - SUSE LINUX Enterprise Server 9 (x86_64) Quadro FX 1100 / APG / SSE2 1.5.2 NVIDIA 66.29 curly - Red Hat Enterprise Linux WS release 4 (Nahant) FireGL V3100 1.3.5140 (X4.3.0-8.14.13) loki - Mac OS X 10.5.2 NVIDIA GeForce 7300 GT OpenGL Engine 2.0 NVIDIA-1.5.2 With OSG_WINDOWING_SYSTEM=Carbon. When OSG_WINDOWING_SYSTEM=X11 the programs launches two windows, one with rendering, the other white with window controls. (We haven't done a Windows build in a while, but had this examples working once upon a time.) Digging a bit deeper I found that glXMakeCurrent was failing, but without setting any gl error code. This was after glXCreateContext returned a valid result. If I make this change in QOSGWidget::createContext() ... // traits-inheritedWindowData = new WindowData(winId()); traits-inheritedWindowData = NULL; we no longer crash, but there are now two windows -- one live and one stale, much like the version on Mac with OSG_WINDOWING_SYSTEM=X11. A check of OpenGL doc indicated that there are legitimate reasons for glXMakeCurrent and glXMakeContextCurrent return false without an error. It would seem likely that Qt is creating a Window that is rejected by glXMakeCurrent some of the time. I'm not familiar with Qt source enough to debug that side of the problem. Does this sound like I'm on the right track? Anyone have a suggestion how to fix this on the OSG side? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] painting into Qt widgets on Mac
Hi Paul, I don't have the old versions you mention around anymore, but there's a recent change to QOSGWidget.cpp that might help. Appearently, QtWidget::winId() returns a value which can be used as a window pointer under Windows and Linux but not under OSX. generic version (original code): traits-inheritedWindowData = new WindowData(winId()); replaced with this for OSX only: traits-inheritedWindowData = new WindowData(HIViewGetWindow((HIViewRef)winId())); the near equivalent Qt code: traits-inheritedWindowData = new WindowData(qt_mac_window_for(this)); The fix assumes that OSG has been built for Carbon and not X11 windowing. When built for X11 there's a seperate OSG rendering window in addition to Qt's. -Don Leich Hello, Has anyone succeeded in using OSG to paint into Qt widgets on Mac OS X? On Windows it works without any problems if I do this: Producer::Camera *cam-getRenderSurface()-setWindow(QWidget::winId()). On Mac, however, this only works if the QWidget is a toplevel widget. If a QWidget is inside another widget, though, the window never gets repainted. I've tried using QWidget::handle() instead, but that only returns the same thing as winId for that widget's toplevel ancestor. I'm using Leopard 10.5.6. But both OSG and Qt are old versions: OSG 1.2 and Qt 3.3.8. Sorry, but I can't upgrade now... Thanks Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] out-of-source builds don't work reliably?
Hi J-S, We've never tried multiple platforms with the same in-source tree, and I wouldn't expect that it should work. However, I would expect that we'd be able to build debug and release versions for a single platform in the same in-source tree. Has this been working reliably for you? We've been trying to set up all builds as out of source with exceptions for Windows (because of our network more than any other reason), and now Mac OS X. These platforms each have their own source trees. Thanks again for your help and experience with this. On your advice I'll stick with out-for-source for 32 and 64 bit Linux. -Don Jean-Sébastien Guay wrote: Hi Don, Because of way our network is set up we build Windows on a seperate drive, so it's always been built in-source. We have several flavors of Linux, Mac, and maybe even Solaris (if we get around to it) that I've been trying to build off the same source directory. Well, building multiple platforms in-source in the same source tree (or in the same build/ directory, or installing to the same directory) isn't a good idea in general. Apart from the fact that the Config file (for both OpenThreads and OSG) will be (and must be) different on different platforms, it can introduce subtle problems, especially for similar platform like unices (which will typically use the same filenames for shared objects, for example). I think you may be making things difficult for yourself :-) My advice: build out-of-source, and use the install target. I find it's easier to have control over what you get that way. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac OS X plugins confusion
On Mac OS X *debug* version executables look for *release* version named plug-in shared libraries. $ osgviewerd cow.osg Warning: Could not find plugin to read objects from file cow.osg. osgviewerd: No data loaded With OSG_NOTIFY_LEVEL=DEBUG... DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so I worked around the problem by creating links like this $ ln -s osgdb_osgd.so osgdb_osg.so for all plugin libraries. This was seen with a fresh debug only build of Friday's 2.7.7 release for Mac OS X. A similar build on 64-bit Linux did not exhibit this problem. Also, nothing to do with out-of-source builds. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] out-of-source builds don't work reliably?
It seems that I've had more difficulty with building OSG than most other developers out there. Now that I've picked up the 2.7.7 release, revisted some old problems and encountered new ones, I may have found much of the cause. I think I have found a bunch of problems due to building OSG exclusively for out-of-source. Specific problems may be limited to Mac OS X, but I think there is just a basic failure of out-of-source builds where cmake does not work as expected. I downloaded Friday's release and did the following... $ unzip OpenSceneGraph-2.7.7.zip -- tweaked CMakeLists.txt to turn on examples remove Mac ppc -- $ mkdir OpenSceneGraph-2.7.7.Build $ cd OpenSceneGraph-2.7.7.Build $ cmake ../OpenSceneGraph-2.7.7 -DCMAKE_BUILD_TYPE=Debug $ make This ran smoothly until the build of the osgviewerQT executable where the file GL/glx.h could not be found. Previously I had to alter src/CMakeLists.txt in order to resolve this problem. I discovered that the path for GL/glx.h was correctly set in src/osgViewer/CMakeLists.txt, but this file was appearently not seen by the out-of-source build. (For similar reasons the setting of OSG_WINDOWING_SYSTEM seemed to be ineffective.) There are several files that are generated by cmake -- include/OpenThreads/Config and include/osg/Config among them. When building OSG with the out-of-source methodology they are written in the out-of-source directory. This did not pose a problem with building OSG itself, but a re-build of my application failed when these files were not found. They are expected to be found under the src/osg/include directories. It's possible that this problem hasn't showed up until now since I had always done at least an aborted in-source build - enough to write the Config files for an arbitrary architecture. Does anyone have some insight into these problems? Are there some extra steps necessary to build out-of-source correctly, or does it just not work? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] out-of-source builds don't work reliably?
Hi Robert, I did see the thread about the out-of-source Config files and needing to include the out-of-source path. Once I went looking for a solution to this problem it was pretty easy to find. (Although I didn't catch on that installing as a solution until now.) I had been resisting the install step so we are not locked into a specific version of OSG at any given time. I still think the GL/glx.h not found points to a bigger problem. I should have added earlier that when I did an in-source build the problem with not finding GL/glx.h went away immediately. From this it seem that APPLE specific cmake content is ignored for out-of-source builds. -Don Robert Osfield wrote: Hi Don, The glx/gl finding issue is one I've seen from even before the cmake days when doing straight Makefile builds. I don't think the out of source will have any baring on this. My guess is the framework vs include/GL issues might be causing these. I've known exactly why though - I'm only an occasional OSX interloper so can't really help much on insider knowledge. The config issue is a natural consequence to having build specific configuration files and out of source builds, it's a situation that is present on all platforms. If you wish to do out of source builds AND not install the built software then you have to add the include path to the out of source build config directories.Either doing in source build OR installing the software will fix this issue. Robert. On Tue, Dec 16, 2008 at 7:52 PM, Don Leich d...@ilight.com wrote: It seems that I've had more difficulty with building OSG than most other developers out there. Now that I've picked up the 2.7.7 release, revisted some old problems and encountered new ones, I may have found much of the cause. I think I have found a bunch of problems due to building OSG exclusively for out-of-source. Specific problems may be limited to Mac OS X, but I think there is just a basic failure of out-of-source builds where cmake does not work as expected. I downloaded Friday's release and did the following... $ unzip OpenSceneGraph-2.7.7.zip -- tweaked CMakeLists.txt to turn on examples remove Mac ppc -- $ mkdir OpenSceneGraph-2.7.7.Build $ cd OpenSceneGraph-2.7.7.Build $ cmake ../OpenSceneGraph-2.7.7 -DCMAKE_BUILD_TYPE=Debug $ make This ran smoothly until the build of the osgviewerQT executable where the file GL/glx.h could not be found. Previously I had to alter src/CMakeLists.txt in order to resolve this problem. I discovered that the path for GL/glx.h was correctly set in src/osgViewer/CMakeLists.txt, but this file was appearently not seen by the out-of-source build. (For similar reasons the setting of OSG_WINDOWING_SYSTEM seemed to be ineffective.) There are several files that are generated by cmake -- include/OpenThreads/Config and include/osg/Config among them. When building OSG with the out-of-source methodology they are written in the out-of-source directory. This did not pose a problem with building OSG itself, but a re-build of my application failed when these files were not found. They are expected to be found under the src/osg/include directories. It's possible that this problem hasn't showed up until now since I had always done at least an aborted in-source build - enough to write the Config files for an arbitrary architecture. Does anyone have some insight into these problems? Are there some extra steps necessary to build out-of-source correctly, or does it just not work? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] out-of-source builds don't work reliably?
Hi J-S, You're right about using ccmake. I should get it installed on my Linux box. (It already is on my Mac.) I always head for the wrong .txt file to edit. Thanks for sharing your experiences with out-of-source building. I'm not so sure Mac is such a different beast or if the out-of-source problems I've had are rare. Maybe osgviewerQT is the different beast. Because of way our network is set up we build Windows on a seperate drive, so it's always been built in-source. We have several flavors of Linux, Mac, and maybe even Solaris (if we get around to it) that I've been trying to build off the same source directory. In the last week we jumped from 2.6.0 to 2.7.7, so maybe part of my problem is in just catching up. -Don Jean-Sébastien Guay wrote: Hi Don, I think I have found a bunch of problems due to building OSG exclusively for out-of-source. Specific problems may be limited to Mac OS X, but I think there is just a basic failure of out-of-source builds where cmake does not work as expected. I have always built out-of-source, be it on Windows or Linux, and have not had as much trouble as you (by a long shot). It always pretty much worked for me. The fact you build on MacOSX is a difference of course, as is the osgviewerQT example (see below). $ unzip OpenSceneGraph-2.7.7.zip -- tweaked CMakeLists.txt to turn on examples remove Mac ppc -- Err, can't you just use ccmake (or the CMake GUI on MacOSX) to tweak the build? Changing the CMakeLists.txt files should never be necessary, the build files should give you the options you need (if they don't, you can suggest other options to add or add them and contribute the changes...). In particular, building the examples is controlled by a variable which you can just turn off or on. Not sure about the PPC stuff... This ran smoothly until the build of the osgviewerQT executable This is one difference, I have not built osgviewerQT on Linux before. On Windows it builds fine, but I think Linux would more comparable to MacOSX so I can't help there. There are several files that are generated by cmake -- include/OpenThreads/Config and include/osg/Config among them. When building OSG with the out-of-source methodology they are written in the out-of-source directory. This did not pose a problem with building OSG itself, but a re-build of my application failed when these files were not found. They are expected to be found under the src/osg/include directories. It's possible that this problem hasn't showed up until now since I had always done at least an aborted in-source build - enough to write the Config files for an arbitrary architecture. This has been discussed a lot before, check the archives. You have two options: 1. Add the out-of-source build's include directory to your application's include path. 2. Do a make install (make sure your CMAKE_BUILD_PREFIX is set to where you want the binaries+includes to end up) and point your application's include and lib directories there. I personally find the second option cleaner, I don't like other projects depending on a build directory which I consider to be temporary files that could be deleted at any time. But it's up to preference, up to you. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X plugins confusion
Thanks bob. You've earned these bad band photos (almost as good as bad album covers)... http://www.rockandrollconfidential.com/hall/hall_detail.php?dd_keyid=464 -Don Bob Kuehne wrote: hi don, i fixed this by change some cmake to take a different code path so that it creates xxxd and osgdb_xxxd.so style names for os x as well as other platforms. i forgot to submit this for a while, but will right now. watch your osg-submissions channel... bob On Dec 16, 2008, at 8:52 PM, Don Leich wrote: On Mac OS X *debug* version executables look for *release* version named plug-in shared libraries. $ osgviewerd cow.osg Warning: Could not find plugin to read objects from file cow.osg. osgviewerd: No data loaded With OSG_NOTIFY_LEVEL=DEBUG... DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so I worked around the problem by creating links like this $ ln -s osgdb_osgd.so osgdb_osg.so for all plugin libraries. This was seen with a fresh debug only build of Friday's 2.7.7 release for Mac OS X. A similar build on 64- bit Linux did not exhibit this problem. Also, nothing to do with out-of-source builds. -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MAC
Hi Robert, Too much time has lapsed to reconstruct my exact problems -- too much cursing instead of note taking back then. I started with Cmake 2.4.7 that we'd been using for Linux OSG builds. It was quickly obvious that version wouldn't do. I don't recall how I ended up with cmake 2.6.1 - it was probably the latest stable version when I grabbed it, but it was giving me problem after problem. Just lucky I guess. I later grabbed version 2.6.2 which I can build without a hitch and is what I ultimately used to build OSG. I guess the big problem for me was that the Dependencies page was and still is way behind the curve on what's required for building on Mac OSX. It says CMake 2.4 or later is prefered. On Mac specific page there's mention of grabbing the SVN version of Cmake for XCode considerations, but nothing more specific about a required cmake version. The Mac (OS X 10.5.2) has libcurl.4.dylib. I also had a problem building the curl plugin on an i386 Linux system with libcurl.2.0.2 . Other Linux systems here have libcurl.3.0.0 although I haven't built on any of these. -Don Robert Osfield wrote: Hi Don, Cmake should only build the curl plugin if it finds libcurl installed. So I presume that you do have libcurl installed on your system but an older version perhaps that the OSG can't compile against. Could you pass on the errors, and information about which version of libcurl you have installed on your system so we can look at ways of fix this, even with changes to the source code or the build. Robert. On Mon, Dec 8, 2008 at 8:49 PM, Don Leich [EMAIL PROTECTED] wrote: I thought maybe it's time to bring this up. The problem I had building cmake on Mac OS X had to do with libcurl. I got the cmake build past to finally complete by turing off some curl specific tests. The development systems I work on are not connected to the Internet and do not get updated libraries very often. This may be a factor. (I also built cmake from downloaded source.) If even is libcurl is not a prerequisite for OSG is seems that some mention of it on the Dependencies page would be helpful. Many seem to have been bitten by libcurl problems. -Don Leich Raphael Sebbe wrote: Re: [osg-users] MAC Raphael Sebbe Wed, 19 Nov 2008 00:37:11 -0800 I think it's right in the middle of moving from Xcode based projects to cmake build system, which currently generates dylibs instead of frameworks (I may not be up to date, checked a couple of weeks ago, moving target). Once you get a successful build in cmake, with proper build flags, you shouldn't have much surprise on the mac. Raphael On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote: Quoting Don Leich [EMAIL PROTECTED]: My experience with Mac development has not quite so smooth. Getting cmake to build was a battle and beyond the scope of this thread. OSG itself has some appearant rough edges with OSG and X11 integration. I am working with Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6 from DarwinPorts) compiled on OS X. I don't know why you have to use X11 (Qt?) but that could be the cause of your problems. You'd probably see similar issues running OSG/X11 on Windows. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MAC
I thought maybe it's time to bring this up. The problem I had building cmake on Mac OS X had to do with libcurl. I got the cmake build past to finally complete by turing off some curl specific tests. The development systems I work on are not connected to the Internet and do not get updated libraries very often. This may be a factor. (I also built cmake from downloaded source.) If even is libcurl is not a prerequisite for OSG is seems that some mention of it on the Dependencies page would be helpful. Many seem to have been bitten by libcurl problems. -Don Leich Raphael Sebbe wrote: Re: [osg-users] MAC Raphael Sebbe Wed, 19 Nov 2008 00:37:11 -0800 I think it's right in the middle of moving from Xcode based projects to cmake build system, which currently generates dylibs instead of frameworks (I may not be up to date, checked a couple of weeks ago, moving target). Once you get a successful build in cmake, with proper build flags, you shouldn't have much surprise on the mac. Raphael On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote: Quoting Don Leich [EMAIL PROTECTED]: My experience with Mac development has not quite so smooth. Getting cmake to build was a battle and beyond the scope of this thread. OSG itself has some appearant rough edges with OSG and X11 integration. I am working with Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6 from DarwinPorts) compiled on OS X. I don't know why you have to use X11 (Qt?) but that could be the cause of your problems. You'd probably see similar issues running OSG/X11 on Windows. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT example
specific information if that will help smooth out the wrinkles with Qt integration here. -Don Leich Hi all, I would like to know if in a correctly configured Linux, the osgviewerQT example works with the --QOSGWidget option ? I am asking that because we are currently trying to achieve something similar with WinForms on Linux (using Mono), and we are following the same way than the QT example and the QOSGWidget. The big deal is that we are working with VMWare, without real graphics drivers, and this example crash the same way as our application. That's why we would like to know if it's related to VMWare or not. Thanks in advance ! -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux Dev. Env. Poll
We have a mix of SuSE and Fedora of various vintages. I use vim mostly, emacs sometimes; g++; gbd or Totalview (good multi-thread support) for debugging. -Don Can T. Oguz wrote: Dear OSG Users, May I Ask which linux distribution and development environment you chose to work on ? Thank you for your time, Can ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi J-S, J.P., and non-initialed persons of interest (or P.O.I.s), J-S beat me and posted the traces I mailed to him off-line yesterday. I was doing another round of tests to see if I could really duplicate his exact problem. I can't. I don't get the hang unless I change the threading model. On all tested systems I could create 40 or more addView windows when staying with SingleThreaded. A few notes on an anomoly or two in my results. System cartman shows many more threads than expected. Perhaps there's a bug in gdb that shows the same thread multiple time. Where I mentioned missing cows, I would get a background colored window and no other graphics. System curly has a package for a driver fire-glfglrx_4_3_0-8.10.19-1.i386.rpm, but since it's very obviously draw limited it probably really is rendering with Mesa. Another system that is known to be Mesa didn't have any problems with the addView test. System sparky may have an entirely different problem. We're cross platform CAE developers here and upgrade our drivers very infrequently. I suspect that is why we may be finding so many problems with OSG and threading. -Don Hi all, Thanks for testing again. I've had a few other reports for Linux and Windows, some can repro others can't, so I'm trying to get hardware details and driver versions to see if it could be dependent of these factors. Thanks for providing them. Robert suggested off-list that I post these stack traces, so here they are. The first one in particular (jeckle) seems to show the same problem I have been investigating. Thanks to Don Leich for testing on a few different machines (hardware, driver versions). I hope this info will be useful. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Interesting. My system sparky has OpenGL version string: 2.1.1 NVIDIA 100.14.19 AMD-64, SuSe 9.2 (I think) rather old kernel 2.4.21-102-smp -Don Robert, what driver version are you using? Any chance OpenGL version string: 2.1.1 NVIDIA 100.14.19 Intel Quad core, Kubuntu 7.10. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
I tried J-S's test on a couple of systems in my office and got it to hang on several. I'm using OSG 2.6.0 and our drivers are far from bleeding edge (some are several years old). I think I have coaxed additional nastyness from the test by typing an 'm' to change the threading model after each 'a'. This trace is typical of the set, although not identical. I can make serveral more traces available off-line. This system is Linux kernal 2.6.5-7.97-smp x86_64 GNU/Linux; Quadro FX 1100/AGP/SSE2 1.5.2 NVIDIA 66.29. The test hangs after 4th addView on the 'm' to change back to SingleThreaded. 1.1 (182952639424) T in pthread_cond_wait 1.10 (1092614496) T in pthread_cond_wait 1.11 (1094711648) T in pthread_cond_wait 1.12 (1096808800) T in pthread_cond_wait 1.13 (1098905952) T in pthread_cond_wait 1.14 (1101003104) T in pthread_cond_wait 1.15 (1103100256) T in pthread_cond_wait pthread_cond_wait, FP=7fbfffd5a0 pthread_cond_wait, FP=7fbfffd5b0 OpenThreads::Condition::wait, FP=7fbfffd610 OpenThreads::BlockCount::block, FP=7fbfffd660 osgViewer::ViewerBase::renderingTraversals, FP=7fbfffd870 osgViewer::ViewerBase::frame, FP=7fbfffd8a0 osgViewer::ViewerBase::run,FP=7fbfffd8d0 osgViewer::CompositeViewer::run, FP=7fbfffd920 main, FP=7fbfffdc60 __libc_start_main, FP=7fbfffdd30 _start,FP=7fbfffdd40 pthread_cond_wait, FP=411ff5b0 pthread_cond_wait, FP=411ff5c0 OpenThreads::Barrier::block, FP=411ff610 osg::BarrierOperation::operator (), FP=411ff630 osg::OperationThread::run, FP=411ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=411ff7b0 start_thread,FP=411ff870 pthread_cond_wait, FP=413ff5b0 pthread_cond_wait, FP=413ff5c0 OpenThreads::Barrier::block, FP=413ff610 osg::BarrierOperation::operator (), FP=413ff630 osg::OperationThread::run, FP=413ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=413ff7b0 start_thread,FP=413ff870 pthread_cond_wait, FP=415ff5b0 pthread_cond_wait, FP=415ff5c0 OpenThreads::Barrier::block, FP=415ff610 osg::BarrierOperation::operator (), FP=415ff630 osg::OperationThread::run, FP=415ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=415ff7b0 start_thread,FP=415ff870 pthread_cond_wait, FP=417ff580 pthread_cond_wait, FP=417ff590 OpenThreads::Barrier::block, FP=417ff5e0 osg::BarrierOperation::operator (), FP=417ff600 osg::OperationThread::run, FP=417ff6b0 osg::GraphicsThread::run,FP=417ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=417ff7b0 start_thread,FP=417ff870 pthread_cond_wait, FP=419ff1c0 pthread_cond_wait, FP=419ff1d0 OpenThreads::Condition::wait,FP=419ff230 OpenThreads::Block::block, FP=419ff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=419ff2e0 osgViewer::Renderer::draw, FP=419ff460 osgViewer::Renderer::operator (), FP=419ff480 osg::GraphicsContext::runOperations, FP=419ff5a0 osg::RunOperations::operator (), FP=419ff5c0 osg::GraphicsOperation::operator (), FP=419ff600 osg::OperationThread::run, FP=419ff6b0 osg::GraphicsThread::run,FP=419ff6e0 ...reads::ThreadPrivateActions::StartThread, FP=419ff7b0 start_thread,FP=419ff870 pthread_cond_wait, FP=41bff1c0 pthread_cond_wait, FP=41bff1d0 OpenThreads::Condition::wait,FP=41bff230 OpenThreads::Block::block, FP=41bff280 ...wer::Renderer::TheadSafeQueue::takeFront, FP=41bff2e0 osgViewer::Renderer::draw, FP=41bff460 osgViewer::Renderer::operator (), FP=41bff480 osg::GraphicsContext::runOperations, FP=41bff5a0 osg::RunOperations::operator (), FP=41bff5c0 osg::GraphicsOperation::operator (), FP=41bff600 osg::OperationThread::run, FP=41bff6b0 osg::GraphicsThread::run,FP=41bff6e0 ...reads::ThreadPrivateActions::StartThread, FP=41bff7b0 start_thread,FP=41bff870 -Don =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Donald Leich Mailto:[EMAIL PROTECTED] Senior Software Developer Voice: 201-460-4700 ext: 215 Intelligent Light FAX: 201-460-0221 301 Route 17 North, 7th Floor Rutherford, NJ 07070-2575 Visit our web site at http://www.ilight.com =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Hi J-S, I've just upgraded OSG on two Linux machines to latest svn and I can still reproduce the hang with your example. I need to add around 8-12 new windows. The one machine is a dual-core laptop with GeForce Go 7400. The other is a quad-core desktop with a GTX280. Both are running Debian Sid 32-bit. NVidia driver version 177.82. OSG svn 9181. Tried debug and release version on the
Re: [osg-users] Reset 2D Orthographic - Perspective
The problems recently mentioned with funky clipping in an orthographic projection may be related to something I found. I've been working on and off porting a legacy application to use OSG. In this application we are able to toggle between perspective and orthographic projections. The distance from the eye to the viewing origin in an orthographic projection, but in OSG it does. I have an off-list exchange about this recently with Paul Martz where he proposes a fix. Hopefully, this will be of some help. Hey Paul, I've hacked your example to display a wireframe of an orthographic projection when isPerspective is set to false. I didn't get around to hooking the boolean to the keyboard. I'm not sure if this would work as is switching on the fly. This will actually exhibit some of the problems I've seen with orthographic views. A Mouse-3 action will go for a while and after a few secs. there's a major flake out - jittering and blinking graphics, etc. Possibly the matrix math becomes unstable. -Don P: In the TrackballManipulator, the right mouse button ...moves the camera forward or backward without changing the field of view. I'd expect right mouse to have no effect in an orthographic view -- eye distance is irrelevant in orthographic projections; parallel lines always render parallel. ... Hm. I tried your code, and ran it while displaying the cow. I used the right mouse to move my eye forward and let it run. What I noticed was the sphere mapping on the cow collapses as the eye distance shrinks. Eventually, the view volume starts to move forward, as if it is trying to stay ahead of where it thinks the eye is located. The cow is eventually in front of the near plane and the window renders blue. D: If I push with Right-Mouse everything is stable for a little while (a second or so). The wireframe frustum then starts to jitter around. This becomes increasingly more violent and the Right-Mouse translation increases. While this is going on the orthographic view of the cow is appearently randomly clipped as the near/far planes jump around. P: I'm not sure what you're trying to accomplish by changing the eye distance in an orthographic view. D: Well, our app calculates 4x4 transforms and doesn't touch TrackballManipulator. We support toggling between perspective and orthographic views and want the consistant look-at-from eye and point-of-interest coordinates in both projections. The point is that I'm surprized that eye distance has any effect in the orthographic projection. I have an effective work around so it's no longer a problem. I suspect ortho doesn't get much exercise. ... I found this to be a decent work around for our app, where _near is the bounding box min Z of our world... // For orthographic, translate so nothing goes behind the eye. osg::Matrix eye; eye.makeTranslate( 0., 0., _isPerspective ? 0. : -_near ); this-getCamera()-setViewMatrix( eye ); P: Ah! Well, the ModelView matrix transforms object space to eye space, where the eye is at the origin. If the ModelView matrix contains a translation, which it must do to support eye distance in a perspective projection, then this distance must go in the ModelView matrix. However, the MatrixManipulators are ignorant of the current projection, and therefore don't know to leave this translation out of the matrix they compute. Perhaps the right thing to do in OSG is to add a setOrtho(bool) method to the MatrixManipulator, and when true, the manipulator would know to remove eye distance from its view matrix computation. As you suspect, I imagine this hasn't been done because ortho receives little usage. Things only get done in OSG if users have a need for it. -Paul Don =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Donald Leich Mailto:[EMAIL PROTECTED] Senior Software Developer Voice: 201-460-4700 ext: 215 Intelligent Light FAX: 201-460-0221 301 Route 17 North, 7th Floor Rutherford, NJ 07070-2575 Visit our web site at http://www.ilight.com =0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0=0= Subject: [osg-users] Reset 2D Orthographic - Perspective From: Jeremy Moles [EMAIL PROTECTED] Date: Tue, 25 Mar 2008 15:13:57 -0400 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Hello folks! Last night I started working on adding a few debugging tools to osgWidget (both for myself, and for people to use in the future) and what I'm currently trying to do is provide a hotkey that will allow a user to switch their HUD view from the standard 2D view and zoom out to a fully perspective 3D view. The main reason I want to do this is so that people can actively view how all of their Windows/Widgets are layered in three dimensions, which will really help me as I finish up this stratum stuff. :) (Don't you love the word stratum?)
Re: [osg-users] Reset 2D Orthographic - Perspective
Of course, I meant to say...
The distance from the eye to the viewing
origin in an orthographic projection
shouldn't affect anything, but in OSG it
does.
Here's the modified osgthirdpersonview example.
-Don
/* OpenSceneGraph example, osgthirdpersonview.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
// This code is originally Copyright (c) 2008 Skew Matrix Software LLC,
// but you may use the code under the terms of the OSGPL as described above.
// This example demonstrates how CompositeViewer can be used to
// provide a third person view of another view, including eyepoint and
// view frustum.
//
// The code creates a CompositeViewer with two Views. Each of the two
// Views has its own window. One View is the typical scene view,
// showing the loaded model(s).
//
// The second View is a third person view showing not just the loaded
// model(s), but also a wireframe representation of the first View's
// frustum. Interactions with the first View are reflect5ed in the
// second View's displayed frustum.
//
// Command line arguments are taken to be models for display. If you
// specify no command line arguments, the code attempts to load cow.osg.
#include osg/Geometry
#include osg/DisplaySettings
#include osg/MatrixTransform
#include osg/LineWidth
#include osgDB/ReadFile
#include osgViewer/CompositeViewer
#include osgGA/TrackballManipulator
const double _fov = 30.;
const double _aspectRatio = 640. / 480.;
const double _oHeight = 1./_aspectRatio;
const double _near = 1.;
const double _far = 10.;
const double _scl = 4.;
// Given a Camera, create a wireframe representation of its
// view frustum. Create a default representation if camera==NULL.
osg::Node*
makeFrustumFromCamera( osg::Camera* camera, bool isPerspective )
{
// Projection and ModelView matrices
osg::Matrixd proj;
osg::Matrixd mv;
if (camera)
{
proj = camera-getProjectionMatrix();
mv = camera-getViewMatrix();
}
else
{
// Create some kind of reasonable default Projection matrix.
if (isPerspective)
proj.makePerspective( _fov, _aspectRatio, _near, _far );
else
proj.makeOrtho( _scl*-1., _scl*1., _scl*-_oHeight, _scl*_oHeight,
_near, _far );
// leave mv as identity
}
// Get near and far from the Projection matrix.
double near = proj(3,2) / (proj(2,2)-1.0);
double far = proj(3,2) / (1.0+proj(2,2));
// Get the sides of the near plane.
double nLeft = near * (proj(2,0)-1.0) / proj(0,0);
double nRight = near * (1.0+proj(2,0)) / proj(0,0);
double nTop = near * (1.0+proj(2,1)) / proj(1,1);
double nBottom = near * (proj(2,1)-1.0) / proj(1,1);
// Get the sides of the far plane.
double fLeft = far * (proj(2,0)-1.0) / proj(0,0);
double fRight = far * (1.0+proj(2,0)) / proj(0,0);
double fTop = far * (1.0+proj(2,1)) / proj(1,1);
double fBottom = far * (proj(2,1)-1.0) / proj(1,1);
// Clobber if orthographic
if (! isPerspective)
{
proj.getOrtho(nLeft, nRight, nBottom, nTop, near, far);
proj.getOrtho(fLeft, fRight, fBottom, fTop, near, far);
}
// Our vertex array needs only 9 vertices: The origin, and the
// eight corners of the near and far planes.
osg::Vec3Array* v = new osg::Vec3Array;
v-resize( 9 );
(*v)[0].set( 0., 0., 0. );
(*v)[1].set( nLeft, nBottom, -near );
(*v)[2].set( nRight, nBottom, -near );
(*v)[3].set( nRight, nTop, -near );
(*v)[4].set( nLeft, nTop, -near );
(*v)[5].set( fLeft, fBottom, -far );
(*v)[6].set( fRight, fBottom, -far );
(*v)[7].set( fRight, fTop, -far );
(*v)[8].set( fLeft, fTop, -far );
osg::Geometry* geom = new osg::Geometry;
geom-setUseDisplayList( false );
geom-setVertexArray( v );
osg::Vec4Array* c = new osg::Vec4Array;
c-push_back( osg::Vec4( 1., 1., 1., 1. ) );
geom-setColorArray( c );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
GLushort idxLines[8] = {
0, 5, 0, 6, 0, 7, 0, 8 };
GLushort idxLinesOrtho[8] = {
1, 5, 2, 6, 3, 7, 4, 8 };
