Re: [osg-users] QuicktimeLiveImageStream.h missing?
On Nov 8, 2007 3:40 AM, Abe Stephens [EMAIL PROTECTED] wrote: Hi, It looks like a header QuicktimeLiveImageStream.h was missing from a recent commit, the .cpp file is in place... Could you try a svn update and let me know if it now works. Live video stream support is pretty cool.. Even cooler when you see it running on a distortion corrected spherical display :-) http://pufferfishdisplays.co.uk/ Got to see it Present3D/OSG all running on one of there display on Monday, live feed worked great. Alas I didn't get to take one of the display home. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgconv
Hi Tony, It's kinda of odd that the line in osgconv.cpp: if (dynamic_castosgViewer::GraphicsWindow*(_gc.get())) Doesn't for the symbol GraphicsWindow to be imported and there for osgViewer linked properly, perhaps this is a bug in the linker. Referencing something benign like osgViewer::osgViewerGetLibraryName() is a bit obscure relatively harmless if one comments why its there. I'd rather getting using something useful in osgconv for this purpose though. Robert. On Nov 8, 2007 12:25 AM, Tony Horrobin [EMAIL PROTECTED] wrote: Hi, Depends from the platform sdk reveals that osgconv.exe is not linking with osgViewer.dll because by default there are no symbols to be resolved from it due to the decoupled mechanism used to get a context. Other proxies in e.g. the openflight loader will be constructed because the library is explicitly loaded or because there are exports that are used in the final executable. I have no idea how to force it to obey the user in the first place, since osgViewer is both a project dependency and explicitly specified on the linker additional dependencies line. Using /OPT:NOREF has no effect, as do various combinations of function-level linking, declaring the proxy as an export, in the header... As it turns out, forcing any old reference by say calling osgViewer::osgViewerGetLibraryName() at the top of main is sufficient to set things right. Would this be any more acceptable? Cheers, -Tony Robert Osfield wrote: On 11/2/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Luigi, You and I both know that that will work. Since Robert doesn't like that solution, I'm not going to bother. I'm not as noble as some--I have my own software to write. Well I want to fix the problem properly that's all, adding a locally constructed Viewer object might work but its a hack that hides the real issue - why Windows/VS is not automatically constructing the proxy registration object in osgViewer/GraphicsWindowWin32.cpp. If one can fix this then osgconv should just work. It might require a different compile option. Robert. ___ 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
[osg-users] How to exclude nodes from a pick list
Hi All, I have a quick question. I'm playing with picking objects in a scene using the pickhandler example. The scene is essentially a big box whose faces face inwards. Within the box I have a smaller box whose faces face outwards. If I am outside both boxes, looking into the outer box, the pickhandler returns both the outer box, face that I have hit, and the inner box faces that I have hit. As the outer box face is actually facing away from me, I want to exclude it. Is there an easy way to do this? My thinking was that I essentially need to look at the normal of the face that I hit, and the direction of view vector for the camera, take the dot product, and if positive exclude it. Does this sound right? Is there an easier way/structure that I should use? Many thanks for any help Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] marker projection on sphere
What type of marker ? Some kind of geometry or just texture projected on the
surface ?
I am afraid that first one would be impossible without some intersection
testing (or depth picking - maybe GL picking could work - but its a guess as
I am not an expert on GL picking).
Texture marker may be much simpler using texgen and second texture stage for
marker.
If you are allowed to use shaders you may try to do some procedural fragment
coloring based on direct screen coords available in fragment shader.
Does this marker needs to adjust to the depth somehow ? If not why you just
not draw it at your screen location after whole scene was drawn ?
Regards,
Wojtek Lewandowski
PS. Mozesz zaatakowac mnie bezposrednio pod moim adresem po Polsku. Musimy
sobie pomagac ;-)
- Original Message -
From: Janusz Goldasz [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Sent: Wednesday, November 07, 2007 7:38 PM
Subject: [osg-users] marker projection on sphere
Hello:
I would appreciate any help/advice to direct me in the right direction-
I need to project a marker on a sphere in such a way that its
coordinates when projected back on the viewport (screen coordinates)
remain constant regardless camera movements/panning/dragging/pitch
changes, etc. For a number of reasons this cannot be done using
intersector.
The marker has to follow the camera motion gliding on the sphere's
surface in any direction (or a little above it) but the projected
coordinates should not change and ideally be located in the center of
the viewport.
If that were done using the intersector the OSG code would be, e.g.:
---
if
(viewer-computeIntersections(ea.getWindowX()+0.5*ea.getWindowWidth(),ea.getWindowY()+0.5*ea.getWindowHeight(),intersections))
{
const osgUtil::LineSegmentIntersector::Intersection
intersection = *(intersections.begin());
osg::Vec3 markerXYZ = intersection.getWorldIntersectPoint();
// marker on the sphere
.
}
Appreciate any guidance/advice,
Janusz Goldasz
___
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] How to exclude nodes from a pick list
Hi All, I have a quick question. I'm playing with picking objects in a scene using the pickhandler example. The scene is essentially a big box whose faces face inwards. Within the box I have a smaller box whose faces face outwards. If I am outside both boxes, looking into the outer box, the pickhandler returns both the outer box, face that I have hit, and the inner box faces that I have hit. As the outer box face is actually facing away from me, I want to exclude it. Is there an easy way to do this? My thinking was that I essentially need to look at the normal of the face that I hit, and the direction of view vector for the camera, take the dot product, and if positive exclude it. Does this sound right? Is there an easier way/structure that I should use? Many thanks for any help Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] quicktime plugin cmake failure
Hi Gerrick et al, Sorry about this, it's an incomplete submissions that I didn't spot due to not having Windows or OSX. I'll contact the contributor and get the missing file. Robert. On Nov 7, 2007 10:01 PM, Gerrick Bivins [EMAIL PROTECTED] wrote: Looks like the file: QuicktimeLiveImageStream.h is missing from the repository. I have a clean checkout and the file wasn't there. I checked the source browse and it is missing as well: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/quicktime biv ___ 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] quicktime plugin cmake failure
On Nov 8, 2007 9:48 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Gerrick et al, Sorry about this, it's an incomplete submissions that I didn't spot due to not having Windows or OSX. I'll contact the contributor and get the missing file. I've gone through my email archive and found the original submission that had the missing header file, but alas the submission was done with mail tool that inlined the whole submission, argghghg, the subsequent zipped version didn't contain the header. I've just had a bash at extracting what looks to be the header for the flat inlined email, tabbing doesn't look right, but I can't spot any other errors introduced by the mail tool/my editing so hopefully what I have just checked in will work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Depth Buffer to Distance Conversion
Hi, Can someone provide me with the algorithm to convert the value of the depth buffer pixels to ranges? Thanks This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] slow loading with DatabasePager and a model library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've converted FlightGear to use OSG's database pager. While I'm happy that it works at all, I've noticed that it can take a very long time (several seconds) to load in a single terrain tile which does not have very much data by modern standards. I believe the problem is excessive (re)compilation of GL objects. Some background: I'm not using PagedLOD, but am making explicit requestNodeFile calls from FlightGear's existing tiling code. Actually, I've subclassed DatabasePager to support explicit delete requests too. I don't think that this usage pattern changes much with respect to the behaviour I'm seeing. When I set OSG_DO_PRE_COMPILE=no the tile times are much more reasonable (300 - 500 ms). Also, setting OSG_MAXIMUM_OBJECTS_PER_FRAME to higher values lowers the tile time. Both these changes produce noticeable jerks in the visuals. I think it's clear that the slow load times are caused by a storm of GL compile operations building up on the DatabasePager's queue. The terrain in FlightGear is polygon meshes with textures from a material library plus models loaded from the file system. Most of these models are shared with other tiles, so there is a lot of potential for sharing. We use the object cache in the file loader for these models, and the subgraph for the whole tile, including terrain and models, is built in the ReaderWriter::readNode method for the top-level tile file. So... I notice that DatabasePager::FindCompileableGLObjectsVisitor doesn't check if the object is already compiled, so I think our shared models and textures are being recompiled in every new tile that is loaded. This might not be very expensive for textures, but by default only 4 objects are compiled per frame, so it slows down the loading of the tile. The compileGLObjects method for osg::Drawable doesn't check if its object is already compiled (probably by design), and I imagine that compiling display lists could be expensive. Also, I've noticed that the SharedStateManager is called in the update traversal late in the loading process, after objects have been compiled. Is there any reason that this can't be done earlier, in the pager thread, potentially eliminating the need for some compilation? What are people doing with material and model libraries and paging? Do you live with vertex arrays and precompile textures, relying only on the SharedStateManager? I'd rather not give up on display lists just yet. Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHMyTOeDhWHdXrDRURAvWLAKCoBPTSun+pegT+naicyUfnnabG4gCfWCeo kAcwiB7SuyTYk/NiaeJkwAs= =5ClR -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth Buffer to Distance Conversion
Download the GLU source code from opengl.org and look at how gluUnProject() works. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 08, 2007 6:16 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Depth Buffer to Distance Conversion Hi, Can someone provide me with the algorithm to convert the value of the depth buffer pixels to ranges? Thanks This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
...except Robert has already publicly stated that the old line segment and plane intersection classes are now deprecated. In light of that, I would not advise developing any new code that uses them. I don´t think so. It´s the osgUtil::IntersectionVisitor that´s deprecated. The LineSegmentIntersector and PlaneIntersector are both quite new and derived, like the polytopeIntersector you use, from osgUtil::Intersector. Oh, my mistake. Sorry I misunderstood. (The naming scheme is so similar between the new and the deprecated classes, it's confusing.) The best solution is to not use ShapeDrawables -- ever. They are not well supported for anything other than drawing. The osg needs some replacement for standard-shapes like included in glut. In my case, the shapeDrawables do what I want, and thus I will use them! If all you need to do is render, that's great. But there's a significant amount of code, both in OSG and external projects that use OSG, that dynamic_cast Drawables to Geometry objects, and if the cast fails, the code does nothing. So, you've been warned. :-) I think ShapeDrawables are an excellent illustration of how to derive a custom Drawable in OSG. And, as this thread shows, they also demonstrate how custom Drawables have their limitations. It'd be trivial to implement sphere, cone, box, and cylinder using the Geometry class. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
My advice: Don't use ShapeDrawable to draw spheres. Use Geometry instead. The osgUtil Intersector classes work with Geometry because Geometry::accept() actually contains code. -Paul Hi, the lineSegment-intersector and the planeIntersector definitely work with shapeDrawables. For picking spheres in a scene I would use a lineSegmentIntersector. As for the polytopeIntersector in the example-code I don´t know, I haven´t tried that. ...except Robert has already publicly stated that the old line segment and plane intersection classes are now deprecated. In light of that, I would not advise developing any new code that uses them. The best solution is to not use ShapeDrawables -- ever. They are not well supported for anything other than drawing. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
Paul Martz schrieb: My advice: Don't use ShapeDrawable to draw spheres. Use Geometry instead. The osgUtil Intersector classes work with Geometry because Geometry::accept() actually contains code. -Paul Hi, the lineSegment-intersector and the planeIntersector definitely work with shapeDrawables. For picking spheres in a scene I would use a lineSegmentIntersector. As for the polytopeIntersector in the example-code I don´t know, I haven´t tried that. ...except Robert has already publicly stated that the old line segment and plane intersection classes are now deprecated. In light of that, I would not advise developing any new code that uses them. I don´t think so. It´s the osgUtil::IntersectionVisitor that´s deprecated. The LineSegmentIntersector and PlaneIntersector are both quite new and derived, like the polytopeIntersector you use, from osgUtil::Intersector. The best solution is to not use ShapeDrawables -- ever. They are not well supported for anything other than drawing. The osg needs some replacement for standard-shapes like included in glut. In my case, the shapeDrawables do what I want, and thus I will use them! Reagards, Andreas -Paul ___ 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] slow loading with DatabasePager and a model library
Hi Tim, You could try tweaking the FindCompileableGLObjectsVisitor or the Drawable::compileGLObjects() to avoid recompile, see how much difference this makes. Using compressed texture when doing paging also makes a huge difference. Also what hardware/OS are you using? Robert. On Nov 8, 2007 3:01 PM, Tim Moore [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've converted FlightGear to use OSG's database pager. While I'm happy that it works at all, I've noticed that it can take a very long time (several seconds) to load in a single terrain tile which does not have very much data by modern standards. I believe the problem is excessive (re)compilation of GL objects. Some background: I'm not using PagedLOD, but am making explicit requestNodeFile calls from FlightGear's existing tiling code. Actually, I've subclassed DatabasePager to support explicit delete requests too. I don't think that this usage pattern changes much with respect to the behaviour I'm seeing. When I set OSG_DO_PRE_COMPILE=no the tile times are much more reasonable (300 - 500 ms). Also, setting OSG_MAXIMUM_OBJECTS_PER_FRAME to higher values lowers the tile time. Both these changes produce noticeable jerks in the visuals. I think it's clear that the slow load times are caused by a storm of GL compile operations building up on the DatabasePager's queue. The terrain in FlightGear is polygon meshes with textures from a material library plus models loaded from the file system. Most of these models are shared with other tiles, so there is a lot of potential for sharing. We use the object cache in the file loader for these models, and the subgraph for the whole tile, including terrain and models, is built in the ReaderWriter::readNode method for the top-level tile file. So... I notice that DatabasePager::FindCompileableGLObjectsVisitor doesn't check if the object is already compiled, so I think our shared models and textures are being recompiled in every new tile that is loaded. This might not be very expensive for textures, but by default only 4 objects are compiled per frame, so it slows down the loading of the tile. The compileGLObjects method for osg::Drawable doesn't check if its object is already compiled (probably by design), and I imagine that compiling display lists could be expensive. Also, I've noticed that the SharedStateManager is called in the update traversal late in the loading process, after objects have been compiled. Is there any reason that this can't be done earlier, in the pager thread, potentially eliminating the need for some compilation? What are people doing with material and model libraries and paging? Do you live with vertex arrays and precompile textures, relying only on the SharedStateManager? I'd rather not give up on display lists just yet. Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHMyTOeDhWHdXrDRURAvWLAKCoBPTSun+pegT+naicyUfnnabG4gCfWCeo kAcwiB7SuyTYk/NiaeJkwAs= =5ClR -END PGP SIGNATURE- ___ 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 to exclude nodes from a pick list
Hi Robert, sorry, I didn't really explain myself very clearly. The issue isn't so much that I don't want the face from the outer box to be hit, I merely want to be able to identify that it is facing away from the camera, and hence I can ignore it when try to identify that the inner box has been hit. The outer box essentially represents the walls of a room. From outside the room, looking in, I can see the interrior walls which is correct. If I am outside my room looking in, when I click on the box that sits on the floor of my room, I get a pick list that includes the wall that I am looking through. The difficulty is that I wish to discard this, and get the next item in the pick list which is the box that sits on the floor. I can't simply skip the first intersection, as if I were inside the room, then the box on the floor would be the first intersection and I would miss it. Given that I've got a hit on the wall that I'm looking through - which faces away from me and hence isn't visible as the culling gets rid of it for rendering purposes -what I need to do is essentially marry the culling that occurs for rendering with a pick handler so that the pick handler only considers faces that a rendering cull would want to render. My thinking was that, rather than go to the headache of trying to do the marry it would be simpler to take my hit list, and perform the calculation that basically says whether the face is facing towards the camera, or away from it. The hit records gives me a world normal of the face that is hit. I thought that the simplest thing to do would be to get the vector of the direction of look for the camera, multiply the two vectors, and discard those with a positive component in the direction of the camera view. My difficulty is in getting the vector that represents the direction of view of the camera. I don't know how to do that, and I guess thats what I really need the help with. Could you tell me how I get this vector, or perhaps suggest an alternative approach ? Surely the node mask approach would prevent me selecting the interior wall that is facing towards me, which isn't right as I may wish to select this wall and put a really cheesey wall paper texture on it :-) I would be grateful for any help on this. Kind regards Neil ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PickHandler Class on Quick Start Guide
On Nov 8, 2007 3:24 PM, Andreas Goebel [EMAIL PROTECTED] wrote: I don´t think so. It´s the osgUtil::IntersectionVisitor that´s deprecated. osgUtil::IntersectVisitor is the old one that is deprecated. osgUtil::IntersectionVisitor is the new one that exists in 1.9.x onwards. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CombineLODsVisitor
Hi Robert -- I'm confused by the CombineLODsVisitor at Optimizer.cpp line 1498. The apply(LOD) method doesn't do anything unless the LOD is a PagedLOD. Not sure why the code is written this way. The combineLODs() method doesn't appear to be PagedLOD-specific, in fact there's nothing about this algorithm that would appear to require PagedLODs as far as I can tell. If apply(LOD) really is PagedLOD-specific, then why not just use apply(PagedLOD) instead? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth Buffer to Distance Conversion (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Paul, 'gluUnProject' is a world space inverse projection If I understand right, the depth buffer mapping is vendor specific and is traditionally a logarithmic mapping. I'm not aware of a generic algorithm to do the inverse projection for the depth buffer. Try the 'Real-Time Rendering' text and/or their website: http://www.realtimerendering.com/ Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, November 08, 2007 8:12 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Depth Buffer to Distance Conversion Download the GLU source code from opengl.org and look at how gluUnProject() works. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 08, 2007 6:16 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Depth Buffer to Distance Conversion Hi, Can someone provide me with the algorithm to convert the value of the depth buffer pixels to ranges? Thanks This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated. 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] QuicktimeLiveImageStream.h missing? (fixed)
Thanks for that the quick response with the quicktime header--I'm able to fully configure now. I was able to build OSG on Leopard by turning off OSG_GLU_TESS_CALLBACK_TRIPLEDOT and explicitly adding -Wl,- dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ Versions/A/Libraries/libGL.dylib to the link line for the freetype stuff. Abe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] slow loading with DatabasePager and a model library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Tim, You could try tweaking the FindCompileableGLObjectsVisitor or the Drawable::compileGLObjects() to avoid recompile, see how much difference this makes. Using compressed texture when doing paging also makes a huge difference. OK; I'll check those out. Also what hardware/OS are you using? Fedora, 3 Ghz dual processor P4, 8800 GTS. I don't have any I/O worries about the machine; other OSG sample programs and databases run fine. Tim Robert. On Nov 8, 2007 3:01 PM, Tim Moore [EMAIL PROTECTED] wrote: Hello, I've converted FlightGear to use OSG's database pager. While I'm happy that it works at all, I've noticed that it can take a very long time (several seconds) to load in a single terrain tile which does not have very much data by modern standards. I believe the problem is excessive (re)compilation of GL objects. Some background: I'm not using PagedLOD, but am making explicit requestNodeFile calls from FlightGear's existing tiling code. Actually, I've subclassed DatabasePager to support explicit delete requests too. I don't think that this usage pattern changes much with respect to the behaviour I'm seeing. When I set OSG_DO_PRE_COMPILE=no the tile times are much more reasonable (300 - 500 ms). Also, setting OSG_MAXIMUM_OBJECTS_PER_FRAME to higher values lowers the tile time. Both these changes produce noticeable jerks in the visuals. I think it's clear that the slow load times are caused by a storm of GL compile operations building up on the DatabasePager's queue. The terrain in FlightGear is polygon meshes with textures from a material library plus models loaded from the file system. Most of these models are shared with other tiles, so there is a lot of potential for sharing. We use the object cache in the file loader for these models, and the subgraph for the whole tile, including terrain and models, is built in the ReaderWriter::readNode method for the top-level tile file. So... I notice that DatabasePager::FindCompileableGLObjectsVisitor doesn't check if the object is already compiled, so I think our shared models and textures are being recompiled in every new tile that is loaded. This might not be very expensive for textures, but by default only 4 objects are compiled per frame, so it slows down the loading of the tile. The compileGLObjects method for osg::Drawable doesn't check if its object is already compiled (probably by design), and I imagine that compiling display lists could be expensive. Also, I've noticed that the SharedStateManager is called in the update traversal late in the loading process, after objects have been compiled. Is there any reason that this can't be done earlier, in the pager thread, potentially eliminating the need for some compilation? What are people doing with material and model libraries and paging? Do you live with vertex arrays and precompile textures, relying only on the SharedStateManager? I'd rather not give up on display lists just yet. Thanks, Tim ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHM41neDhWHdXrDRURAiXrAKDfsljuLckH8dxU1LDEoOaHeXOW3QCeIDgQ qw8lH0YWsES6JKFYBb6SHiE= =TgMC -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building osg on release version of leopard
Thanks for the fix Eric, Is this change made to the CMake generated projects, or to the XCode directory from svn ? Mihai E. Wing wrote: Sorry, the path was going to $(SDKROOT)/usr/X11R6/lib, but I forgot to account the change to X.org, so the path needed to be $(SDKROOT)/usr/X11/lib. I updated the Xcode project so both paths are listed so it should now do the right thing against both the 10.4 and 10.5 SDKs. -Eric On 11/7/07, Radu Mihai [EMAIL PROTECTED] wrote: Hi To confirm, tis problem is still present when compiling from svn on Leopard. Setting the sdk to 10.5 did not work, but the previously mentioned fix did ( adding specific dylib to the link line ) Here is a more informative description of the fix: http://www.racoonfink.com/mt-rr-trackback.cgi/580 -- Radu Mihai [EMAIL PROTECTED] On 29-Oct-07, at 9:36 AM, Daniel Larimer wrote: The problem I identified is a fix for building against 10.5 and the build process would have to be smart enough to test it. It would also have to be smart enough to know when it is being built for X11 instead of AGL. I hope Apple fixes the libGL.dylib bug because it has been a thorn in my side for several of the code bases I maintain. Perhaps I didn't understand your solution, I thought your fix required installing a new version of freetype that linked against Apple's open gl instead of the X11 open gl. Dan On Oct 29, 2007, at 3:21 AM, E. Wing wrote: I haven't tried what you suggested so I could be mistaken. But if James's problem is what I think it is, your above suggestion will either not work or could potentially cause other serious/hard-to-identify problems. The problem I',m identifying is a binary interface incompatibility between 10.4 and 10.5. The fix I checked in (which is actually much shorter than your solution because I just add an $(SDKROOT) variable) makes sure to look in the correct SDK locations for things. I suspect your fix is going to try to always link to the native system framework (10.5 in this case) which will cause a linking failure if you are building against the 10.4u SDK and is generally the wrong thing to do. But again, I could be mis-identifying the problem. I do recall a cycle problem kind of like what James described many months ago in a much older seed, but that problem was supposedly fixed quite awhile ago and I haven't encountered it since. (I put together a 10.5 OSG binary package as a test run against the last seed and I did not encounter any build problems as described.) -Eric On 10/28/07, Daniel Larimer [EMAIL PROTECTED] wrote: There is a much easier work around to this X11 Open GL bug and that is to add the following to the linking command. I found this on the Fink page documenting changes required for Leopard: http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/ Versions/ A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ Versions/A/Librarie s/libGL.dylib Dan On Oct 28, 2007, at 10:55 AM, James E.Hopper wrote: the xcode project needs to be fixed. we can no longer use the x11 version of libfreetype as it causes a cycle error because it pulls in the x11 version of opengl. the ossim project has a universal libfreetype in their dependencies package. link to that lets osgdb_freetype build cleanly. dependencies package can be downloaded at: http://ossim.telascience.org/ossimdata/MacOSX/ best jim ___ 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 ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building osg on release version of leopard
Xcode only in the SVN. We're currently trying to iron out issues within CMake itself wrt to SDKs and also Leopard, so the OSG/CMake system still isn't quite there yet. -Eric On 11/8/07, Mihai Radu [EMAIL PROTECTED] wrote: Thanks for the fix Eric, Is this change made to the CMake generated projects, or to the XCode directory from svn ? Mihai E. Wing wrote: Sorry, the path was going to $(SDKROOT)/usr/X11R6/lib, but I forgot to account the change to X.org, so the path needed to be $(SDKROOT)/usr/X11/lib. I updated the Xcode project so both paths are listed so it should now do the right thing against both the 10.4 and 10.5 SDKs. -Eric On 11/7/07, Radu Mihai [EMAIL PROTECTED] wrote: Hi To confirm, tis problem is still present when compiling from svn on Leopard. Setting the sdk to 10.5 did not work, but the previously mentioned fix did ( adding specific dylib to the link line ) Here is a more informative description of the fix: http://www.racoonfink.com/mt-rr-trackback.cgi/580 -- Radu Mihai [EMAIL PROTECTED] On 29-Oct-07, at 9:36 AM, Daniel Larimer wrote: The problem I identified is a fix for building against 10.5 and the build process would have to be smart enough to test it. It would also have to be smart enough to know when it is being built for X11 instead of AGL. I hope Apple fixes the libGL.dylib bug because it has been a thorn in my side for several of the code bases I maintain. Perhaps I didn't understand your solution, I thought your fix required installing a new version of freetype that linked against Apple's open gl instead of the X11 open gl. Dan On Oct 29, 2007, at 3:21 AM, E. Wing wrote: I haven't tried what you suggested so I could be mistaken. But if James's problem is what I think it is, your above suggestion will either not work or could potentially cause other serious/hard-to-identify problems. The problem I',m identifying is a binary interface incompatibility between 10.4 and 10.5. The fix I checked in (which is actually much shorter than your solution because I just add an $(SDKROOT) variable) makes sure to look in the correct SDK locations for things. I suspect your fix is going to try to always link to the native system framework (10.5 in this case) which will cause a linking failure if you are building against the 10.4u SDK and is generally the wrong thing to do. But again, I could be mis-identifying the problem. I do recall a cycle problem kind of like what James described many months ago in a much older seed, but that problem was supposedly fixed quite awhile ago and I haven't encountered it since. (I put together a 10.5 OSG binary package as a test run against the last seed and I did not encounter any build problems as described.) -Eric On 10/28/07, Daniel Larimer [EMAIL PROTECTED] wrote: There is a much easier work around to this X11 Open GL bug and that is to add the following to the linking command. I found this on the Fink page documenting changes required for Leopard: http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/ Versions/ A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ Versions/A/Librarie s/libGL.dylib Dan On Oct 28, 2007, at 10:55 AM, James E.Hopper wrote: the xcode project needs to be fixed. we can no longer use the x11 version of libfreetype as it causes a cycle error because it pulls in the x11 version of opengl. the ossim project has a universal libfreetype in their dependencies package. link to that lets osgdb_freetype build cleanly. dependencies package can be downloaded at: http://ossim.telascience.org/ossimdata/MacOSX/ best jim ___ 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 ___ 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
[osg-users] New Mac OS X 10.5 Leopard binaries posted and Leopard specific documentation added to the Wiki
Some things have been updated. First, a new 10.5 oriented binary package has been uploaded to: http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0-10.5SDK.dmg Hopefully, Robert can add the link to the main downloads page soon. The description should be: Mac OS X 10.5 Universal Binaries (10.5 SDK, 32-bit-only) Second, I have updated and added a bunch of documentation. This is included in the OSX_OSG_README.rtf included in the .dmg, but I have also added all this information plus additional information to the Wiki. Leopard Notes: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5 I also made some updates and fixes to some of the other OS X related pages I found on the Wiki. Since the mail archive seems to have been lost, I added my original post on Objective-C/C++ to the Wiki for reference: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Objective-C And as described in the Leopard notes, I hope to add a formal 10.4 and 10.5 cross-compile SDK for OSG soon. Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Error when I try to run
I downloaded the OpenSceneGraph Quick Start Guide and read it. I created a KDE app in KDevelop. I basically did the following in the header file: osgViewer::Viewer viewer I linked with libosgViewer.so and libosg.so. The program compiles and when I try to run it I am getting the following error: /home/mwhall/Projects/KMap/debug/./src/kmap: error while loading shared libraries: libosg.so.25: cannot open shared object file: No such file or directory Can anyone give me a clue as to what is going on? I linked with the libs in /usr/local/lib64. If you need more info I will provide it, just trying to take baby steps. Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
