Re: [osg-users] Proper method for getting the screen/viewportresolution.
Hi Eric,
I have a camera drawback and have some legacy OpenGL code that needs
to know the size of the viewport. I've tried various combinations of
Viewer-GetCamera() in the main. And the callback class does not seem
to have anything that can get to the viewport.
I suppose it did not work because you checked before viewer windows were
realized (created). You may try viewer.realize() first and then checking the
camera viewport.
Using CameraDraw callback should be fine as well.
Example:
void MyCameraDrawCallback::operator () (osg::RenderInfo renderInfo) const
{
...
osg::Viewport * viewport =
renderInfo.getCurrentCamera()-getViewport();
...
}
Cheers,
Wojtek
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error in Viewer.Frame()
Are you doing this in the same thread ?
You might want to post more of the code your using, to give folks a chance
to see what may at issue
__
Gordon Tomlinson
Email : [EMAIL PROTECTED]
Website : www.vis-sim.com www.gordontomlinson.com
__
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
-Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz
Sent: 30 May 2008 04:02
To: OpenSceneGraph Users
Subject: Re: [osg-users] Error in Viewer.Frame()
1) If there was a call stack in that email, I missed it.
2) Does the problem occur on SVN head?
3) Can you post an .osg file that reproduces the problem in osgviewer?
-Paul
On May 29, 2008, at 8:40 PM, Mike Greene wrote:
Using Windows XP, VS2005 debug, OSG 2.3.7.
Getting an exception inviewer.frame(OSGSimTime); the first
time through the render loop. Looking at the auto variable values, it
appears that BoundingSphere has returned an error.
I do call :
terrainGroup-addChild(terrainNode);
const osg::BoundingSphere bs = terrainNode-getBound();
but not in the actual render loop. Its value seem OK.
The actual exception occurs
in
vector
at this line here:
_Myt operator++()
{// preincrement
-- this line _SCL_SECURE_VALIDATE(this-_Mycont != NULL);
_SCL_SECURE_VALIDATE_RANGE(_Myptr ((_Myvec *)(this-
_Mycont))-_Mylast);
++_Myptr;
return (*this);
}-
VStudio Auto variable values:
_Mycont0x {_Myfirstiter=??? }const
std::_Container_base *
_MyfirstiterCXX0017: Error: symbol not found
-this{_ptr=0x }
std
::_Vector_const_iterator
osg::ref_ptrosg::Node,std::allocatorosg::ref_ptrosg::Node
* const
-ptr{_ptr=0x }osg::ref_ptrosg::Node
-_ptr0x {_initialBound={...}
_computeBoundCallback={...} _boundingSphere={...} ...}osg::Node *
+osg::Object{_name={...} _dataVariance=???
_userData={...} }osg::Object
+_initialBound{_center={...} _radius=??? }
osg::BoundingSphere
+_computeBoundCallback{_ptr=??? }
osg::ref_ptrosg::Node::ComputeBoundingSphereCallback
-_boundingSphere{_center={...} _radius=??? }
osg::BoundingSphere
-_center{_v=0x004b }osg::Vec3f
-_v0x004bfloat [3]
[0]CXX0030: Error: expression cannot be evaluated
[1]CXX0030: Error: expression cannot be evaluated
[2]CXX0030: Error: expression cannot be evaluated
_radiusCXX0030: Error: expression cannot be evaluated
_boundingSphereComputedCXX0030: Error: expression cannot
be evaluated
_parents{_Myfirst=??? _Mylast=??? _Myend=??? }
std::vectorosg::Group *,std::allocatorosg::Group *
+_updateCallback{_ptr=??? }
osg::ref_ptrosg::NodeCallback
_numChildrenRequiringUpdateTraversalCXX0030: Error:
expression cannot be evaluated
+_eventCallback{_ptr=??? }
osg::ref_ptrosg::NodeCallback
_numChildrenRequiringEventTraversalCXX0030: Error:
expression cannot be evaluated
+_cullCallback{_ptr=??? }
osg::ref_ptrosg::NodeCallback
_cullingActiveCXX0030: Error: expression cannot be
evaluated
_numChildrenWithCullingDisabledCXX0030: Error:
expression cannot be evaluated
_numChildrenWithOccluderNodesCXX0030: Error: expression
cannot be evaluated
_nodeMaskCXX0030: Error: expression cannot be evaluated
_descriptions{_Myfirst=??? _Mylast=??? _Myend=??? }
std
::vector
std::basic_stringchar,std::char_traitschar,std::allocatorchar
,std
::allocator
std::basic_stringchar,std::char_traitschar,std::allocatorchar
+_stateset{_ptr=??? }osg::ref_ptrosg::StateSet
Stack Trace :
osg33-osgd.dll!
std
::_Vector_const_iterator
osg::ref_ptrosg::Node,std::allocatorosg::ref_ptrosg::Node
::operator++() Line 117 + 0x33 bytesC++
osg33-osgd.dll!
std
::_Vector_iterator
osg::ref_ptrosg::Node,std::allocatorosg::ref_ptrosg::Node
::operator++() Line 337C++
osg33-osgd.dll!osg::Group::traverse(osg::NodeVisitor
nv={...}) Line 60 + 0x8 bytesC++
osg33-osgd.dll!osg::NodeVisitor::traverse(osg::Node
node={...}) Line 181 + 0x1c bytesC++
osg33-osgUtild.dll!osgUtil::GLObjectsVisitor::apply(osg::Node
node={...}) Line 36 + 0xf bytesC++
osg33-osgd.dll!osg::NodeVisitor::apply(osg::Group
node={...}) Line 236 + 0x22 bytesC++
osg33-osgd.dll!osg::Group::accept(osg::NodeVisitor nv={...})
Line 38 + 0x41
[osg-users] enable/disable a view on a CompositeViewer having more than one view
Hi,
I am new to osg, so I apologise if this question seems trivial. I have
looked through the examples and documentation with no luck.
I am using a composite viewer, and have two views.
I want to be able to let the user disable and enable one of the views
using the keyboard keys.
I have something like this:
osgViewer::CompositeViewer viewer(arguments);
// view one
osgViewer::View* viewOne = new osgViewer::View;
viewer.addView(viewOne);
viewOne-setSceneData(scene.get());
viewOne-getCamera()-setViewport(new osg::Viewport(0,0,
traits-width/2, traits-height/2));
viewOne-getCamera()-setGraphicsContext(gc.get());
// view two
osgViewer::View* viewTwo = new osgViewer::View;
viewer.addView(viewTwo);
viewTwo-setSceneData(scene.get());
viewTwo-getCamera()-setViewport(new osg::Viewport(traits-width/2,0,
traits-width/2, traits-height/2));
viewTwo-getCamera()-setGraphicsContext(gc.get());
So, when the user presses the d key, I want to disable view two, and
when the user presses the e key, I want to enable back view two.
I thought that just removing the view from the viewer should do it,
i.e. something like:
void disable()
{
viewer.removeView(viewTwo));
}
void enable()
{
viewer.addView(viewTwo);
}
but osg crashes when I disable the view. It looks like viewerTwo's
camera is still on the GraphicsContext list of cameras?
How does one disable/enable a view on the composite viewer?
Thanks
Juan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cmake 2.6 issue, latest svn head
Hi all On 5/29/08, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- Current head builds fine on Mac OS X 10.5, cmake 2.4.8 building gcc makefiles. On WinXP SP3, cmake 2.6 building VS8 sln/vcproj files, I get a cmake warning during configuration. See attached warning dialog screenshot. I have seen this also on linux using CMake-2.6. A fix could be something like IF(CMAKE_VERSION = 2.6.0) CMAKE_POLICY(VERSION 2.4.8) ENDIF(CMAKE_VERSION = 2.6.0) ...but needs testing and i'm not as skilled in cmake as I will be (eventually :) Have a deadline today so can try to post a submission this weekend unless a cmake expert steps up. It's just a harmful warning highlighting new features and not many people uses 2.6 yet I guess cheers Mattias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I archieve antialiasing in osg 2.4?
Hi, I just tried the: osg::DisplaySettings::instance()-setNumMultiSamples( 4 ); and didn't get it to work either at first try. I found out that is must be called right after osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer; then it worked just fine.. would have been nice with a warning or something when you try to call setNumMultiSamples after window initialization (if that is the problem). regards, Peter Wraae Marino http://osghelp.com On Fri, May 30, 2008 at 3:05 AM, Leeten [EMAIL PROTECTED] wrote: Hi, all I'm using OSG 2.4 and I can't find GL_LINE_SMOOTH or GL_POLYGON_SMOOTH something in it. The lines and edges of polygons in my scene are jagged( shown in the attachment ), so I'm trying to find some antialiasing way. I've tried the fllowed way which seemed helped nothing. 1) set the Mode of scene group with GL_MULTISAMPLE_ARB; 2) using osg:: DisplaySetting-insence()-setSampleNum( 4 or 8 or 16 ); 3) set the Attribute of scece root with osg::Hint or osg::MultiSample; all above occured nothing change of the jagged edges and lines. Could someone hits me a little? PS: I'm not using osgViewer::Viewer directly, I'm using osgUtil:: SceneView to render my scene and developing on VC 2003.net. 3x. 2008-05-30 -- Leeten ___ 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] VPB: Non-geocentric spherical data set
HI Paul, VPB is built around working on earth data, hence the default to WGS84. You can override the size of the spheriod via --radius-equator value and --radius-polar value, a recent bug fix to VPB fixed this functionality so it should work now. It should also be possible to set the coordinate string for the output, but... I have to admit I haven't tested anything other than earth based data - to start I only have had earth data to work with so far and it's been the focus of the work. As for non the coordinate system the data is in causing problems, again I've never had such data before so can't really provide any guidance on whether GDAL can cope with it. VPB should be able to handle what you after, but there is good chance that we'll need to tweak it a bit to achieve it. What bits we need to tweak I can't say off hand as.. again I have no experience with this type of data. Would it be possible for you to post an example dataset and the VPB options that you are using? Robert. On Thu, May 29, 2008 at 9:59 PM, Paul Brewster [EMAIL PROTECTED] wrote: Hey all, I have a couple questions about VPB. I've been playing around with it for about a month now, and have reached as far as I can go. After some help from here a month ago (thanks all) I spent some time digging through the source code to see what I could find and have reached about as far as I can go by myself. It appears that I am trying to do something that VPB does not support yet. I was hoping I could find a simple change to do what I want, but it doesn't appear to be that easy. Or at least, my mind couldn't get around the code enough to figure it out. Anyway, here are my questions/concerns: 1) I am trying to do a model of the Moon. I have data in PDS format that reads into GDAL just fine. I can run osgdem -l 1 -d foo.pds -o bar.ive and it works fine. If I peek at the resulting ive file, I can see it has a CoordinateSystemNode at the top with the right WKT in it. There is no Ellipsoid because the terrain is flat. And a quick look at the vertices seem to put them in the right area (uses moon radius, not Earth radius). But I really need to do a spherical model of the Moon, since I am doing Lander simulations and things like that matter. The only way I know to make a spherical terrain is to use the --geocentric command. After tracing all over the code, it appears that this forces VPB to use the WGS84 coordinate system, no matter what else I try. When the intermediate and destination coordinate systems are created, it automatically creates the default WGS84 coordinate system with appropriate Ellipsoids, no matter what the input data is. So no matter how I try, I always get an Earth-like Ellipsoid with WGS84 coordinate system in my output. Am I doing something wrong? Is there a command-line to indicate what I want the final coordinate system to be? I have a WKT for the moon. Is there a way to force that? I tried entering that WKT in, but it was never used for creating the intermediate and destination data sets. 2) My data is in a Polar Stereographic projection, rather than a cylindrical type projection. Which means that the center of the image is the North (or South) Pole. Lat lines radially extend from the center and Lon-lines are concentric rings around the center. When I use this on for a --geocentric data set, it shows up as a partial wedge or orange slice from the north pole to about 75 degrees North. It appears to me that it is being treated like a cylindrical projection. I have not looked into this problem as much. Is this a GDAL issue? Where does the projection from a given pixel to a Lat-Lon happen? Anyway, thanks for the help. VPB is a pretty amazing piece of software. I've been able to do huge datasets quickly and easily, so I'm really excited to get it working on the Moon too. I appreciate any help. Paul Brewster Data Visualization and Analysis Lab NASA Langley Research Center ___ 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] CMake issue on RHEL 5
Hi Jason, In the SVN version of the OSG there is a catch for this. FYI, the PgConfig support works from 2.4.7 on my system so you are possible just a bit unlucky. I will putting out a 2.5.1 release today once I've done some bug fixing work. Robert. On Fri, May 30, 2008 at 12:23 AM, Jason Daly [EMAIL PROTECTED] wrote: Hi, all, On Red Hat Enterprise 5 (update 2), I'm getting the following from CMake with the latest svn: CMake Error: PkgConfig_DIR is not set. It must be set to the directory containing PkgConfigConfig.cmake in order to use PkgConfig. This is with CMake 2.4.5 (the version that ships with RHEL 5). I checked out the 2.4.0 tag, and that one builds fine, so I'm guessing this came from the recent additions for the SVG plugin. --J ___ 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] Loading OSG Models in OpenGL code
Hi Siddharth, I'm not clear on what you actually want to do. Do you want to rendering using the OSG, or just use the OSG purely as a data structure? Robert. On Fri, May 30, 2008 at 4:22 AM, Sid [EMAIL PROTECTED] wrote: Hi, Is there any way, I could load an osg model, use some of the osg api functionalities in an opengl code and render it using opengl, not through osg as in osgviewerGLUT example. -- Siddharth Choudhary ___ 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] Proper method for getting the screen/viewport resolution.
Hi Eric, To get he screen resolution you need to the osg::GraphicsContext::WindowSystemInterface and query the getScreenResolution methods. Have a look at the osgcamera example for guidance. Robert. On Thu, May 29, 2008 at 9:17 PM, eheft [EMAIL PROTECTED] wrote: I have a camera drawback and have some legacy OpenGL code that needs to know the size of the viewport. I've tried various combinations of Viewer-GetCamera() in the main. And the callback class does not seem to have anything that can get to the viewport. Currently I am just using win32 api calls to get the screen resolution, which works when in full screen mode. This has got to be so trivial that no one has posted on the subject, at least that I could find. Thank you, Eric ___ 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] enable/disable a view on a CompositeViewer having more than one view
Hi Juan,
You need to stop threading before you remove or add views to a
CompositeViewer. i.e.
viewer.stopThreading();
viewer.addView(view);
viewer.startThreading();
The other thing you can do is toggle the cameras associated with the
view off by setting their NodeMask to 0x0/0x to be off/on
respectively.
Robert.
On Fri, May 30, 2008 at 8:07 AM, Juan Casanueva [EMAIL PROTECTED] wrote:
Hi,
I am new to osg, so I apologise if this question seems trivial. I have
looked through the examples and documentation with no luck.
I am using a composite viewer, and have two views.
I want to be able to let the user disable and enable one of the views
using the keyboard keys.
I have something like this:
osgViewer::CompositeViewer viewer(arguments);
// view one
osgViewer::View* viewOne = new osgViewer::View;
viewer.addView(viewOne);
viewOne-setSceneData(scene.get());
viewOne-getCamera()-setViewport(new osg::Viewport(0,0,
traits-width/2, traits-height/2));
viewOne-getCamera()-setGraphicsContext(gc.get());
// view two
osgViewer::View* viewTwo = new osgViewer::View;
viewer.addView(viewTwo);
viewTwo-setSceneData(scene.get());
viewTwo-getCamera()-setViewport(new osg::Viewport(traits-width/2,0,
traits-width/2, traits-height/2));
viewTwo-getCamera()-setGraphicsContext(gc.get());
So, when the user presses the d key, I want to disable view two, and
when the user presses the e key, I want to enable back view two.
I thought that just removing the view from the viewer should do it,
i.e. something like:
void disable()
{
viewer.removeView(viewTwo));
}
void enable()
{
viewer.addView(viewTwo);
}
but osg crashes when I disable the view. It looks like viewerTwo's
camera is still on the GraphicsContext list of cameras?
How does one disable/enable a view on the composite viewer?
Thanks
Juan
___
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] Fwd: cmake 2.6 issue, latest svn head
Sent yesterday, but never got through... -- Forwarded message -- From: Robert Osfield [EMAIL PROTECTED] Date: Thu, May 29, 2008 at 9:04 AM Subject: Re: [osg-users] cmake 2.6 issue, latest svn head To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Hi Paul, The warning doesn't mean anything specifically to me, but I'd guess that it's related to Philip Lowman's changes in support of CMake 2.6 with backwards compatibility for CMake 2.4.x. Perhaps Philip will know. Robert. On Thu, May 29, 2008 at 2:43 AM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- Current head builds fine on Mac OS X 10.5, cmake 2.4.8 building gcc makefiles. On WinXP SP3, cmake 2.6 building VS8 sln/vcproj files, I get a cmake warning during configuration. See attached warning dialog screenshot. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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] How can I archieve antialiasing in osg 2.4?
Hi Leeten, Full screen anti-aliasing is different the line and polygon smooth modes, for these you just do stateset-setMode(GL_LINE_SMOOTH, osg::StateAttribute::ON); etc. As for full screen anti-aliasing, the advice given so far won't help you, as it only works for osgViewer based apps that use the inbult graphics context generation. As you are managing the graphics context yourself you are on your own, it's entirely up to you how you create and manage your context - it's here you'll need to enable FSAA yourself. Personally I don't recommend using SceneView yourself, you'll just end up needing far more support when you want to add all the extra features like anti-aliasing, multi-context, multi-thread, database paging, event handling all the things that go into providing viewer functionality, while all this functionality is already there for you, in osgViewer. Robert. On Fri, May 30, 2008 at 2:05 AM, Leeten [EMAIL PROTECTED] wrote: Hi, all I'm using OSG 2.4 and I can't find GL_LINE_SMOOTH or GL_POLYGON_SMOOTH something in it. The lines and edges of polygons in my scene are jagged( shown in the attachment ), so I'm trying to find some antialiasing way. I've tried the fllowed way which seemed helped nothing. 1) set the Mode of scene group with GL_MULTISAMPLE_ARB; 2) using osg:: DisplaySetting-insence()-setSampleNum( 4 or 8 or 16 ); 3) set the Attribute of scece root with osg::Hint or osg::MultiSample; all above occured nothing change of the jagged edges and lines. Could someone hits me a little? PS: I'm not using osgViewer::Viewer directly, I'm using osgUtil:: SceneView to render my scene and developing on VC 2003.net. 3x. 2008-05-30 Leeten ___ 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] Problem with osgProducerViewer on new GeForce videocards
Hi Yefei, I just noticed your post. Robert told you everything. You may try duplicating of wglMakeCurrent. But I doubt this is the same issue if Producer really runs in SingleThreaded mode. You may check this with VS Debugger. See menu Debug / Windows / Threads panel. SingleThreaded app should show one main thread. MultiThreaded app will have more of them. For threaded app there is usually one main thread + one or two worker thread for each view + number of opengl shadow threads for each application thread (this may depend on the drivers). I am not sure about DB Pager, tough. There is a chance that you may find aditional thread for the pager. Hi Yefei, Could you try the osgViewer from the SVN version of the OSG? There is a workaround written by Wojiech Lewandowski that calls wglMakeCurrent twice to fix a problem when running multiple windows across multiple display, multi-threaded under WindowsXP with NVidia drivers. The submission reads: From Wojiech Lewandowski, Workaround for wglMakeCurrent bug in NVidia drivers by calling wglMakeCurrent twice. This bug has been reported to NVidia, confirmed and fixed by NVidia but awaits verifiaction and release if a driver which fixes this bug. Also have a look through the last few weeks email discussion on this topic. I'd guess the same workaround would would for Producer/osgProducer i.e. call makeCurrent twice. Robert. On Thu, May 29, 2008 at 11:17 PM, Yefei He [EMAIL PROTECTED] wrote: Hello, folks, Some time ago there was a discussion here about osgviewer rendering junk when running in multi-threaded mode on newer GeForce video cards and multi-core CPUs. One solution was to use single-threaded mode instead. This works on my own Windows XP box as well, but when I tried osgProducerViewer, it seems to render junk regardless of what threading mode I'm using. I tried setting the environmental variable OSG_CAMERA_THREADING to SingleThreaded to make it run in single threaded mode. At least that's what I think as the way to turn the producer viewer into single-threaded mode. Has anybody encountered this as well? Found solutions? My set up has a Intel Core2 Quad Q9300 and two GeForce 9800GX2 cards, although right now there are only two displays connected to a single video card. Cheers, Yefei ___ 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] Operation progress report from OSG Interactive operations
Hi Robert,
See my comments below:
Robert Osfield wrote:
Hi John,
Perhaps a Terrain::init() or update() method would be appropriate -
one that goes through all the tiles registered with
the terrain and calls init() on them.
As for 16 seconds, this is looong time. I am only seeing around a
second of time update on a database
that is getting on 10TB in size, the trick is it's a paged database
and only what is loaded is updated.
Please excuse my ignorance, but osgdem produces pagedLOD databases per
default, doesn't it? At least, the top node of my terrain database start
out like this:
CoordinateSystemNode {
name osgTerrain_globe.ive
nodeMask 0x
cullingActive TRUE
Format WKT
CoordinateSystem GEOGCS[\WGS 84\,DATUM[\WGS_1984\,SPHEROID[\WGS
84\,6378137,298.257223563,AUTHORITY[\EPSG\,\7030\]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\EPSG\,\6326\]],PRIMEM[\Greenwich\,0,AUTHORITY[\EPSG\,\8901\]],UNIT[\degree\,0.0174532925199433,AUTHORITY[\EPSG\,\9108\]],AXIS[\Lat\,NORTH],AXIS[\Long\,EAST],AUTHORITY[\EPSG\,\4326\]]
EllipsoidModel {
RadiusEquator 6378137
RadiusPolar 6356752.3142
}
num_children 1
PagedLOD {This must means model is a pageLOD db, right?
nodeMask 0x
cullingActive TRUE
Center -3963 0 0
Radius -1
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 2 {
1.43452e+08 1e+10
0 1.43452e+08
}
NumChildrenThatCannotBeExpired 0
FileNameList 2 {
osgTerrain_globe_root_L0_X0_Y0/osgTerrain_globe_L0_X0_Y0_subtile.ive
}
1 sec. vs. 16 sec. makes a big difference! OK, I am running my tests on
a laptop, but it has the following specs: Intel Duo T7300, GeForce 8600m
GT 512MB, 2GB Memory, running CentOS 4.6 (a.k.a RHEL 4). So unless
you've spent a fortune on hardware, I don't think hardware differences
alone can explain the difference.
What could potentially contribute to this difference in update time. Any
ideas?
FYI, the thing that will be taking all the time in the generation will
be the display lists/texture object update. Making osgTerrain a bit
more intelligent about it's updates it would be possible to just
update the existing vertices and normals when changing the scale,
something that would be much cheaper. The dirty/update mechinism
would have to be alot more sophisticated though. Long term this is
where osgTerrain is heading, right now its very much in its infancy.
Thanks, this is very useful information. I'll see what I might figure
out when, and if, I get the time. But I'll certainly keep a watchful eye
on any VPB svn updates;)
Best regards,
John Vidar
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Vertex attributes: how does implementation of osg::State::disableVertexAttribPointersAboveAndIncluding() work, it is almost never called
Hi, I am trying to add vertex attributes to my shader program and I am having a crash when I reload the geometry with vertex attributes. Now I am looking into the source and came across the func osg::State::disableVertexAttribPointersAboveAndIncluding(). Looking at the func name I would expect that the vertex attribute units would be disabled, but it doesn't count up. I am really new in this area and would like to learn. Is there someone who can explain this piece? Mike Weiblen, could you take a look maybe, you're a shader expert! A related question: I see that 'some' vertex attribute units are used in examples like the glsl_confetti.osg. Can any unit be used arbitrarily, without 0 which seems to be used for the vertex coordinates? thanks a lot for explaining, best regards Raymond this is in the svn btw ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] I get errors when trying to render to a luminance buffer...
Hi, I want to render to a floating point buffer, and I set things up like this: tex-setInternalFormat( GL_LUMINANCE16F_ARB ); tex-setSourceFormat( GL_RED ); tex-setSourceType( GL_FLOAT ); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach( osg::Camera::BufferComponent( osg::Camera::COLOR_BUFFER0 ), tex ); camera-setDrawBuffer( GL_COLOR_ATTACHMENT0_EXT ); My fragment-shader that write to the surface output the value this way: gl_FragData[0].r = 1.0; Another fragment-shader reads the surface this way: value = texture2DRect( id, gl_FragCoord.xy ).r; I get the following output when I try to run my app: Warning: RenderStage::runCameraSetUp(state) Pbuffer does not support multiple color outputs. My app runs, but nothing is written to the texture. Is it possible to set up a surface that holds one channel (GL_RED) which is an unsigned int of 32 bit resolution? I'd rather use that than a float :-) Viggo _ Lei av å vente på svar? Si det direkte med Windows Live Messenger. http://get.live.com/nb-no/messenger/overview___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: cmake 2.6 issue, latest svn head
Hi Philip, I think Jean-Sébastien's suggestion of setting cmake_policy CMP0005 to OLD is the best option here because we want compatibility with CMake 2.4.x. I'll send it as a submission in a minute. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error in viewer.frame
Paul - Thanks! That fixed the problem. Can you explain why this was needed? /Paul Martz wrote: Try forcing SingleThreaded, either in your app by calling Viewer::setThreadModel, or with the env var OSG_THREADING=SingleThreaded. -Paul / ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I get errors when trying to render to a luminance buffer...
Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I modified my code as you suggested. The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second. It does something. The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again, and the texture gets colors. This works, but then I only have 8 bit in the red channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels. Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, The warning is exactly right, pbuffers don't suport multiple render targets, only FrameBufferObjects do. Perhaps what you intend it not to use multiple render targets, in which case you should set the Camera attachment to COLOR_BUFFER rather than COLOR_BUFFER0, that later tells the OSG that you want MRT and will be using glFragColor[] in your shaders. Also the Camera::setDrawBuffer(GL_COLOR_ATTACHMENT0_EXT) is inappropriate for pbuffers. Robert. On Fri, May 30, 2008 at 1:18 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to render to a floating point buffer, and I set things up like this: tex-setInternalFormat( GL_LUMINANCE16F_ARB ); tex-setSourceFormat( GL_RED ); tex-setSourceType( GL_FLOAT ); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach( osg::Camera::BufferComponent( osg::Camera::COLOR_BUFFER0 ), tex ); camera-setDrawBuffer( GL_COLOR_ATTACHMENT0_EXT ); My fragment-shader that write to the surface output the value this way: gl_FragData[0].r = 1.0; Another fragment-shader reads the surface this way: value = texture2DRect( id, gl_FragCoord.xy ).r; I get the following output when I try to run my app: Warning: RenderStage::runCameraSetUp(state) Pbuffer does not support multiple color outputs. My app runs, but nothing is written to the texture. Is it possible to set up a surface that holds one channel (GL_RED) which is an unsigned int of 32 bit resolution? I'd rather use that than a float :-) Viggo Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass. ___ 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 SkyDrive er her. Glem minnepinnen! ___ 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] I get errors when trying to render to a luminance buffer...
Ok, that make sense. It happens every time I render with a floating point texture. The fall in framerate does not happen when I run the OSG multi render target example using HDR. My code does however use additive blending toward the floating point texture so I bet that is what cause it to fall into a software rendering mode. Do you know about any texture surface bit format that is more than 8 bits (unsigned integer) ? Viggo Date: Fri, 30 May 2008 16:29:05 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, When performance drops like this it's because you've dropped onto a software fallback path in the OpenGL driver. Exactly what formats are software vs hardware depends upon the hardware and OpenGL drivers. You'll need to check with your hardware vendors specs to see what will be hardware accelerated. Robert. On Fri, May 30, 2008 at 2:16 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I modified my code as you suggested. The warning is gone :-) The framerate is now 10 seconds per frame instead of 30 frames per second. It does something. The texture I render to remains black (cleared to black). If I change the setInternalFormat to GL_RGBA then the framerate is up again, and the texture gets colors. This works, but then I only have 8 bit in the red channel. What I need is as many bits as possible in the red channel, preferably 32. And I do not need GBA channels. Do you have a suggestion for me on this one? Viggo Date: Fri, 30 May 2008 13:25:24 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] I get errors when trying to render to a luminance buffer... Hi Viggo, The warning is exactly right, pbuffers don't suport multiple render targets, only FrameBufferObjects do. Perhaps what you intend it not to use multiple render targets, in which case you should set the Camera attachment to COLOR_BUFFER rather than COLOR_BUFFER0, that later tells the OSG that you want MRT and will be using glFragColor[] in your shaders. Also the Camera::setDrawBuffer(GL_COLOR_ATTACHMENT0_EXT) is inappropriate for pbuffers. Robert. On Fri, May 30, 2008 at 1:18 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to render to a floating point buffer, and I set things up like this: tex-setInternalFormat( GL_LUMINANCE16F_ARB ); tex-setSourceFormat( GL_RED ); tex-setSourceType( GL_FLOAT ); camera-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); camera-attach( osg::Camera::BufferComponent( osg::Camera::COLOR_BUFFER0 ), tex ); camera-setDrawBuffer( GL_COLOR_ATTACHMENT0_EXT ); My fragment-shader that write to the surface output the value this way: gl_FragData[0].r = 1.0; Another fragment-shader reads the surface this way: value = texture2DRect( id, gl_FragCoord.xy ).r; I get the following output when I try to run my app: Warning: RenderStage::runCameraSetUp(state) Pbuffer does not support multiple color outputs. My app runs, but nothing is written to the texture. Is it possible to set up a surface that holds one channel (GL_RED) which is an unsigned int of 32 bit resolution? I'd rather use that than a float :-) Viggo Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass. ___ 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 SkyDrive er her. Glem minnepinnen! ___ 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 _ Windows Live Hotmail nå med 5000 MB gratis lagringsplass. http://get.live.com/nb-no/mail/overview___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error in viewer.frame
On Fri, May 30, 2008 at 1:44 PM, Mike Greene [EMAIL PROTECTED] wrote: Paul, The program is pretty large with lots of dependencies, so I'm not sure I can attach it here: By SVN head, do you mean using OSG 2.4 instead of 2.3.7? Oh I might guess that Paul might have have SVN head, *not* either of 2.4 or 2.3.7. Since 2.4.0 we've made a fix to the graphics context initialization to prevent the update traversal overlapping with the initial compile traversal. If you code is modifying state in the update traversal that the compile traversal is trying to read then you can get a crash. This is what the fix addressed, the compile traversal now is strictly managed so it doesn't overlap with the initial update traversal. I'm about to tag 2.5.1 which will contain this fix. I'd recommend upgrading to this version. Porting between 2.3.7 and 2.5.1/SVN should be trivial - just a rebuild should be required as the vast majority of the API has been unchanged. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote: The new code is in OpenSceneGraph/CMakeLists.txt is: #use pkg-config to find various modues FIND_PACKAGE(PkgConfig) IF(PKG_CONFIG_FOUND) ... Yes, as I said, that code is in the version I have. This should prevent problems. Could you please post problems you get once you try 2.5.1 or the SVN version out. We can't fix problems if we don't specifically know what they are. Sure, I'll try it again once it's released. I'm mainly posting now because you asked us to test current svn :-) I've tried to give as specific information as I could. If there's anything else I can do to help track down the problem, I'd be happy to provide it. As for the statement Red Hat Enterprise 5 won't be able to generate Makefiles, I think this is rather overblown. First up there is nothing stopping you downloading and installing a more up to date version of CMake. I could easily do that on one workstation, yes. It's more of an issue when you're dealing with a lab of several dozen workstations. This is why we pay to run Red Hat Enterprise. You can even not bother installing it and just set your PATH/LD_LIBRARY_PATH to pick up on a local install. pkg-config is in my path, what else do I need to do? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Hi Jason, On Fri, May 30, 2008 at 6:59 PM, Jason Daly [EMAIL PROTECTED] wrote: Robert Osfield wrote: The new code is in OpenSceneGraph/CMakeLists.txt is: #use pkg-config to find various modues FIND_PACKAGE(PkgConfig) IF(PKG_CONFIG_FOUND) ... Yes, as I said, that code is in the version I have. Could you try isolating the error, I can presume it's coming from the FIND_PACKAGE(PkgConfig). perhaps CMake can't handle Find(Xpackage) when a Xpackage.cmake module doesn't exist. If this is the case then the only way to prevent this error would be to wrap the FIND_PACKAGE with a check against CMake version. I could easily do that on one workstation, yes. It's more of an issue when you're dealing with a lab of several dozen workstations. This is why we pay to run Red Hat Enterprise. Pay for out of date tools... do you get upgrades included? You can even not bother installing it and just set your PATH/LD_LIBRARY_PATH to pick up on a local install. pkg-config is in my path, what else do I need to do? I was referring to installing a more up to date version of CMake in each user account. pkg-config itself isn't the issue, its the availability of CMake's PkgConfig.cmake module that is the problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Hi Jason,
I have introduced the follow:
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
FIND_PACKAGE(PkgConfig)
ENDIF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
Hopefully this will fix your outdated CMake build problems.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.5.1 dev release tagged.
Hi All, I've just tagged the OpenSceneGraph-2.5.1 developer release which can be downloaded from: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.5.1, released on 30th May 2008. OpenSceneGraph-2.5.1 introduces a revamped database pager that provides two database threads, one for local file access, and one for http access - this combination vastly improves the experience of database paged across the internet when a local cache is available. Also introduced is new osgscreencapture example, animated gif support, support for CMake 2.6.0, bug fixes and performance improvement to TXP plugin, vertical scale support and automatic terrain updating added to osgTerrain, a workaround to NVidia/WindowsXP multi-threaded OpenGL driver bud and various bug and build fixes. source package : OpenSceneGraph-2.5.1.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.5.1 OpenSceneGraph Thanks to all the contributors/testers, in just 18 days since 2.5.0 things have moved forward on a number of different fronts ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with osgProducerViewer on new GeForce videocards
Hi, Justin, Thanks for the info. Yes, I think OSG_THREADING is used by the newer osgViewer, which alternatively takes the option --SingleThreaded or --CullDrawThreadPerContext, etc. to switching between threading modes. On the other hand, the older Producer based osgProducerViewer does use OSG_CAMERA_THREADING to determine threading mode. Regards, Yefei -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Vican, Justin E. Sent: Thursday, May 29, 2008 5:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problem with osgProducerViewer on new GeForce videocards Hi Yefei, I can't offer any insight into the multi-cpu issue, but I think the environment variable OSG_THREADING is the one that you want to use. -Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yefei He Sent: Thursday, May 29, 2008 6:18 PM To: OSG Users Subject: [osg-users] Problem with osgProducerViewer on new GeForce videocards Hello, folks, Some time ago there was a discussion here about osgviewer rendering junk when running in multi-threaded mode on newer GeForce video cards and multi-core CPUs. One solution was to use single-threaded mode instead. This works on my own Windows XP box as well, but when I tried osgProducerViewer, it seems to render junk regardless of what threading mode I'm using. I tried setting the environmental variable OSG_CAMERA_THREADING to SingleThreaded to make it run in single threaded mode. At least that's what I think as the way to turn the producer viewer into single-threaded mode. Has anybody encountered this as well? Found solutions? My set up has a Intel Core2 Quad Q9300 and two GeForce 9800GX2 cards, although right now there are only two displays connected to a single video card. Cheers, Yefei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.or g ___ 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] CMake issue on RHEL 5
Robert Osfield wrote:
Hi Jason,
I have introduced the follow:
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
FIND_PACKAGE(PkgConfig)
ENDIF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
Hopefully this will fix your outdated CMake build problems.
Thanks, I'll try it soon. I'm putting out a fire (figuratively) at the
moment.
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
I've recently been working on upgrading code from VC7 to VC9, and have run into all kinds of fun issues. The most significant problem/pain has been the ridiculously slow debugging introduced when compiling with iterator debugging (default behavior of VC8/VC9). I've waded through that mess, getting OSG and the necessary dependencies compiled without iterator debugging turned on (and without Secure SCL on), and my debugging performance has returned to pre-VC8 performance. I did in the meantime run across one slight problem. I've only caught it in one place within OSG, but I'm sure it exists elsewhere in the code: In any case, I kept getting a crash when executing the return statement in the osgDB::getFileExtension() function. After much debugging and research, I found that it seems there is a problem with the VC8/VC9 compiler described on the following page: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Fee dbackID=319895 If you don't want to be bored by the details, it basically says that VC8 VC9 have a bug when Iterator Debugging is turned off with regards to iterator copying, and that Microsoft doesn't intend to address it until VC10. In my specific case, that bug causes an assertion at the return statement of getFileExtension(). This is not a bug in OSG, but it's definitely something to be on the lookout for if you are turning iterator debugging off, whether it be in OSG or any other STL-based code. Has anyone else experienced this? Any thoughts? I have a clunky work-around I'm using that works okay, but I hate clunky work arounds :-) Steve ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hello Steve, If you don’t want to be bored by the details, it basically says that VC8 VC9 have a bug when Iterator Debugging is turned off with regards to iterator copying, and that Microsoft doesn’t intend to address it until VC10. In my specific case, that bug causes an assertion at the return statement of getFileExtension(). Strange, we are using OSG 2.2 and 2.4 with iterator debugging turned off in our apps, and I have never seen this. I'll investigate a bit more on Monday, this is intriguing... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote: I could easily do that on one workstation, yes. It's more of an issue when you're dealing with a lab of several dozen workstations. This is why we pay to run Red Hat Enterprise. Pay for out of date tools... do you get upgrades included? Of course, in fact, we get upgrades that are fully tested and guaranteed to be compatible with the rest of the system. As a result, you don't always get the very latest version of software, but you get a very stable system. I doubt Red Hat will deploy CMake 2.6 until RHEL 6. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake issue on RHEL 5
Robert Osfield wrote:
Hi Jason,
I have introduced the follow:
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
FIND_PACKAGE(PkgConfig)
ENDIF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
STRGREATER 2.4.5)
Hopefully this will fix your outdated CMake build problems.
Hi, Robert,
That does indeed make the elder CMake happy again.
Thanks!
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Debug VPB build problems on Windows
Has anyone done a Debug build of the VPB svn head on Windows using cmake 2.6 and VS8? I am getting a slew of unresolved symbols from osgTerrain and osgDB. For example, here's output from an osgdem link attempt: 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: class osgTerrain::TerrainTechnique * __thiscall osgTerrain::TerrainTile::getTerrainTechnique(void) ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED] @XZ) referenced in function _main 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall osgTerrain::TerrainTile::TerrainTile(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function _main 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __cdecl osgDB::findDataFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,enum osgDB::CaseSensitivity) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@V?$al [EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@1@@Z) referenced in function _main 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgTerrain::TerrainTile::cloneType(void)const ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@XZ) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual class osg::Object * __thiscall osgTerrain::TerrainTile::clone(class osg::CopyOp const )const ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@@Z) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual bool __thiscall osgTerrain::TerrainTile::isSameKindAs(class osg::Object const *)const ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@@Z) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgTerrain::TerrainTile::libraryName(void)const ([EMAIL PROTECTED]@osgTerrain@@UBEPBDXZ) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual char const * __thiscall osgTerrain::TerrainTile::className(void)const ([EMAIL PROTECTED]@osgTerrain@@UBEPBDXZ) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osgTerrain::TerrainTile::accept(class osg::NodeVisitor ) ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@@Z) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual void __thiscall osgTerrain::TerrainTile::traverse(class osg::NodeVisitor ) ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@@Z) 1osgdem.obj : error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphere __thiscall osgTerrain::TerrainTile::computeBound(void)const ([EMAIL PROTECTED]@osgTerrain@@[EMAIL PROTECTED]@@XZ) 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) protected: virtual __thiscall osgTerrain::TerrainTile::~TerrainTile(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function protected: virtual void * __thiscall osgTerrain::TerrainTile::`scalar deleting destructor'(unsigned int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) class osg::Node * __cdecl osgDB::readNodeFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED] @[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@1@@Z) referenced in function class osg::Node * __cdecl osgDB::readNodeFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@2@@std@@@Z) 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: class osgDB::ReaderWriter::Options * __thiscall osgDB::Registry::getOptions(void) ([EMAIL PROTECTED]@osgDB@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) referenced in function class osg::Node * __cdecl osgDB::readNodeFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@2@@std@@@Z) 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) public: static class osgDB::Registry * __cdecl osgDB::Registry::instance(bool) ([EMAIL PROTECTED]@osgDB@@[EMAIL PROTECTED]@Z) referenced in function class osg::Node * __cdecl osgDB::readNodeFile(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED] @@[EMAIL PROTECTED]@2@@std@@@Z) 1osgdem.obj : error LNK2019: unresolved external symbol __declspec(dllimport) bool __cdecl osgDB::writeNodeFile(class osg::Node const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class
