Re: [osg-users] osgdem segmentation fault
Hi, I've had some problems on Debian Lenny with gcc 4.3 and optimisations. I faintly remember an unexplained osgdem segfault as well. I'm not sure what version of gcc you have installed, but try with another version or other optim settings. jp benben wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find shared object error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Are there any plans for GPGPU utiliziation in OSG?
Hi, we've found OSG to be quite useful for image processing type GPGPU work. One can get quite a bit done in OSG with GLSL, multiple passes and multi-target FBOs. jp Robert Osfield wrote: Hi Judie, You wouldn't integrate GPUPU in the same way as SIMD instructions on the CPU for matrix operations, rather you'd use it a similar way to present GLSL programs - that you pack the input a large block of data with a program and execute it on the GPU then later get the results. There is OpenGL integration with Cuda and the up coming OpenCL which might make it useful for combining things like physics and effects with geometry and textures in the scene. I don't forsee the OSG being a general route into GPUPU, the OSG is a scene graph for representing scenes and rendering it. Robert. On Wed, Sep 17, 2008 at 6:14 PM, Judie Stanley [EMAIL PROTECTED] wrote: Hi, Are there any plans for utilizing General Purpose GPU for matrix operations? At SIGGRAPH 2008, there was a lot of discussion about utilizing the GPU this way and some hardware independent libraries for using GPGPU do exist. I am currently looking into this for future projects. Thank you, Judie ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Floating Point Texture Format
See here: http://article.gmane.org/gmane.comp.graphics.openscenegraph.cvs/3084/match=floating+tiff http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/31039/focus=31105 jp Bill Prendergast wrote: Are there any file formats that natively handle floating-pt RGBA values? I’m looking for one that can be handled by osgDB read/writeImageFile where the data is stored in a format such as GL_RGBA32F_ARB (and preferably can be viewed offline by some generic viewer provided the values are in the [0,1] range). I can read/write them raw, but would prefer something standard if it exists. Thanks, Bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Material and shapes
Hi users, I'm trying to apply a material color to a shape. I assume material color is a state and can be applied to the group that contains the shape. This being said the basic code looks like this: osg::Group* pGroup = new osg::Group; osg::Geode* pGeode = new osg::Geode(); pGeode-addDrawable( new osg::ShapeDrawable( newosg::Capsule(osg::Vec3(8.0f,0.0f,1.0f),0.5f,3.0f) ) ); pGroup-addChild( pGeode ); osg::Material* mat = new osg::Material(); mat-setColorMode( osg::Material::DIFFUSE ); mat-setDiffuse( osg::Material::FRONT_AND_BACK, osg::Vec4(0.0, 1.0, 0.0, 1.0) ); pGroup-getOrCreateStateSet()-setAttribute( mat, osg::StateAttribute::ON ); I would expect my capsule to be green.. but it's still gray? searching the archive I fould this: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg04463.html and he states at the bottom that osg::Material can be used with shapes so,.. am I missing something? Can someone shed a little light and give me a push in the right direction. -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to apply shadows to a scene with different shaders- Part 2
Hi, As a propnent of IMPROVE_TEXGEN_PRECISION fix I feel I should make a response but I am not sure what your problems really are. Tweak in ShadowMap was related to the way OSG OpenGL computes final texture coordination matrix. I assume you have read OpenGL documentation and you know how Texgen with eye space works. Texture coord matrix is computed as multiplication of current inverted view matrix and texgen planes. Problem is that OpenGL internally uses float matrices. So if our View and TexGen matrices use large coordinates (for example large translations when objects are located on earth surface in WGS84 cartesian representation) and are cast to float matrices we loose lots of math precision. Their multiplication sucks even more. Solution to this was to make sure that large coords are multiplied in OSG using double matrices. When you use shaders you are not limited by this functionality and you mays skip using fixed pipeline gl_EyePlane uniformsl. You may simply compute your own tex coord matrix by multiplying inverted view and tex gen using OSG double matrices. Then pass this result as an uniform to your shaders and compute tex cooords by multiplying view coords by your matrix. Cheers, Wojtek Hi guys, I followed this excellent thread http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/31360 with much success. I was able to mimic texgen in the vertex shader and get shadows applied in the frag shader. However, the quality doesn't match what you get with ShadowMap using fixed function vertex processing and I believe I can see where it's coming from. In ShadowMap.cpp there exists the macro constant IMPROVE_TEXGEN_PRECISION. What I have in the shader doesn't take this enhancement into account. Anyone know how this can be done? Thanks, Michael Guerrero ___ 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] AutoTransform and small feature culling again
I have been through an issue that has been discussed previously on the osg-users mailing list. I have put the previous discussion below (it was end of august). The culling traversal was never called on an AutoTransform with auto scale because of small feature culling. So Robert answers with three solutions : 1) Switch off small feature culling : i don't want to do that because other node needs it for best performance 2) Override the computeBound() of the AutoTransform so that it returns an invalid bounding sphere for the first frame : the AutoTransform::computeBound() is already doing that ! 3) Override the computeBound() of the AutoTransform so that it returns an large default bounding sphere for the first frame i try that and it works quite well In fact, solution 2) does not work when the AutoTransform has a parent with multiple children. In this case, the parent is equals to valid bound of its children. So solution 3) works quite well, except when there is a huge camera movement. More precisily, when you look closely at the AutoTransform nodes, and then go back instantly to a very far distance. Culling traversal will not be called again because the AutoTransform bound will be too small... Not sure how to handle this case at the AutoTransform level or if it is possible. Thanks, Fabien -- Hi Sherman, I don't think your code is in error, nor that AutoTransform or small feature culling is in error, rather it's unfortunately chicken and the egg which came first? type dependency. The ways to break the culling of custom node in the first frame would be: To switch off small feature culling or set its value very low. To override the computeBound() of the AutoTransform so that it returns an invalid bounding sphere for the first frame till its been through the cull traversal once, once its been set correct then let the bounding sphere be computed correctly. To override the computeBound() of the AutoTransform so that it returns an large default bounding sphere for the first frame till its been through the cull traversal once, once its been set correct then let the bounding box be computed correctly. The two later solutions could possibly be rolled into AutoTransform itself. Robert. On Mon, Aug 25, 2008 at 2:53 AM, sherman wilcox wilcox.sherman at gmail.com wrote: I've attached a small demo app that illustrates an issue I've discovered (known?) with AutoTransform nodes and small feature culling. Briefly summarized, if I add a custom AutoTransform node (see code for trivial example) to the scenegraph just under the root node everything seems fine, with or without small feature culling enabled. However, if I add this AutoTransform node as a member of a osg::Group and then add the group to the scenegraph then this node's accept function no longer is called after the first traversal if small feature culling is enabled. However, if I disable small feature culling all is well. Is this a bug or am I doing something wrong? ___ osg-users mailing list osg-users at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] kdtree or k-dop tree?
hi all, The kdtree in the new version of osg2.6 is just a Binary Tree or it is the k-dop(discrate orientation polytope) tree? Anybody knows? thanks, peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPPU
Hi users, I have some questions related to the osgPPU, but don't know if this mailing-list is the right place to post these questions? It seems that osgPPU is a 3rd party software and not directly an OpenSceneGraph implementation and the site that has osgPPU has a helpdesk ticket system... so do I ask questions related to osgPPU here or do I use the ticket system on the osgPPU website? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] kdtree or k-dop tree?
Hi Peter. On Thu, Sep 18, 2008 at 9:49 AM, 浣曚紵 [EMAIL PROTECTED] wrote: The kdtree in the new version of osg2.6 is just a Binary Tree or it is the k-dop(discrate orientation polytope) tree? Anybody knows? osg::KdTee is a binary tree with axis aligned bounding boxes - which makes it a KdTree :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] kdtree or k-dop tree?
Hi Robert, In the latest version of OSG, KdTee must be used like this: osgUtil::IntersectionVisitor + osgUtil::LineSegmentIntersector,how can we used it like this:osgUtil::IntersectionVisitor + osgUtil::PolytopeIntersector? In my project i need to detect vehicle's collision,i think use PolytopeIntersector willbe better. thanks, Peter 在2008-09-18 16:59:47，Robert Osfield [EMAIL PROTECTED] 写道： Hi Peter. On Thu, Sep 18, 2008 at 9:49 AM, 浣曚紵___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] kdtree or k-dop tree?
Hi Peter, The PolytopeIntersector doesn't yet have support for KdTree intersections. Feel free to add this functionality if you need it. Robert. 2008/9/18 浣�浼� [EMAIL PROTECTED]: Hi Robert, In the latest version of OSG, KdTee must be used like this: osgUtil::IntersectionVisitor + osgUtil::LineSegmentIntersector,how can we used it like this:osgUtil::IntersectionVisitor + osgUtil::PolytopeIntersector? In my project i need to detect vehicle's collision,i think use PolytopeIntersector willbe better. thanks, Peter 在2008-09-18 16:59:47，Robert Osfield [EMAIL PROTECTED] 写道： Hi Peter. On Thu, Sep 18, 2008 at 9:49 AM, 浣�浼� ___ 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] osgPPU
Hi Peter, I think nobody would complain if you ask your questions here. There are already some users using osgPPU successfully in their projects. What is your question? Best regards, art --- Peter Wraae Marino [EMAIL PROTECTED] schrieb am Do, 18.9.2008: Von: Peter Wraae Marino [EMAIL PROTECTED] Betreff: [osg-users] osgPPU An: osg-users@lists.openscenegraph.org Datum: Donnerstag, 18. September 2008, 10:53 Hi users, I have some questions related to the osgPPU, but don't know if this mailing-list is the right place to post these questions? It seems that osgPPU is a 3rd party software and not directly an OpenSceneGraph implementation and the site that has osgPPU has a helpdesk ticket system... so do I ask questions related to osgPPU here or do I use the ticket system on the osgPPU website? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vrml plugin problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Axelrod wrote: | I am trying to load a VRML file, but I get the error message: | | Warning: Could not find plugin to read objects from file foo.wrl. | | I tried this in OSG code, as well as with osgconv and osgviewer. I | have the OSG lib and osgPlugins directories in my LD_LIBRARY_PATH. | | I compiled OSG 2.6.0 from src on Debian Etch. I am using OpenVRML | version 0.14.3. Do I need a newer version of OpenVRML? Nope. Newer versions use Boost and different API - the plugin will not compile. | I had VRML files working with OSG 2.4 a long time ago. Back then I | also set up the Inventor library during the install. But I forgot | what that library does, why it's needed, and even where to get it. | Do I need it here too? No, if you have the VRML plugin, you do not need the Inventor, unless you want to load also the Inventor (.iv) files. I suspect that if your plugin is compiled correctly but doesn't load, most likely either the OpenVRML library or some of its dependencies cannot be loaded at runtime (make sure it is either in one of the standard lib directories or in the LD_LIBRARY_PATH) Set export OSG_NOTIFY_LEVEL=DEBUG and try to run the viewer. Then look for any unresolved symbols while it is trying to load the VRML file. Most likely the dynamic linker cannot find something. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFI0iIJn11XseNj94gRApcAAKDS9aYrLCpVpFNFgRj9OlIe7r5DYQCgu510 NWD2xMubySXsDj1+07U/Jm0= =BEMl -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] osgPPU
Hi Art, thanks.. I actually tried to use the ticket system 10 minutes ago.. but it crashes and couldn't find an email on the website... so I'll post my question here: some code first (point of reference): HDRRendering* pHDRSetup = new HDRRendering; osgPPU::Unit* firstUnit = NULL; osgPPU::Unit* lastUnit = NULL; pHDRSetup-createHDRPipeline( pProcessor, firstUnit, lastUnit ); pProcessor-addChild( firstUnit ); what I wanted was the output result in a texture so I can apply it to a quad. my first attempt was to use the lastUnit-getOuputTexture() but this gave nothing. my second attempt was to use the lastUnit-getOrCreateOutputTexture(0) and this works... but doesn't this mean I have now have two texture instances in the PPU framework of the final scene? Thats why I wanted to use the first attempt method lastUnit-getOutputTexture() any suggestions or am I doing it correctly. regards, Peter On Thu, Sep 18, 2008 at 11:32 AM, Art Tevs [EMAIL PROTECTED] wrote: Hi Peter, I think nobody would complain if you ask your questions here. There are already some users using osgPPU successfully in their projects. What is your question? Best regards, art --- Peter Wraae Marino [EMAIL PROTECTED] schrieb am Do, 18.9.2008: Von: Peter Wraae Marino [EMAIL PROTECTED] Betreff: [osg-users] osgPPU An: osg-users@lists.openscenegraph.org Datum: Donnerstag, 18. September 2008, 10:53 Hi users, I have some questions related to the osgPPU, but don't know if this mailing-list is the right place to post these questions? It seems that osgPPU is a 3rd party software and not directly an OpenSceneGraph implementation and the site that has osgPPU has a helpdesk ticket system... so do I ask questions related to osgPPU here or do I use the ticket system on the osgPPU website? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] kdtree or k-dop tree?
Hi Robert, Can you talk about your mentality when you add KdTree to the osg? If i want to let PolytopeIntersector to support KdTree intersections, what should i do? How many functions and classes should i optimize? Just like the change of LineSegmentIntersector? thanks, Peter 在2008-09-18 17:29:43，Robert Osfield [EMAIL PROTECTED] 写道： Hi Peter, The PolytopeIntersector doesn't yet have support for KdTree intersections. Feel free to add this functionality if you need it. Robert. 2008/9/18 浣曚紵___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp
Thanks John, change now merged and submitted to SVN. On Wed, Sep 17, 2008 at 2:25 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: J-S, OK. Here it is. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, September 16, 2008 9:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp Hi John, Someone, please copy and paste the _stripTextureFilePath( false ) line into the second constructor and add a comma after _lightingDefault( true ). Don't forget the comma :) You could have just sent the whole modified file to osg-submissions... That way no one would have to copy and paste anything, and there would be no chance to make the mistake of forgetting the comma... And then you would be counted among the Anyone else who likes to fix OSG :-) 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 ___ 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] (no subject)
Hi, we want to switch between the shadow techniques at runtime. Sadly some shadows doesn't work correct. Would be cool if someone can help me with this. 1. ShadowVolume It doesn't work in two-pass mode at all. It just displays the shadow volume as a white mesh. screenshot: http://www.swollen-eyeballs.org/zeugs/two_pass.jpg This is really bad as two-sided only works on newer 3d cards. Also disabling the stencil shadows doesnt work, we recreate the ShadowedScene node but it seems like ShadowVolume disables the lighting. 2. ShadowMap ShadowMap sets the ambient value of our light to zero and it doesn't even restore it when calling cleanScenegraph. I think it would be better if ShadowMap copies the ambient value of the light to the ambient uniform used in the fragment shader and later on cleanScenegraph copy it back to the light. (This should also be done in SoftShadowMap) 3. SoftShadowMap I think i've found a bug there. ShadowMap creates a white dummy base texture so you can use shadows in a scene that has both objects with and without textures. SoftShadowMap doesn't do this. 4. ShadowTexture We cant get this to work at all. Is there anything specific we must consider? greetings Christopher Bläsius ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Floating Point Texture Format
Hi Bill, Are there any file formats that natively handle floating-pt RGBA values? In addition to the modified TIFF reader and the ad-hoc reader that J.P. linked you to, the .hdr format is readable out of the box by OSG, and there might be an OpenEXR reader somewhere (not sure). Hope this helps, 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] Floating Point Texture Format
On Thu, Sep 18, 2008 at 2:29 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Bill, Are there any file formats that natively handle floating-pt RGBA values? In addition to the modified TIFF reader and the ad-hoc reader that J.P. linked you to, the .hdr format is readable out of the box by OSG, and there might be an OpenEXR reader somewhere (not sure). FYI, I have just merged changes to the TIFF plugin for support floating point textures. An svn update to trunk will get these changes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find shared object error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
J.P. Delport wrote: Hi, I've had some problems on Debian Lenny with gcc 4.3 and optimisations. I faintly remember an unexplained osgdem segfault as well. I'm not sure what version of gcc you have installed, but try with another version or other optim settings. The GCC version on my machine is 4.2.3. I am not quite familiar with CMake. Could you elaborate what settings have you changed? I used the whatever the default settings that came in the download. Ben jp benben wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find shared object error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques (was: (no subject))
Hello Christopher, we want to switch between the shadow techniques at runtime. Sadly some shadows doesn't work correct. Would be cool if someone can help me with this. In general, shadow techniques in the OSG are very much in their infancy and are probably not production ready for the most part. The exceptions IMHO are ShadowMap and SoftShadowMap which work well (except for the minor bugs you noted below). See http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/osgShadow for some details. Some other shadow techniques are (possibly) coming soon, and will likely be more robust than the current ones in addition to being more high quality. So stay tuned. Regarding ShadowMap and SoftShadowMap, you could make the required fixes and submit them to osg-submissions (see http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol ). Hope this helps, 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] osgdem segmentation fault
Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Could you try : osgprerender cow.osg --pbuffer. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find shared object error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: problem on render order
Hi Ufuk? (could you sign your posts with the name you'd like to be addressed as to make it clear how to address you), There isn't really enough info about how you are going about rendering the terrain, the roads or the trees to know what might be amiss, as things stand one struggles can only guess at what you are doing, let along come to conclusion as to what is going wrong. Could you explain how you have set up the scene graph, and what your shaders are doing. Robert. On Thu, Sep 18, 2008 at 3:27 PM, ufuk gun [EMAIL PROTECTED] wrote: hi i have problem about rendering my roads and trees. i produce them by using shaders... but the problem is their rendering order. Even roads are far away from the trees, they render as they are close to camera. since they have texture with transparency i changed render Bin number of trees and roads. i gave larger render Bin number to trees geometry. this time i totally lost my trees if there is a road on the screen. if no road i can see them. i'm sending you 3 screen shots. same_render_bin.png = they have same render bin number and there is a problem on rendering order. different_render_bin_1.png = screen shot of trees without any roads on the screen... different_render_bin_2.png = screen shot of trees with a corner of a road on the screen... (trees are lost) so do you have any idea about it? ___ 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] Multi-pass rendering in OSG
Art Tevs wrote on Wednesday, September 17, 2008 5:39 PM: To your question. There is already a check of the framebuffer state after each frame. Hence you will recieve an error if something goes wrong. The only places I've found glCheckFramebufferStatusEXT calls is in RenderStage in runCameraSetUp() (after FBO apply()) and drawInner() (only if an error occurs). My understanding is that this function needs to be called before doing any rendering to the FBO, and it doesn't look that will happen if you just use an FBO in a StateSet. Maybe my understanding is wrong? --- Thrall, Bryan [EMAIL PROTECTED] schrieb am Mi, 17.9.2008: Von: Thrall, Bryan [EMAIL PROTECTED] Betreff: Re: [osg-users] Multi-pass rendering in OSG An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Datum: Mittwoch, 17. September 2008, 23:20 J.P. Delport wrote on Wednesday, September 17, 2008 10:39 AM: Hi, have a look at the osgstereomatch example, there is a multi-pass algo example. See the readme of that too. Also search the list archives for osgPPU. Thanks for the pointers; osgPPU looks like what I want, but version 0.2 doesn't seem to work with OSG svn HEAD and my network proxy isn't letting me access osgPPU's svn repo. Oh well, I can copy the concepts from the source code :) Does anyone have an answer to the question I asked: Thrall, Bryan wrote: It looks, from osgUtil::RenderStage's Camera support, like osg::FrameBufferObject can't be used simply by adding it to a StateSet, but it needs glCheckFrameBufferStatusEXT after the apply(). Is this a limitation of osg::FrameBufferObject, or am I missing something? Note: I'm on Windows XP with an NVIDIA 8800 GPU. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.6 API Documentation in HTML, HTML Help and PDF format
Ernst, Your 1.2 docs have been a permanent shortcut on my desktop for several years now, so many thanks for doing the same for 2.6! David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Floating Point Texture Format
OSG also writes Radiance format (.hdr) David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] A couple of Cmake issues with 2.6
Hi All I'm having a couple of issues with Cmake 2.4 or 2.6 with the 2.6 branch ( I'm a Cmake newbie ) ( no had this with OSG 2. x) CMAKE_INTDIR=\Debug\ CMAKE_INTDIR=\Rlease\ or is being added the preprocessor, and this is causing my link to fail s with errors similar to cl : Command line warning D9025 : overriding '/Fotg_OpenThreads.dir\Debug\' with '/Fo' cl : Command line error D8016 : '/fp:fast' and '/fp:except' command-line options are incompatible If I remove this we link fine Also Every debug projet is getting osg.lib and osgd.lib add to its lib inputs Any ideas on what I screwed up (always blame myself as it normally is my fault ) and how to maybe fix the issues ? Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to get model scale？
hi all, When the secne is zoomed in or out ,I want to get the zoom scale.I do it like this: osg::Camera* camera= viewer.getCamera(); osg::Matrix vm=camera-getViewMatrix(); osg::Vec3 scale=vm.getScale(); the result is that scale always equals to (1,1,1).What does this mean and how can I get the reall scale of the scene? thanks best regards forest ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Profiler with OSG
Hi, Searching memory leaks, I use some libraries looking at leaks but it is very difficult to know if a leak is really one or not, specially due to ref_prt. Is there any free profiler (memory, time, number of acces, ...) for windows or even for VS 2005 (not Team edition) to trace an OSG based program ? Thanks a lot. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to get model scale？
Hi Maybe the camera is only moved and not scaled... try with getTrans(); Vincent. 2008/9/18 forest37 [EMAIL PROTECTED] hi all, When the secne is zoomed in or out ,I want to get the zoom scale.I do it like this: osg::Camera* camera= viewer.getCamera(); osg::Matrix vm=camera-getViewMatrix(); osg::Vec3 scale=vm.getScale(); the result is that scale always equals to (1,1,1).What does this mean and how can I get the reall scale of the scene? thanks best regards forest -- [广告] 买房不必东奔西走，上房老大，看二手房网上房展会http://popme.163.com/link/003984_0909_8679.html ___ 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 get model scale?
if you want to just zoom then adjust the Horizontal field view If you want to scale the scene, parent the scene to a transform and set the scale on the transform ( not the view matrix) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of forest37 Sent: Thursday, September 18, 2008 11:22 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] how to get model scale? hi all, When the secne is zoomed in or out ,I want to get the zoom scale.I do it like this: osg::Camera* camera= viewer.getCamera(); osg::Matrix vm=camera-getViewMatrix(); osg::Vec3 scale=vm.getScale(); the result is that scale always equals to (1,1,1).What does this mean and how can I get the reall scale of the scene? thanks best regards forest [广告] 买房不必东奔西走，上房老大，看二手房网上房展会 http://popme.163.com/link/003984_0909_8679.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to get model scale？
Hi Forest, The Camera simply doesn't have a zoom scale, it just has a view matrix. The zoom is only relevant to specific camera manipulator models that have a concept of zooming - like osgGA::TrackballManipulator and osgGA/TerrainManipulator, so you could get this info directly from these if you are using them. Robert. 2008/9/18 forest37 [EMAIL PROTECTED]: hi all, When the secne is zoomed in or out ,I want to get the zoom scale.I do it like this: osg::Camera* camera= viewer.getCamera(); osg::Matrix vm=camera-getViewMatrix(); osg::Vec3 scale=vm.getScale(); the result is that scale always equals to (1,1,1).What does this mean and how can I get the reall scale of the scene? thanks best regards forest [广告] 买房不必东奔西走，上房老大，看二手房网上房展会 ___ 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] Problems with multi-monitor and DrawThreadPerContext mode
Hi all, First of all, here are the setups I currently use : - 1x GeForce 8600 GTS with 2 monitors - 2x GeForce 8900 GT with 2 monitors (one on each card) The whole installed with Windows XP, the latest OSG version and the latest NVidia drivers. My application use the two screens (a part of the scene is shared by each screen), and I am facing some crashes on the rendering part. Currently if the two rendering threads (I am in DrawThreadPerContext mode) try to compile a display list at the same time, or try to upload a texture to the graphic card, it fails. To avoid it, I need to put mutexes to protect from doing such operations at the same time (it fails with the 2 setups I use). If I use the DrawThreadPerContext mode with only one monitor (but still 2 windows with different contexts), it works without problems. Anyone has already seen such a problem ? Or anyone has some success with multi-monitor on WinXP and NVidia cards ? -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to get model scale？
I'm not entirely sure what you mean by scale of the scene from your message. To me, this is an application concept. The user sets the scale using some user interface, and the application stores this value and modifies the scene graph to redraw the scene at a different size. If your application were set up this way, you would already have the scale and wouldn't need to retrieve it from OSG. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of forest37 Sent: Thursday, September 18, 2008 9:22 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] how to get model scale？ hi all, When the secne is zoomed in or out ,I want to get the zoom scale.I do it like this: osg::Camera* camera= viewer.getCamera(); osg::Matrix vm=camera-getViewMatrix(); osg::Vec3 scale=vm.getScale(); the result is that scale always equals to (1,1,1).What does this mean and how can I get the reall scale of the scene? thanks best regards forest [广告] 买房不必东奔西走，上房老大，看二手房网上房展会 http://popme.163.com/link/003984_0909_8679.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Could you try : osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find shared object error from the loader. And on executing osgdem with no arguments, it simply quits with a segmentation fault error. I also followed the VPB tutorial at http://www.openscenegraph.org/projects/VirtualPlanetBuilder and despite the extra argument inputs I have the same error. So I reckon I must have configured VPB wrong somehow. Is there anything I overlooked? Regards Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with multi-monitor and DrawThreadPerContext mode
Hi Serge, Anyone has already seen such a problem ? Or anyone has some success with multi-monitor on WinXP and NVidia cards ? Search the archives for multi-monitor, Windows XP, NVidia. You'll find extensive discussion in the past few months, with great investigation by Wojtek Lewandowski. But the problem noted then should be worked around by a double MakeCurrent call, so if you're indeed using OSG 2.6+ then perhaps your problem is a different one. Here we use OSG on multi-monitor setups on both XP and Vista and for the most part things work well, though we use the threading mode that OSG chooses for us so I'm not sure it's the same one you use. Sorry I can't help more, 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] [osg-submissions] BUG:osgPlugins\OpenFlight\ExportOptions.cpp
The change is now merged, revision number was . Excellent. I've merged this onto the 2.6 branch. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Hi Ben, Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Yeah, integrated graphics generally don't fare well with FBOs or pbuffers. Hopefully it shouldn't crash though, it should tell you it's not supported and exit... osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. Does Mesa support pbuffers or FBOs? It would be completely software, thus slow, but it might work... osgdem really needs a graphics context to do some of its processing, and in order not to pop up a graphics window it uses pbuffer rendering, so the only other alternative would be to get a better graphics card (though that looks like a laptop so you would probably need to run osgdem on another machine that has one). 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] A couple of Cmake issues with 2.6
found the issue with the cl : Command line warning D9025 : overriding '/Fotg_OpenThreads.dir\Debug\' with '/Fo' cl : Command line error D8016 : '/fp:fast' and '/fp:except' command-line options are incompatible Some command line option were gettng added incorrectly so rjust removing them all solved that Still not sure why I get osg.lib and osgD.lib in my debug linker inputs Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 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 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Thursday, September 18, 2008 11:11 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] A couple of Cmake issues with 2.6 Hi All I'm having a couple of issues with Cmake 2.4 or 2.6 with the 2.6 branch ( I'm a Cmake newbie ) ( no had this with OSG 2. x) CMAKE_INTDIR=\Debug\ CMAKE_INTDIR=\Rlease\ or is being added the preprocessor, and this is causing my link to fail s with errors similar to cl : Command line warning D9025 : overriding '/Fotg_OpenThreads.dir\Debug\' with '/Fo' cl : Command line error D8016 : '/fp:fast' and '/fp:except' command-line options are incompatible If I remove this we link fine Also Every debug projet is getting osg.lib and osgd.lib add to its lib inputs Any ideas on what I screwed up (always blame myself as it normally is my fault ) and how to maybe fix the issues ? Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with multi-monitor and DrawThreadPerContext mode
Hi Serge, Try latest NVidia 177.92 beta drivers. They fixed my latest problems related to multithreaded use. Also may I suggest to stick to --SingleThreaded and --CullDrawThreadPerContext modes while testing ? If everything goes fine then try other threading modes. Default threading mode is DrawThreadPerContext and is usually not a safest one to work with multi-monitor. Wojtek Hi Serge, Anyone has already seen such a problem ? Or anyone has some success with multi-monitor on WinXP and NVidia cards ? Search the archives for multi-monitor, Windows XP, NVidia. You'll find extensive discussion in the past few months, with great investigation by Wojtek Lewandowski. But the problem noted then should be worked around by a double MakeCurrent call, so if you're indeed using OSG 2.6+ then perhaps your problem is a different one. Here we use OSG on multi-monitor setups on both XP and Vista and for the most part things work well, though we use the threading mode that OSG chooses for us so I'm not sure it's the same one you use. Sorry I can't help more, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vanishing Particles
Hmm...I didn't realize you were trying to use a persistent pointer like that; I've been having similar troubles with the color setting ... and have tried a nuber of thing, both sub-classing osg::Particle and osg::ParticleSystem both, each resulting in new problems. If you subclass osg::Particle to MyParticle and add a constant member ID variable with the intent of then iterating over the vector to find specific particles, you suddenly find that the vector is part of osg::ParticleSystem, which thinks it's a vector of osg::Particle and so everything gets messed up. Yup, I don't know the best solution to this sort of problem, but it must be a very common problem. I'll be watching for someone to post a good solution. -Charles On Thu, Sep 18, 2008 at 9:36 AM, b boltze [EMAIL PROTECTED] wrote: Hi Charles, thanks for your guess, but I found the problem already: osgParticle::ParticleSystem is storing its particles in a std::vectorParticle. That means, of course, that pointers to particles may not remain valid all the time. Especially when the vector resizes itself, particles get copied, and hence pointers to them become invalid. I'm not quite sure what to make out of this... essentially it means, that you can not track individual particles over their lifetime, which I definitely need to do for my application. Now I'll go figure out something... bastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with multi-monitor and DrawThreadPerContext mode
Thanks Wojciech for the tip, I'll try the beta drivers, but could you explain why CullDrawThreadPerContext should be safer than DrawThreadPerContext ? On Thu, Sep 18, 2008 at 6:04 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Serge, Try latest NVidia 177.92 beta drivers. They fixed my latest problems related to multithreaded use. Also may I suggest to stick to --SingleThreaded and --CullDrawThreadPerContext modes while testing ? If everything goes fine then try other threading modes. Default threading mode is DrawThreadPerContext and is usually not a safest one to work with multi-monitor. Wojtek Hi Serge, Anyone has already seen such a problem ? Or anyone has some success with multi-monitor on WinXP and NVidia cards ? Search the archives for multi-monitor, Windows XP, NVidia. You'll find extensive discussion in the past few months, with great investigation by Wojtek Lewandowski. But the problem noted then should be worked around by a double MakeCurrent call, so if you're indeed using OSG 2.6+ then perhaps your problem is a different one. Here we use OSG on multi-monitor setups on both XP and Vista and for the most part things work well, though we use the threading mode that OSG chooses for us so I'm not sure it's the same one you use. Sorry I can't help more, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with multi-monitor and DrawThreadPerContext mode
Thanks you very much for this explanation Robert, I better understand it now. As a side note, setting a drawable to DYNAMIC protects it from being modified by the update traversal, but if I remove a drawable (or its geode) from the scene during the update, do I need to set it to DYNAMIC too ? In other words, drawables in STATIC mode are the only ones which are never modified nor removed from the scene ? On Thu, Sep 18, 2008 at 6:24 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Serge, On Thu, Sep 18, 2008 at 5:16 PM, Serge Lages [EMAIL PROTECTED] wrote: Thanks Wojciech for the tip, I'll try the beta drivers, but could you explain why CullDrawThreadPerContext should be safer than DrawThreadPerContext ? A scene graph that has it's Drawable and StateSet DataVariance setup correctly (i.e. DYNAMIC for items that change) should be as stable in DrawThreadPerContext as CullDrawThreadPerContext, but... it's easy to miss them, but if you get crash on the OSG side then this is something to look for. CullDrawThreadPerContext isn't sensitive to DataVariance settings as the cull and draw traversal always finished before Viewer::renderingTraversals() completes, so the main thread that is calling it (or frame) will work single threaded, while DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext will allow the draw thread to overlap with the main thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Hi Ben, This is almost certainly a driver bug. Have a look at the support sits for the Intel hardware to see if there is any reports about problems with pbuffers/FBO's and any fixes that can be applied. In terms of workarounds, osgdem requires a graphics context, so could probably just use a standard graphics window, and it'll actually do this automatically if pbuffers aren't supported, but in your case it looks like GLX is claiming they are supported so OSG/VPB then goes are tries to create one and then it crashes because of a bug in the driver. You could comment out the code that tries pbuffers, this is just a hack though and not something suitable for merging with SVN. The other solution is a hardware one - go buy yourself a cheap Nvidia card, plugin it in, enable the NVidia drivers and you'll be away. You'll get loads of performance, even on load end hardware and driver quality and features are way better. Robert. On Thu, Sep 18, 2008 at 4:53 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Could you try : osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of information. The OSG version is 2.2 and the VPB version is 0.9.1. I am running a Ubuntu Linux 8.04 64bit on an Intel platform, if this is also relevant. The osg installation is straight from the Ubuntu package repository (binary install, as opposed to local rebuild). For building the VPB I added an extra line to the CMakeLists.txt SET(GDAL_INCLUDE_DIR /usr/include/gdal) so osgdem can be compiled. I followed the standard ./configure make sudo make install Everything seemed to be ok. For some reason my OS does not put 64bit libraries in /usr/local/lib64, where the VPB libraries are, so I export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 This stops the cannot find
Re: [osg-users] osgdem segmentation fault
Jean-Sébastien Guay wrote: Hi Ben, Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Yeah, integrated graphics generally don't fare well with FBOs or pbuffers. Hopefully it shouldn't crash though, it should tell you it's not supported and exit... osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. Does Mesa support pbuffers or FBOs? It would be completely software, thus slow, but it might work... osgdem really needs a graphics context to do some of its processing, and in order not to pop up a graphics window it uses pbuffer rendering, so the only other alternative would be to get a better graphics card (though that looks like a laptop so you would probably need to run osgdem on another machine that has one). Correct. This is a laptop. My desktop with a GeForce graphics card just broke a week ago :( and I'm too busy to fix it. But this is completely off-topic. Instead I think I'll just try to hack with the newest release of graphics driver but I really doubt it'd work. The entire X11/GLX stack is very confusing btw. J-S Thanks, Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem segmentation fault
Robert Osfield wrote: Hi Ben, This is almost certainly a driver bug. Have a look at the support sits for the Intel hardware to see if there is any reports about problems with pbuffers/FBO's and any fixes that can be applied. In terms of workarounds, osgdem requires a graphics context, so could probably just use a standard graphics window, and it'll actually do this automatically if pbuffers aren't supported, but in your case it looks like GLX is claiming they are supported so OSG/VPB then goes are tries to create one and then it crashes because of a bug in the driver. You could comment out the code that tries pbuffers, this is just a hack though and not something suitable for merging with SVN. First, thanks for your detailed replies. It really drilled down to the problem source and I am very happy about that. I really don't have the time to do any hacking, not to mention I am an entire novice to OSG and VPB, having been writing OSG apps since a month ago. That said, I'd like to know what are the odds if I try to generate the terrain from another computer but still load it on this machine? That is, does the terrain paging/rendering process touches the pixel buffer part that's known now not working? The other solution is a hardware one - go buy yourself a cheap Nvidia card, plugin it in, enable the NVidia drivers and you'll be away. You'll get loads of performance, even on load end hardware and driver quality and features are way better. As I mentioned in my reply to Guay, that this machine is a laptop so the hardware replacement option is negative. The best I can do now is to research for hopefully bug fixes in my graphics driver. Robert. Thanks, Ben On Thu, Sep 18, 2008 at 4:53 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, The stack trace suggests a problems with pbuffers, which could well be a GLX/OpenGL driver bug. What hardware and OpenGL drivers are you working with? Hardware: Intel Integrated Graphics G965 Driver: The Intel graphics driver (intelfb.ko) OS Kernel: Linux 2.6.24, if this matters. Could you try : osgprerender cow.osg --pbuffer. This results in segmentation fault. Even without the --pbuffer option it results in segmentation fault. So yes sorry for bothering you much Rob. It is not a osgdem bug. However, it will be great if you can suggest a workaround or solution. As for compiling from source it should just be a case of : cd OpenSceneGraph ./configure make sudo make install The paths to the plugins should just work automatically. If you don't install in standard system directory then you'd need to use LD_LIBRARY_PATH to the point to the parent directory of the plugins directory. VPB 1.0 will be released against OSG-2.8, which obviously isn't out yet... perhaps by end of October it'll be ready. Prior to that VPB 0.9.9+ and the 1.0 pre releases will map to OSG-2.7.x dev releases. Robert. On Thu, Sep 18, 2008 at 2:35 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, Thanks for the extra info. The segfault without any options suggests a build issue or link issue of some kind. Could you provide the stack trace? Sure, the core file reads #0 0x7fa215d13af2 in ?? () from /usr/lib/libGL.so.1 #1 0x7fa216c730d9 in osgViewer::PixelBufferX11::init () from /usr/lib/libosgViewer.so.6 #2 0x7fa216c73788 in osgViewer::PixelBufferX11::PixelBufferX11 () from /usr/lib/libosgViewer.so.6 #3 0x7fa216c6fd27 in X11WindowingSystemInterface::createGraphicsContext () from /usr/lib/libosgViewer.so.6 #4 0x0040ae91 in main () It seems it's more of a OSG/OpenGL problem than a osgdem related one. But I have been writing a few OSG apps and they don't seem to have any segfault problems. If it is in fact non-osgdem related, you have my apology. VPB and OSG have come along way since 0.9.1 and OSG-2.2 respectively, and this week I'll be make dev releases for both VPB and OSG that will be matched so these would be a good place to move up to. VPB itself is pretty near its 1.0 status, just a few more weeks left development wise. The only reason I didn't installed the lastest VPB is that I don't want to rebuild OSG from source. I tried, but despite my best effort to set environment variables I could't get it to load plug-ins. As my project deadline is closing in I'd play safe with the working 2.2 OSG installation. I will give OSG2.6 / VPN1.0 a shot once my project is over. Robert. Thanks, Ben On Wed, Sep 17, 2008 at 2:58 PM, benben [EMAIL PROTECTED] wrote: Robert Osfield wrote: Hi Ben, I'm afraid there is wy too little info about your setup to provide any real guidance. VPB should just compile against an installed OSG without need for configuration. You don't mention which VPB or OSG version your are using, you also make no mention of the platform or compilers. All this is important to understanding what might go wrong and how to fix it. Sorry for the lack of
Re: [osg-users] Problems with multi-monitor and DrawThreadPerContext mode
Hi Serge, On Thu, Sep 18, 2008 at 5:16 PM, Serge Lages [EMAIL PROTECTED] wrote: Thanks Wojciech for the tip, I'll try the beta drivers, but could you explain why CullDrawThreadPerContext should be safer than DrawThreadPerContext ? A scene graph that has it's Drawable and StateSet DataVariance setup correctly (i.e. DYNAMIC for items that change) should be as stable in DrawThreadPerContext as CullDrawThreadPerContext, but... it's easy to miss them, but if you get crash on the OSG side then this is something to look for. CullDrawThreadPerContext isn't sensitive to DataVariance settings as the cull and draw traversal always finished before Viewer::renderingTraversals() completes, so the main thread that is calling it (or frame) will work single threaded, while DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext will allow the draw thread to overlap with the main thread. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera control and view matrix
Hi, Robert. You've said: As for examples of manage the view matrix, there should be examples in the archives, but in the end it all boils down to not using a CameraManipulator and instead calling on each frame: viewer.getCamera()-setViewMatrix(viewMatrix); How do I stop using the default camera manipulator, that I believe is TrackballManipulator? Thanks. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera control and view matrix
I believe it's just a simple matter of commenting the manipulator out where you call viewer-setCameraManipulator(). That's what I do when I want explicit control of the camera via my own view matrix... -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renan Mendes Sent: Thursday, September 18, 2008 11:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Camera control and view matrix Hi, Robert. You've said: As for examples of manage the view matrix, there should be examples in the archives, but in the end it all boils down to not using a CameraManipulator and instead calling on each frame: viewer.getCamera()-setViewMatrix(viewMatrix); How do I stop using the default camera manipulator, that I believe is TrackballManipulator? Thanks. Renan M Z Mendes smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera control and view matrix
Hi Renan, The osgViewer::Viewer by default doesn't have any camera manipulators attached, but... if you call run without attaching a camera manipultor then it'll add a TrackballManipulator as a fallback to make the view usable. If you are controlling the view matrix from your own frame loop then you won't be calling run() so you won't have any CamerManipulator attached unless you go add one yourself. Robert. On Thu, Sep 18, 2008 at 6:39 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, Robert. You've said: As for examples of manage the view matrix, there should be examples in the archives, but in the end it all boils down to not using a CameraManipulator and instead calling on each frame: viewer.getCamera()-setViewMatrix(viewMatrix); How do I stop using the default camera manipulator, that I believe is TrackballManipulator? Thanks. Renan M Z Mendes ___ 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] Camera control and view matrix
Hi Renan, Thanks for the link, I'll update it tomorrow, unless some kindly soul gets to it before me :-) Robert. On Thu, Sep 18, 2008 at 5:36 PM, Renan Mendes [EMAIL PROTECTED] wrote: Robert, The page I'm talking about that still references osg::Producer is http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControl. Basically, all pages related to camera control tutorials. It even has a wiki editing note about this. Renan M Z Mendes ___ 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] Camera control and view matrix
Grepping the osgViewer source for TrackballManipulator should reveal that you only get one by default if you call Viewer::run(). Don't call that, instead call Viewer::done() and Viewer::frame(). Then you won't get a default camera manipulator. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renan Mendes Sent: Thursday, September 18, 2008 11:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Camera control and view matrix Hi, Robert. You've said: As for examples of manage the view matrix, there should be examples in the archives, but in the end it all boils down to not using a CameraManipulator and instead calling on each frame: viewer.getCamera()-setViewMatrix(viewMatrix); How do I stop using the default camera manipulator, that I believe is TrackballManipulator? Thanks. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] loading vrml segfault
When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that causes the segfault, as well as the same file with some minor changes to make it run properly. The segfault happens inside: osgDB::readNodeFile(filename). It would be great if OSG could detect the error, and return properly with an invalid node. But I understand if the fault is inside of OpenVRML. Thanks, -Ben vrmltest.tar.bz2 Description: vrmltest.tar.bz2 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Adding code for movie textures
I've been trying to find a way to get movie textures to play using only a
.osg file as the input to osgviewer. From skulking around in the source
code I figured out how osgviewer --movie plays movies on a polygon and
took that idea and applied it to the texture handling source files in
osgPlugins/osg.
I added the following code to Texture1D.cpp, Texture2D.cpp, Texture3D.cpp
and TextureRectangle.cpp:
#include osg/ImageStream
if (fr[0].matchWord(movie) fr[1].isString())
{
std::string filename = fr[1].getStr();
Image* image = fr.readImage(filename.c_str());
ImageStream* imagestream = dynamic_castosg::ImageStream*(image);
if (imagestream) {
texture.setImage(imagestream);
imagestream-play();
}
}
So far it's worked. Is this something that's going to work out in the
long run? Is there a better way for me to do what I've done?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgCairo, osgPango
Hi all, especially Jeremy :-) I've been looking forward to trying out osgCairo for a while now, and now that osgPango has been released (at least in its first version), I figured I'd give it a try. Unfortunately, it looks like it will be a bit difficult to get them to compile on Windows, because the CMake scripts want to use pkg-config to find cairo, pango and pangocairo, but no such thing exists on Win32 (unless using MinGW or cygwin I imagine...). And there are no FindPango or FindCairo scripts that ship with CMake itself which I could use, either. Before I go about writing my own, has anyone tried to compile these nodekits on Windows? Oh, and CMake complains that there should be a CMAKE_MINIMUM_REQUIRED(VERSION 2.x.y) line at the top of the CMakeLists.txt files (for example, 2.4.7 should work). Thanks in advance, 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] osgCairo, osgPango
Hi Jeremy, In the hope that my wandering will help someone in the future... Incidentally, I thought this info would be useful to other potential users of your nodekits on Windows, but I can't find an add page button for the wiki on osgpango.googlecode.org... Do new pages need to be added by the project administrator? 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
[osg-users] head intact
___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer, update traversal, prerender branch
Hi everybody, Ive got some problems with displaying the result of a prerender step in different views. The root node has two basic branches: a prerender branch that renders and processes a live camera image, and a main render branch, that has two subnodes. The output texture of the prerender step is applied to the subnodes in different ways. A View is set to each subnode to display the specific view of the scene. A third View is set to the root node to observe the overall behavior of the texture (applied to both subnodes). The problem is, that the Texture gets updated in the overall view, but not in the subnode views (it shows the initialised static texture, not even the updated camera image). When I set the scene data of the subnode views to the root, the texture gets updated, but the framerate drops. When i assign no View to the scene root, the prerender branch isnt traversed at allAs far as i know, the update traversal is called once per frame for a composite viewer, that should update the texture in all nodes. Please help me with that one. Cheers, Fabian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
