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 0x00007fa215d13af2 in ?? () from /usr/lib/libGL.so.1
#1 0x00007fa216c730d9 in osgViewer::PixelBufferX11::init ()
from /usr/lib/libosgViewer.so.6
#2 0x00007fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 ()
from /usr/lib/libosgViewer.so.6
#3 0x00007fa216c6fd27 in
X11WindowingSystemInterface::createGraphicsContext
()
from /usr/lib/libosgViewer.so.6
#4 0x000000000040ae91 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 waaaay 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
