[osg-users] Camera on a PAT?
Hello everyone, Can I add an osg::Camera to an osg::PositionAttitudeTransform node to render the scene? The idea is to use the transform node to move and orientate the camera. I tried this myself but all i get is a black screen. Regards, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera on a PAT?
Robert Osfield wrote:
Hi Ben,
On Sat, Sep 6, 2008 at 8:28 AM, benben <[EMAIL PROTECTED]> wrote:
Can I add an osg::Camera to an osg::PositionAttitudeTransform node to render
the scene? The idea is to use the transform node to move and orientate the
camera.
The Camera isn't an ordinary object like a car or house that you
position in the scene, the relationship is that the Camera sits above
the scene that you wish to render, this applies to high level Viewe
Camera's just as it does to ones in the scene graph. The next special
relationship is that the OpenGL modelview matrix the world underneath
the camera positions the world in the local coordinates of the camera,
rather than positioning the camera in world coordinates - this is just
how OpenGL works and OSG works with.
Yes I understand this. But the fact that osg::Camera class is a
derivation of the transform node makes me think this can be done that way.
In your own application you need to Camera to contain the scene you
want to render, if it was a leaf of your scene graph then it wouldn't
have anything to render. You could add you scene to the Camera but
this would cause a circular cycle in the scene graph and bag you'd end
up reccursing till your memory blows... so that certainly work either.
Second you want to set the Camera's view matrix to be the inverse of
the model matrix, rather than the the model matrix that will be
inherited down to the Camera that you have in your setup. So again we
are getting the opposite of what you want by placing the Camera as a
leaf.
So this brings us to how do you solve the task of following nodes in
the scene? The osgGA::NodeTrackerManipulator is one solution, as is
holding the NodePath from the root of your scene to the node you want
to set the position by, and then computing the world to local
transform using osg::computeWorldToLocal(NodePath) (this is what
NodeTracker does internally). If you set the viewer's Camera's view
matrix yourself don't attach a camera manipulator, and just set the
view matrix each frame like:
[snip]
And so I didn't end up writing any sort of manipulator but instead I
manually calculate the transformation matrix and update the camera view
matrix with setViewMatrix() function.
But there is still one problem nagging me. In my application I wish to
view from a local coordinate so the x axis goes into the screen, y-axis
to the right, and z-axis down. I ended up having to transform it like this:
const static vec3 x_axis(1.0, 0.0, 0.0);
const static vec3 y_axis(0.0, 1.0, 0.0);
const static vec3 z_axis(0.0, 0.0, 1.0);
const static double right_angle = -M_PI/2.0;
static matrix rs1; rs1.makeRotate(right_angle, z_axis);
static matrix rs2; rs2.makeRotate(-right_angle, x_axis);
static matrix rs3; rs3.makeRotate(M_PI, z_axis);
const static matrix rs = rs3*rs2*rs1;
matrix camview = matrix::inverse(rs*ts*rotation*translation);
v.getCamera()->setViewMatrix(camview);
but the last few rotations (rs1, rs2, rs3) are not changing from
{x-front, y-right, z-down} to {x-right, y-front, z-up}
Would you enlighten me on this?
Yours,
Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the "cannot find shared object" error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the "cannot find shared object" error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ 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] osgdem segmentation fault
J.P. Delport wrote: Hi, I've had some problems on Debian Lenny with gcc 4.3 and optimisations. I faintly remember an unexplained osgdem segfault as well. I'm not sure what version of gcc you have installed, but try with another version or other optim settings. The GCC version on my machine is 4.2.3. I am not quite familiar with CMake. Could you elaborate what settings have you changed? I used the whatever the default settings that came in the download. Ben jp benben wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the "cannot find shared object" error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ 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] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Could you try : osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the "cannot find shared object" error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ 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] osgdem segmentation fault
Jean-Sébastien Guay wrote: Hi Ben, Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Yeah, integrated graphics generally don't fare well with FBOs or pbuffers. Hopefully it shouldn't crash though, it should tell you it's not supported and exit... osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. Does Mesa support pbuffers or FBOs? It would be completely software, thus slow, but it might work... osgdem really needs a graphics context to do some of its processing, and in order not to pop up a graphics window it uses pbuffer rendering, so the only other alternative would be to get a better graphics card (though that looks like a laptop so you would probably need to run osgdem on another machine that has one). Correct. This is a laptop. My desktop with a GeForce graphics card just broke a week ago :( and I'm too busy to fix it. But this is completely off-topic. Instead I think I'll just try to hack with the newest release of graphics driver but I really doubt it'd work. The entire X11/GLX stack is very confusing btw. J-S Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, This is almost certainly a driver bug. Have a look at the support sits for the Intel hardware to see if there is any reports about problems with pbuffers/FBO's and any fixes that can be applied. In terms of workarounds, osgdem requires a graphics context, so could probably just use a standard graphics window, and it'll actually do this automatically if pbuffers aren't supported, but in your case it looks like GLX is claiming they are supported so OSG/VPB then goes are tries to create one and then it crashes because of a bug in the driver. You could comment out the code that tries pbuffers, this is just a hack though and not something suitable for merging with SVN. First, thanks for your detailed replies. It really drilled down to the problem source and I am very happy about that. I really don't have the time to do any hacking, not to mention I am an entire novice to OSG and VPB, having been writing OSG apps since a month ago. That said, I'd like to know what are the odds if I try to generate the terrain from another computer but still load it on this machine? That is, does the terrain paging/rendering process touches the pixel buffer part that's known now not working? The other solution is a hardware one - go buy yourself a cheap Nvidia card, plugin it in, enable the NVidia drivers and you'll be away. You'll get loads of performance, even on load end hardware and driver quality and features are way better. As I mentioned in my reply to Guay, that this machine is a laptop so the hardware replacement option is negative. The best I can do now is to research for hopefully bug fixes in my graphics driver. Robert. Thanks, Ben On Thu, Sep 18, 2008 at 4:53 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Could you try : osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben <[EMAIL PROTECTED]> wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention
