[osg-users] smooth layer transistion?
Hi, I have created a terrain DB with different resolution images covering same area. As and when the region is zoomed in, there is transistion from poor resolution image to higher resolution image. The transition is quite visible. Means that at particular level the entire poor resolution tile disappears and next layer is brought up. I would like it to happen so smoothly. Whether do I have to set mipmap filter to acquire such smooth transition? Thank you! Cheers, Akilan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19468#19468 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Tim, On Tue, Nov 10, 2009 at 5:23 PM, Tim Moore timo...@redhat.com wrote: If you want to customize culling for a node that is a subclass of osg::Geode, you pretty much need to write your own cull visitor and override CullVisitor::apply(Geode); the low-level code that puts geometry into the render graph is contained in that function and is called after the traverse() function of the node class. osg::Geode is presently a bit of special case as it's the leaf node, all is not lost, you still have different techniques that can help avoid needing to subclassing CullVisitor. First up, the osg::Drawable have their own cull callback so if you want to change the culling on a Geode's drawables then you can place the cull callback on them. Another approach you can take is to subclass from osg::Node and mirror the osg::Geode behavour of managing it's own Drawables, and then in a custom traverse method you do the culling as your desire and adding the Drawables into the CullVisitor directly. Both of these approaches have the advantage that they work on any viewer, and you don't have to grapple with the overriding the default CullVisitor. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Notify log archive creation
Hi Ernest, 2009/11/10 Ernesto de la Cruz Guevara Ramírez elguev...@uci.cu: Hi all there, People I´m new to OSG I´m trying to use it wit QT framework and ARToolKit to develop my first Augmented Reality application. First I have integrated OSG ARToolKit and QT quite good, I saw the live video stream from my webcam, but when I tried to add marker detection the application close without any message. Then I need to know how to redirect osg::Notify messages to a log archive to know what is happening with my application. You have a couple of different options, in svn/trunk there is now support for writing your own NotifyHandler, but with OSG-2.8.x and prior you'll need to take the notify() stream and attach your own custom streambuffer to reidirect the output. Or... just run your app in the console and redirect the output to a file - this is what I do for debug work. i.e. osgviewer cow.osg output.txt Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multisampling in embedded window?
Hi Raphael I have exactly the same problem, how did you solve it? Thanks a lot in advance Dominic -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19471#19471 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GraphicsWindowWin32: InheritCursor problems
Hello. I need to use custom cursors. To do that I use InheritCursor, this solution works when I use embedded window which not receive WM_NCHITTEST message. But when I try to use this solution with osg own window it not works, because when WM_NCHITTEST message received, _mouseCursor changes from InheritCursor and then WM_SETCURSOR message handler work incorrect. Mikhail. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with QGLWidget and Anti Aliasing
Sorry, searched on the wrong framework. I could solve the problem in Qt itself: QGLFormat fmt; QGLFormat::setDefaultFormat(fmt); fmt.setSamples(4); fmt.setSampleBuffers(true); qglwidget-setFormat(fmt); Hi there I am absolutly new to the OSG stuff (and it's the first time I attend in a mailing list) and trying to get my OSG work in a Qt environment. I made my own OSG/Qt class, which inherits from QGLWidget and osgViewer::Viewer. Most of the OSG stuff works, but I can't enable the anti aliasing or the multi sampling. I tried the following two configurations: 1. ref_ptr DisplaySettings displaySettings = new DisplaySettings; displaySettings-setNumMultiSamples(16); modelView-setDisplaySettings( displaySettings.get() ); 2. osg::DisplaySettings::instance()-setNumMultiSamples(8); But this didn't work. Does anybody had the same problems or have some ideas to solve this problem. I attached my class and header files. If I'm doing something wrong concerning the mailing list rules, just let me know. Thanks a lot and regards Dominic ___ 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] Announcing osgWorks and osgBullet
Hi Paul, Lovely work! I assume that for now, independent threading for the physics is handled only by the multi-threaded Bullet library, is this correct? I couldn't find in the source any place using the PhysicsThreading class, are you going to use it in the future? I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. Regards, Alberto Paul Martz writes: Hi all -- I'm pleased to announce two new open source OSG-based projects, osgWorks and osgBullet, licensed under LGPL. These are active projects with discussion groups, source downloads, wiki, and issue tracking. They are actively used by the open source VE-Suite application. They were funded by Ames Laboratory and created primarily by myself / Skew Matrix Software. osgWorks is a set of applications and software tools useful to OSG software developers. It features a set of command line analysis tools, a library with utility functions and NodeVisitors for things like screen capture, scene graph comparison, and polygon decimation, and plugins to support .OSG and hierarchical structure storage. For more information on osgWorks and to download the source, visit: http://osgworks.vesuite.org osgBullet is a set of software tools for applications that use both OSG and the Bullet physics library. It features utilities to create Bullet collision shapes from OSG data and vice versa, run the physics simulation in a separate host thread, debug utilities to display Bullet collision shapes in an OSG scene, support for arbitrary scaling and center of mass, and support for COLLADA. For more information on osgBullet and to download the source, visit: http://osgbullet.vesuite.org For questions, please either post here or to the project discussion groups hosted on Google Groups. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi everyone! This is a tough one. I'm now certain that there is more than one bug at large here! At least one in the pager (the one mentioned in the PagedLOD experts thread) and at least one in the txp plugin. The one I have been chasing for the past 2 days is within the txp plugin and looks more like a design issue than a bug. I don't think the txp plugin was designed with multiple cameras in mind! The TXPNode (the top level node when loading a .txp archive) updates the camera position in _pageManager on every cull visit (through updateEye). Since there is one cull visit per camera per frame, the page manager position jumps between multiple positions every frame. Every time the position changes, the set of LOD0 nodes is reconsidered. This results in multiple cameras fighting over which set of LOD0 nodes should be present. Note that LOD0 nodes, or blocks, become children of the TXPNode in the update stage. At some point, a state is achieved in which a certain number of nodes end up on the _nodesToAdd list and the same amount of nodes end up on the _nodesToRemove list. Unfortunately, some of the nodes on the remove list are not actually in the _children list, so the net result is that more nodes are added than removed. This happens every frame, so the number of children of the TXPNode increases indefinitely. Since these children are PagedLOD nodes, they, in turn, also start loading in children until all memory is exhausted. It seems to me as though a major overhaul is needed for the txp plugin to be able to handle multiple cameras. As I mentioned earlier, one workaround is to make sure that each TXPNode is only visited by one camera - for instance by loading the terrain anew for each camera. Cheers, Michael [/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19476#19476 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Problem with Collada-dom
Hi guys, Thanks for your help. I am having some problems with the installation of Collada-dom. I am trying to install in my computer with Linux. When I execute this line make -f Makefile.linux, it starts to compile but at the end it generates the next error: make[1]: Entering directory `/home/caba/collada-dom/rt' Compiling src/Crt/1.4/CrtSceneRead.cpp to build/linux-1.4/obj/CrtSceneRead.o In file included from include/1.4/Crt/CrtScene.h:11, from src/Crt/1.4/CrtSceneRead.cpp:15: include/Crt/CrtAnimation.h:23: error: ‘string’ was not declared in this scope include/Crt/CrtAnimation.h:23: error: template argument 1 is invalid include/Crt/CrtAnimation.h:23: error: template argument 3 is invalid include/Crt/CrtAnimation.h:23: error: template argument 4 is invalid include/Crt/CrtAnimation.h:231: error: ‘string’ was not declared in this scope include/Crt/CrtAnimation.h:231: error: template argument 1 is invalid include/Crt/CrtAnimation.h:231: error: template argument 3 is invalid include/Crt/CrtAnimation.h:231: error: template argument 4 is invalid include/Crt/CrtAnimation.h:232: error: ‘string’ was not declared in this scope include/Crt/CrtAnimation.h:232: error: template argument 1 is invalid include/Crt/CrtAnimation.h:232: error: template argument 3 is invalid include/Crt/CrtAnimation.h:232: error: template argument 4 is invalid In file included from include/Crt/CrtSkin.h:16, from include/Crt/CrtGeometry.h:11, from include/1.4/Crt/CrtScene.h:15, from src/Crt/1.4/CrtSceneRead.cpp:15: include/Crt/CrtController.h:45: error: ‘string’ was not declared in this scope include/Crt/CrtController.h:45: error: template argument 1 is invalid include/Crt/CrtController.h:45: error: template argument 2 is invalid In file included from ../fx/include/cfxPlatform.h:17, from ../fx/include/cfxSurface.h:15, from ../fx/include/cfxEffect.h:26, from ../fx/include/cfxLoader.h:25, from include/Crt/CrtGeometry.h:16, from include/1.4/Crt/CrtScene.h:15, from src/Crt/1.4/CrtSceneRead.cpp:15: ../fx/include/cfxLinux.h: In function ‘void cfxPrint(const char*, ...)’: ../fx/include/cfxLinux.h:39: warning: format not a string literal and no format arguments In file included from external-libs/bullet/include/btBulletCollisionCommon.h:26, from external-libs/bullet/include/btBulletDynamicsCommon.h:20, from include/Crt/CrtPhysics.h:20, from include/1.4/Crt/CrtScene.h:24, from src/Crt/1.4/CrtSceneRead.cpp:15: external-libs/bullet/include/BulletCollision/CollisionShapes/btBoxShape.h: In member function ‘virtual char* btBoxShape::getName() const’: external-libs/bullet/include/BulletCollision/CollisionShapes/btBoxShape.h:255: warning: deprecated conversion from string constant to ‘char*’ In file included from external-libs/bullet/include/btBulletCollisionCommon.h:27, from external-libs/bullet/include/btBulletDynamicsCommon.h:20, from include/Crt/CrtPhysics.h:20, from include/1.4/Crt/CrtScene.h:24, from src/Crt/1.4/CrtSceneRead.cpp:15: external-libs/bullet/include/BulletCollision/CollisionShapes/btSphereShape.h: In member function ‘virtual char* btSphereShape::getName() const’: external-libs/bullet/include/BulletCollision/CollisionShapes/btSphereShape.h:46: warning: deprecated conversion from string constant to ‘char*’ In file included from external-libs/bullet/include/btBulletCollisionCommon.h:28, from external-libs/bullet/include/btBulletDynamicsCommon.h:20, from include/Crt/CrtPhysics.h:20, from include/1.4/Crt/CrtScene.h:24, from src/Crt/1.4/CrtSceneRead.cpp:15: external-libs/bullet/include/BulletCollision/CollisionShapes/btCapsuleShape.h: In member function ‘virtual char* btCapsuleShape::getName() const’: external-libs/bullet/include/BulletCollision/CollisionShapes/btCapsuleShape.h:43: warning: deprecated conversion from string constant to ‘char*’ In file included from external-libs/bullet/include/btBulletCollisionCommon.h:29, from external-libs/bullet/include/btBulletDynamicsCommon.h:20, from include/Crt/CrtPhysics.h:20, from include/1.4/Crt/CrtScene.h:24, from src/Crt/1.4/CrtSceneRead.cpp:15: external-libs/bullet/include/BulletCollision/CollisionShapes/btCylinderShape.h: In member function ‘virtual char* btCylinderShape::getName() const’: external-libs/bullet/include/BulletCollision/CollisionShapes/btCylinderShape.h:83: warning: deprecated conversion from string constant to ‘char*’ external-libs/bullet/include/BulletCollision/CollisionShapes/btCylinderShape.h: In member function ‘virtual char* btCylinderShapeX::getName() const’:
Re: [osg-users] Problem with DOF Nodes
Hi Robert, I could make it with Callbacks. Thank you very much for your help. Cheers, Felipe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19478#19478 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
You might want to check svn because I filed a bug about the lack of BulletMultiThreaded on x86_64 causing a few build errors in various places in the source code several months ago and recently they closed the report saying BulletMultiThreaded now builds on x86_64. On Wed, Nov 11, 2009 at 6:49 AM, Alberto Luaces alua...@udc.es wrote: Hi Paul, Lovely work! I assume that for now, independent threading for the physics is handled only by the multi-threaded Bullet library, is this correct? I couldn't find in the source any place using the PhysicsThreading class, are you going to use it in the future? I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. Regards, Alberto Paul Martz writes: Hi all -- I'm pleased to announce two new open source OSG-based projects, osgWorks and osgBullet, licensed under LGPL. These are active projects with discussion groups, source downloads, wiki, and issue tracking. They are actively used by the open source VE-Suite application. They were funded by Ames Laboratory and created primarily by myself / Skew Matrix Software. osgWorks is a set of applications and software tools useful to OSG software developers. It features a set of command line analysis tools, a library with utility functions and NodeVisitors for things like screen capture, scene graph comparison, and polygon decimation, and plugins to support .OSG and hierarchical structure storage. For more information on osgWorks and to download the source, visit: http://osgworks.vesuite.org osgBullet is a set of software tools for applications that use both OSG and the Bullet physics library. It features utilities to create Bullet collision shapes from OSG data and vice versa, run the physics simulation in a separate host thread, debug utilities to display Bullet collision shapes in an OSG scene, support for arbitrary scaling and center of mass, and support for COLLADA. For more information on osgBullet and to download the source, visit: http://osgbullet.vesuite.org For questions, please either post here or to the project discussion groups hosted on Google Groups. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Notify log archive creation
Hi, Robert I'm using OSG 2.8.0 but the osgART Plugin I have at this moment is compiled without debug information, that's why I'm trying to redirect messages through osg::notify(). I think to take the first option you pointed out that: I'll need to take the notify() stream and attach my own custom streambuffer to reidirect the output since I tried to redirect console messages without success because of the app is writen for a QT project in release mode. Finally wether I can't to know the error I'll need to drag down the code and recompile the plugin with debug information. Thanks for your soon reply. Cheers, Ernesto -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19480#19480 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Hi Philip, what build system are you using? The most recent svn version of Bullet says in src/CMakeLists.txt: $ head CMakeLists.txt if (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletSoftBody BulletCollision BulletDynamics LinearMath ) else (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletMultiThreaded BulletSoftBody BulletCollision BulletDynamics LinearMath ) endif (CMAKE_SIZEOF_VOID_P MATCHES 8) Regards, Alberto Philip Lowman writes: You might want to check svn because I filed a bug about the lack of BulletMultiThreaded on x86_64 causing a few build errors in various places in the source code several months ago and recently they closed the report saying BulletMultiThreaded now builds on x86_64. On Wed, Nov 11, 2009 at 6:49 AM, Alberto Luaces alua...@udc.es wrote: Hi Paul, Lovely work! I assume that for now, independent threading for the physics is handled only by the multi-threaded Bullet library, is this correct? I couldn't find in the source any place using the PhysicsThreading class, are you going to use it in the future? I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. Regards, Alberto Paul Martz writes: Hi all -- I'm pleased to announce two new open source OSG-based projects, osgWorks and osgBullet, licensed under LGPL. These are active projects with discussion groups, source downloads, wiki, and issue tracking. They are actively used by the open source VE-Suite application. They were funded by Ames Laboratory and created primarily by myself / Skew Matrix Software. osgWorks is a set of applications and software tools useful to OSG software developers. It features a set of command line analysis tools, a library with utility functions and NodeVisitors for things like screen capture, scene graph comparison, and polygon decimation, and plugins to support .OSG and hierarchical structure storage. For more information on osgWorks and to download the source, visit: http://osgworks.vesuite.org osgBullet is a set of software tools for applications that use both OSG and the Bullet physics library. It features utilities to create Bullet collision shapes from OSG data and vice versa, run the physics simulation in a separate host thread, debug utilities to display Bullet collision shapes in an OSG scene, support for arbitrary scaling and center of mass, and support for COLLADA. For more information on osgBullet and to download the source, visit: http://osgbullet.vesuite.org For questions, please either post here or to the project discussion groups hosted on Google Groups. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ 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] Would someone be willing to help me diagnose a performance issue?
Hi Frank, However, in the Slow App, there's actually a Model class of our own making, that has an osg::Group* member that stores a reference to the model's parent node, and an osg::MatrixTransform* that stores a reference to the model's Matrix Transform. The constructor of this class follows the same basic steps I outlined above, in order to wire everything together, but it's possible that I'm overlooking something amongst the added complexity. That might be the case - encapsulation is a powerful tool but it sometimes inadvertently hides important details... (or makes them less obvious) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] Would someone be willing to help me diagnose a performance issue?
Hi Frank, So, I think that about wraps it up! Thanks to everyone for your help. Great, good to know you've found one of the culprits! I'd still encourage you to review your hierarchy to facilitate OSG's culling, but as long as your objectives are met, it's probably not that critical for now. :-) As Robert once said, when optimizing, check if you get a solid 60Hz, if so then go have a beer :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Hi Wyatt, When I have one or two objects, say the size of a car, or truck, only. The shadow map looks correct. But when I add my terrain which is approximately x = 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map. Similarly, if I increase the length and width of the bottom box in the osgShadow example, I no longer see the other objects in the shadow map. I assume I am running into some shadow map texture resolution limit or something. What is going on? Yep, Most probable. osgShadow::ShadowMap can't help you there, but there are a few things you can do to mitigate the problem. * First, don't set your terrain to cast shadow (if it's mostly flat you'd never see its shadow anyways) * Second, make sure all the objects you set to cast shadow are in a small area. If an object leaves the area of focus, remove its cast shadow bit from its node mask. * Third, increase the shadow map resolution as much as you can (on some cards, 4096x4096 is the biggest you can go, on some others it's 2048x2048) But if you want better results, switch to one of the ViewDependentShadow techniques that are in OSG 2.8+ (for example osgShadow::LightSpacePerspectiveShadowMap). These will consider the camera's view volume and only calculate shadows for this area automatically, so if you're looking at a relatively small portion of your scene it will give much better results. Though they have some artifacts in some situations too... Nothing is perfect, it's always a trade-off. My shadow map is looking mostly correct now after making changes to light type, position etc. However shadows are not appearing in the final rendering. The app I am trying to add shadow mapping to uses textures bound to tex units 0-3. I noticed in the ShadowMap class there were methods for setting the texture unit and wondered if this possibly why I am not seeing the shadows. That is, is my use of tex units 0-3 conflicting with ShadowMaps use of texture units and should I reassign one or the others texture units? Most probably, ShadowMap uses texture unit 1 by default for the shadow map. Call osgShadow::ShadowMap::setTextureUnit() to set the texture unit you want the shadow map to use (for example 4, or 7 to give yourself some breathing room), and use that same texture unit in your shadow shaders when you get to the point of generating texture coordinates and doing the shadow lookup too. There's a similar method in osgShadow::LightSpacePerspectiveShadowMap. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Yes this all helps greatly.. I really appreciate the help you have provided. Thanks, W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, November 11, 2009 8:04 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Hi Wyatt, When I have one or two objects, say the size of a car, or truck, only. The shadow map looks correct. But when I add my terrain which is approximately x = 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map. Similarly, if I increase the length and width of the bottom box in the osgShadow example, I no longer see the other objects in the shadow map. I assume I am running into some shadow map texture resolution limit or something. What is going on? Yep, Most probable. osgShadow::ShadowMap can't help you there, but there are a few things you can do to mitigate the problem. * First, don't set your terrain to cast shadow (if it's mostly flat you'd never see its shadow anyways) * Second, make sure all the objects you set to cast shadow are in a small area. If an object leaves the area of focus, remove its cast shadow bit from its node mask. * Third, increase the shadow map resolution as much as you can (on some cards, 4096x4096 is the biggest you can go, on some others it's 2048x2048) But if you want better results, switch to one of the ViewDependentShadow techniques that are in OSG 2.8+ (for example osgShadow::LightSpacePerspectiveShadowMap). These will consider the camera's view volume and only calculate shadows for this area automatically, so if you're looking at a relatively small portion of your scene it will give much better results. Though they have some artifacts in some situations too... Nothing is perfect, it's always a trade-off. My shadow map is looking mostly correct now after making changes to light type, position etc. However shadows are not appearing in the final rendering. The app I am trying to add shadow mapping to uses textures bound to tex units 0-3. I noticed in the ShadowMap class there were methods for setting the texture unit and wondered if this possibly why I am not seeing the shadows. That is, is my use of tex units 0-3 conflicting with ShadowMaps use of texture units and should I reassign one or the others texture units? Most probably, ShadowMap uses texture unit 1 by default for the shadow map. Call osgShadow::ShadowMap::setTextureUnit() to set the texture unit you want the shadow map to use (for example 4, or 7 to give yourself some breathing room), and use that same texture unit in your shadow shaders when you get to the point of generating texture coordinates and doing the shadow lookup too. There's a similar method in osgShadow::LightSpacePerspectiveShadowMap. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] Announcing osgWorks and osgBullet
Was using the CMake build but am not tracking svn at the moment. Perhaps this thread will help? bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=4238 On Nov 11, 2009 8:36 AM, Alberto Luaces alua...@udc.es wrote: Hi Philip, what build system are you using? The most recent svn version of Bullet says in src/CMakeLists.txt: $ head CMakeLists.txt if (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletSoftBody BulletCollision BulletDynamics LinearMath ) else (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletMultiThreaded BulletSoftBody BulletCollision BulletDynamics LinearMath ) endif (CMAKE_SIZEOF_VOID_P MATCHES 8) Regards, Alberto Philip Lowman writes: You might want to check svn because I filed a bug about the lack of Bullet... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Definitely there is no support for BulletMultiThreaded in 64 bits at the moment. From the last post in the forum thread you gave to me: BulletMultiThreaded, MultiThreadedDemo, Gpu2dDemo, Gpu3dDemo are not supported on 64bit platforms. It was accidently enabled in a previous revision, but now it has been disabled in the trunk. If you can make any of this work on 64 platforms, please consider contributing it. Regards, Alberto Philip Lowman writes: Was using the CMake build but am not tracking svn at the moment. Perhaps this thread will help? bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=4238 On Nov 11, 2009 8:36 AM, Alberto Luaces wrote: Hi Philip, what build system are you using? The most recent svn version of Bullet says in src/CMakeLists.txt: $ head CMakeLists.txt if (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletSoftBody BulletCollision BulletDynamics LinearMath ) else (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletMultiThreaded BulletSoftBody BulletCollision BulletDynamics LinearMath ) endif (CMAKE_SIZEOF_VOID_P MATCHES 8) Regards, Alberto Philip Lowman writes: You might want to check svn because I filed a bug about the lack of Bullet... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
BTW, 2 more questions 1. Is there a way I can query the number of texture units available on my GPU via an OSG call? 2. Is there a list, other than the osgShadow programming guide of shadowmap techniques, specifically ViewDependentShadow techniques? W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, November 11, 2009 8:04 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap problem... Hi Wyatt, When I have one or two objects, say the size of a car, or truck, only. The shadow map looks correct. But when I add my terrain which is approximately x = 5100 by y = 5100, I no longer see the car/truck shadows on the shadow map. Similarly, if I increase the length and width of the bottom box in the osgShadow example, I no longer see the other objects in the shadow map. I assume I am running into some shadow map texture resolution limit or something. What is going on? Yep, Most probable. osgShadow::ShadowMap can't help you there, but there are a few things you can do to mitigate the problem. * First, don't set your terrain to cast shadow (if it's mostly flat you'd never see its shadow anyways) * Second, make sure all the objects you set to cast shadow are in a small area. If an object leaves the area of focus, remove its cast shadow bit from its node mask. * Third, increase the shadow map resolution as much as you can (on some cards, 4096x4096 is the biggest you can go, on some others it's 2048x2048) But if you want better results, switch to one of the ViewDependentShadow techniques that are in OSG 2.8+ (for example osgShadow::LightSpacePerspectiveShadowMap). These will consider the camera's view volume and only calculate shadows for this area automatically, so if you're looking at a relatively small portion of your scene it will give much better results. Though they have some artifacts in some situations too... Nothing is perfect, it's always a trade-off. My shadow map is looking mostly correct now after making changes to light type, position etc. However shadows are not appearing in the final rendering. The app I am trying to add shadow mapping to uses textures bound to tex units 0-3. I noticed in the ShadowMap class there were methods for setting the texture unit and wondered if this possibly why I am not seeing the shadows. That is, is my use of tex units 0-3 conflicting with ShadowMaps use of texture units and should I reassign one or the others texture units? Most probably, ShadowMap uses texture unit 1 by default for the shadow map. Call osgShadow::ShadowMap::setTextureUnit() to set the texture unit you want the shadow map to use (for example 4, or 7 to give yourself some breathing room), and use that same texture unit in your shadow shaders when you get to the point of generating texture coordinates and doing the shadow lookup too. There's a similar method in osgShadow::LightSpacePerspectiveShadowMap. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] std::vector instances from osg::geode derived class error
Hi,
I'm trying to instanciate TGWidgetElement with a std::vector, which derives
from osg::geode with a std::vector but it gives following errors.
--
Compiler Output:
In file included from /usr/include/osg/Group:17,
from TGBaseWidget.hpp:11,
from TGBaseWidget.cpp:1:
/usr/include/osg/Node:60: instantiated from ‘void std::vector_Tp,
_Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , const _Tp) [with _Tp = TGWidgetElement, _Alloc =
std::allocatorTGWidgetElement]’
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void
std::vector_Tp, _Alloc::push_back(const _Tp) [with _Tp = TGWidgetElement,
_Alloc = std::allocatorTGWidgetElement]’
TGBaseWidget.cpp:64: instantiated from here
/usr/include/osg/Object:169: error: ‘osg::Object osg::Object::operator=(const
osg::Object)’ is private
/usr/include/osg/Node:60: error: within this context
/usr/include/osg/Geode: In member function ‘osg::Geode
osg::Geode::operator=(const osg::Geode)’:
In file included from /usr/include/osgDB/SharedStateManager:19,
from /usr/include/osgDB/DatabasePager:29,
from /usr/include/osgDB/Registry:26,
from /usr/include/osgDB/ReadFile:24,
from TGWidgetElement.hpp:15,
from TGBaseWidget.hpp:12,
from TGBaseWidget.cpp:1:
/usr/include/osg/Geode:29: instantiated from ‘void std::vector_Tp,
_Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , const _Tp) [with _Tp = TGWidgetElement, _Alloc =
std::allocatorTGWidgetElement]’
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void
std::vector_Tp, _Alloc::push_back(const _Tp) [with _Tp = TGWidgetElement,
_Alloc = std::allocatorTGWidgetElement]’
TGBaseWidget.cpp:64: instantiated from here
/usr/include/osg/Geode:29: note: synthesized method ‘osg::Node
osg::Node::operator=(const osg::Node)’ first required here
TGWidgetElement.hpp: In member function ‘TGWidgetElement
TGWidgetElement::operator=(const TGWidgetElement)’:
In file included from TGBaseWidget.hpp:12,
from TGBaseWidget.cpp:1:
TGWidgetElement.hpp:19: instantiated from ‘void std::vector_Tp,
_Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , const _Tp) [with _Tp = TGWidgetElement, _Alloc =
std::allocatorTGWidgetElement]’
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void
std::vector_Tp, _Alloc::push_back(const _Tp) [with _Tp = TGWidgetElement,
_Alloc = std::allocatorTGWidgetElement]’
TGBaseWidget.cpp:64: instantiated from here
TGWidgetElement.hpp:19: note: synthesized method ‘osg::Geode
osg::Geode::operator=(const osg::Geode)’ first required here
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector_Tp,
_Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , const _Tp) [with _Tp = TGWidgetElement, _Alloc =
std::allocatorTGWidgetElement]’:
In file included from /usr/include/c++/4.4/vector:69,
from /usr/include/osg/StateAttribute:23,
from /usr/include/osg/StateSet:18,
from /usr/include/osg/Node:19,
from /usr/include/osg/Group:17,
from TGBaseWidget.hpp:11,
from TGBaseWidget.cpp:1:
/usr/include/c++/4.4/bits/vector.tcc:312: note: synthesized method
‘TGWidgetElement TGWidgetElement::operator=(const TGWidgetElement)’ first
required here
make[2]: *** [build/Release/GNU-Linux-x86/TGBaseWidget.o] Fehler 1
make[2]: Verlasse Verzeichnis
'/home/thorsten/NetBeansProjects/thyrgon~subversion/Thyrgon'
make[1]: *** [.build-conf] Fehler 2
make[1]: Verlasse Verzeichnis
'/home/thorsten/NetBeansProjects/thyrgon~subversion/Thyrgon'
make: *** [.build-impl] Fehler 2
---
The Code:
int posX = 585;
int posY = 370;
std::vectorTGWidgetElement ElementLower;
for(int i=count_width; i0; i--)
{
ElementLower.push_back(TGWidgetElement(posX, posY,
WidgElementSideLower.png));
posX += 15;
posY += 15;
//this-addChild(ElementLower[count_width]);
}
I'm really stuck here. What am i doing wrong???
Thank you!
Cheers,
Thorsten
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19491#19491
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 9:56 AM:
int posX = 585;
int posY = 370;
std::vectorTGWidgetElement ElementLower;
for(int i=count_width; i0; i--)
{
ElementLower.push_back(TGWidgetElement(posX, posY,
WidgElementSideLower.png)); posX += 15;
posY += 15;
//this-addChild(ElementLower[count_width]);
}
I'm really stuck here. What am i doing wrong???
Group and other OSG Nodes declare operator= to be non-public so they
cannot be instantiated on the stack (which would easily lead to problems
with OSG's smart pointers); you have to dynamically allocate them.
Try something like this instead:
int posX = 585;
int posY = 370;
std::vectorosg::ref_ptrTGWidgetElement ElementLower;
for(int i=count_width; i0; i--)
{
ElementLower.push_back(new TGWidgetElement(posX,
posY,WidgElementSideLower.png));
posX += 15;
posY += 15;
//this-addChild(ElementLower[count_width]);
}
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derivedclasserror
Thrall, Bryan wrote on Wednesday, November 11, 2009 10:00 AM: Group and other OSG Nodes declare operator= to be non-public so they cannot be instantiated on the stack (which would easily lead to problems with OSG's smart pointers); you have to dynamically allocate them. I should've checked first; this is actually because they declare their destructor non-public (protected, actually). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
The response to my bug report must have been completely wrong then... Guess I should check the source before I post. Like I said, am not tracking svn bullet at the moment. http://tiny.cc/Eoa3l On Nov 11, 2009 10:00 AM, Alberto Luaces alua...@udc.es wrote: Definitely there is no support for BulletMultiThreaded in 64 bits at the moment. From the last post in the forum thread you gave to me: BulletMultiThreaded, MultiThreadedDemo, Gpu2dDemo, Gpu3dDemo are not supported on 64bit platforms. It was accidently enabled in a previous revision, but now it has been disabled in the trunk. If you can make any of this work on 64 platforms, please consider contributing it. Regards, Alberto Philip Lowman writes: Was using the CMake build but am not tracking svn at the moment. Perhaps this thread will help? ... On Nov 11, 2009 8:36 AM, Alberto Luaces wrote: Hi Philip, what build... ___ osg-users mailing list osg-us...@lists.openscenegrap... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Hi Wyatt,
1. Is there a way I can query the number of texture units available on my
GPU via an OSG call?
A Google search turned up glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB). Also
searching the OSG headers, I found
osg::Texture::Extensions::numTextureUnits() which returns a GLint (int).
Look at the source to find out where the value will be initialized or
how to initialize it yourself.
I generally don't bother to query and use 8 (0-7) as a number that's
supported pretty much everywhere.
2. Is there a list, other than the osgShadow programming guide of shadowmap
techniques, specifically ViewDependentShadow techniques?
The source/headers... And the mailing list archives.
The three usable types are:
class LightSpacePerspectiveShadowMapDB /*...*/ {};
class LightSpacePerspectiveShadowMapCB /*...*/ {};
class LightSpacePerspectiveShadowMapVB /*...*/ {};
And LightSpacePerspectiveShadowMap is an alias for
LightSpacePerspectiveShadowMapDB :
typedef LightSpacePerspectiveShadowMapDB LightSpacePerspectiveShadowMap;
And also StandardShadowMap is usable, but it's not view-dependent, so
it's pretty much a direct replacement for osgShadow::ShadowMap but in
the same class hierarchy as the LightSpace* classes.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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] std::vector instances from osg::geode derived class error
Hi, Ahhh. Ok that worked. But now i uncommented Code: this-addChild(ElementLower[count_width]); It compiles but gives a Segmentation Fault at startup. Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19496#19496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 10:31 AM: Ahhh. Ok that worked. But now i uncommented Code: this-addChild(ElementLower[count_width]); It compiles but gives a Segmentation Fault at startup. Not a lot of information to go on, but here's a WAG: count_width is counting down, but ElementLower is growing, so ElementLower[count_width] is not the same as the element you just passed to push_back(). HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Alberto Luaces wrote: Hi Paul, Lovely work! I assume that for now, independent threading for the physics is handled only by the multi-threaded Bullet library, is this correct? I couldn't find in the source any place using the PhysicsThreading class, are you going to use it in the future? I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. Hi Alberto -- Thanks for trying osgBullet. After the 2.74 release, the Bullet people made a series of incompatible changes to BulletMultiThreaded. I've modified osgBullet to not use BulletMultiThreaded if the version is greater than 2.74, but probably failed to make the CMake system robust enough to handle the library's absence. I'll add this to my to-do list. BulletMultiThreaded contains some host-thread SPU classes to do constraint solving in parallel. In my investigation, these classes typically run slower than the non-threaded sequential solver. osgBullet allows an application to run the physics simulation in a separate host thread, so that OSG rendering isn't blocked by the cost of the physics simulation. That separate thread can use either the sequential solver or the host-thread solver; osgBullet doesn't impose any restrictions on how the simulation is performed by Bullet. I do have a few simple examples that show how to do this, but they use proprietary client data. I'll add to my to-do list, either to rewrite this in a non-proprietary way, or get permission from the client to open source the data. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Obj loader: one mesh with different materials
Hi David, I just started with OSG I was wondering if you can give me some pointers or sample code that could do something similar as to what you describled. To be more specific right now I'm trying to 1. select a point on the screen and find corresponding vertex position. 2. edit xyz position of that vertex The problem i'm having with #1 is that mouse xy is in screen coordinates while vertex is in some other kind of coordinate system and I don't know how to convert mouse xy to vextex xy. As for #2, should i modify the vec3arr and redraw the whole mesh? It might take a long time. Any help would be appreciated. Thank you! O. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19488#19488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived class error
Hi, It only gives a segfault if count_width is higher than 1. I've no idea what could be wrong... Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19502#19502 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived class error
Hi, It only gives a segfault if count_width is higher than 1. I've no idea what could be wrong... Thank you! Cheers, Thorsten Try this: this-addChild(ElementLower[count_width].get()); Don -- To compel a man to furnish contributions of money for the propagation of opinions which he disbelieves and abhors is sinful and tyrannical. - Thomas Jefferson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived class error
Hi, Thanks. the difference is the both couts that i did sow both instances now. Afterwards i get a segfault again. Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19505#19505 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] std::vector instances from osg::geode derived classerror
Thorsten Werner wrote on Wednesday, November 11, 2009 11:47 AM: Hi, It only gives a segfault if count_width is higher than 1. I've no idea what could be wrong... Try looking at it in a debugger and compare count_width with the current size of the vector. For example, if count_width is 5, your code does: ElementLower.push_back(new TGWidgetElement()); // vector size is now 1 addChild(ElementLower[5]); // there is no such element! HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] help with osgmovie
Hi, i try to play a movie in osg but the code osgmovie doesn't work i have some errors when i compile it i think this need some class of plugin or SDL but i dont know where download this and how add to my project??? i need help firsti have some problem with audiostream, and image but i download this again and i have this errors prueba.obj : error LNK2019: símbolo externo __declspec(dllimport) public: float __thiscall osg::Image::getPixelAspectRatio(void)const (__imp_?getpixelaspectra...@image@osg@@QBEMXZ) sin resolver al que se hace referencia en la función _main 1prueba.obj : error LNK2019: símbolo externo __declspec(dllimport) public: class std::vectorclass osg::ref_ptrclass osg::AudioStream,class std::allocatorclass osg::ref_ptrclass osg::AudioStream__thiscall osg::ImageStream::getAudioStreams(void) (__imp_?getaudiostre...@imagestream@osg@@qaeaav?$vec...@v?$ref_ptr@vaudiostr...@osg@@@osg@@v?$alloca...@v?$ref_ptr@vaudiostr...@osg@@@osg@@@std@@@std@@XZ) sin resolver al que se hace referencia en la función _main 1C:\Documents and Settings\adminmulti\Mis documentos\RealidadVirtual\Pory\OSGpr\Debug\OSGpr.exe : fatal error LNK1120: 2 externos sin resolver Thank you! Cheers, Ivan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19508#19508 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Monday, November 09, 2009 1:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow question Hi Wyatt, The fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders listed at the top of the cpp with the other two shaders Ah, no those are only used if you enable the debug HUD. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Hi Wyatt, I have changed to a LISPSM shadow technique. OK. I have removed the cast bit from my terrain. The only two objects I have set cast shadow are close together. This should not need to be done when using LISPSM. It's view-dependent, so you don't need to make sure that the shadow map is applied to a small part of the scene as you did with the normal ShadowMap. Still, it doesn't hurt if you don't need shadows cast by your terrain anyways. My texture size is 2048 x 2048. Not seeing shadows on the terrain from my objects. Did you check the debugHUD (with LISPSM it's as easy as shadowTechnique-setDebugDraw(true) )? Does it show something that looks valid? Note that LISPSM's shaders are different than ShadowMap's shaders that your used before. It uses a different name for the shadow map sampler, and by default it separates the shaders into main and shadow parts, though you can still disable the shaders that LISPSM adds and use your own (make sure to use the right sampler and uniform names in your shader). Check the source in StandardShadowMap.cpp to see what the shaders look like. Changed shadowTexture unit to 7. Should basetexture be 0 still? The base texture unit is just used by the shaders that LISPSM sets by default. If you're disabling those and using your own (which you surely do if you're using units 0-3 for some effects), then don't worry about it. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] osgShadow question
Hi Wyatt, Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? You're starting to go into the realm of questions you should be able to answer yourself, using the source and trying things out. I can't help you with every little detail. In this case, I think those shaders are only used by the debugHUD itself, and so you shouldn't need to modify them even if you enable the debugHUD since they should not affect your scene. But I'm not sure, check the source to see where they're applied. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] osgShadow question
Hi Debug hud shaders are only used by debug hud to display shadow map. These shaders should not bother you at all. They don't affect your scene, scene is drawn by mainVertex/mainFragment/shadowVertex/shadowFragment shaders. See osgshadow example with following options: -4 --lispsm --debugHUD and see what they do. Wojtek -- From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Sent: Wednesday, November 11, 2009 8:08 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgShadow question Hi Wyatt, Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? You're starting to go into the realm of questions you should be able to answer yourself, using the source and trying things out. I can't help you with every little detail. In this case, I think those shaders are only used by the debugHUD itself, and so you shouldn't need to modify them even if you enable the debugHUD since they should not affect your scene. But I'm not sure, check the source to see where they're applied. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] osgShadow question
Hi Wojtek, I'm surprised the magic word to summon Wojtek (shadows) took so much time this time! We've been discussing this for a few days now :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Did you check the debugHUD (with LISPSM it's as easy as shadowTechnique-setDebugDraw(true) )? Does it show something that looks valid? I am not sure... With the debugHUD in the ShadowMap example, there was just a window which appeared to display the shadow map in gray-scale, but in the LISPSM example, there appears to be two sub-windows in the debughud window (not in gray-scale). What are these displaying? Note that LISPSM's shaders are different than ShadowMap's shaders that your used before. It uses a different name for the shadow map sampler, and by default it separates the shaders into main and shadow parts, though you can still disable the shaders that LISPSM adds and use your own (make sure to use the right sampler and uniform names in your shader). Check the source in StandardShadowMap.cpp to see what the shaders look like. I found the shader source, in StandardShadowMap::StandardShadowMap. I am a bit confused about how to use the osgShadow in my app if I already have shaders in my app. The osgShadow programmers guide says What if my objects already have a shader applied to them? * That shader also needs to implement shadow mapping. See the top of src/osgShadow/ShadowMap.cpp for the basic shader, and use that in your shader (keep the same names for the variables too). Am I supposed to, basically, copy the shader code from StandardShader map and add it to my shaders and turn off the LISPSM shaders? W ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi J-S, I have been bit swamped recently. I have restricted my policy to react only to LISPSM while being busy ;-). Besides, you are doing much better support than I could dream of. Thank You, btw. Wojtek -- From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Sent: Wednesday, November 11, 2009 9:07 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgShadow question Hi Wojtek, I'm surprised the magic word to summon Wojtek (shadows) took so much time this time! We've been discussing this for a few days now :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Hi Wyatt, Did you check the debugHUD (with LISPSM it's as easy as shadowTechnique-setDebugDraw(true) )? Does it show something that looks valid? I am not sure... With the debugHUD in the ShadowMap example, there was just a window which appeared to display the shadow map in gray-scale, but in the LISPSM example, there appears to be two sub-windows in the debughud window (not in gray-scale). What are these displaying? First square displays shadow map using pseudo coloring (if you interested why see the comment above the shader in DebugShadowMap.cpp) second square contains dump from predraw of you scene to very small depth texture, this extra pre render step is used to compute visible part of scene and optimize shadow volume. This second square is only drawn for LispsmDB MinimalDrawBoundsShadowMap. Note that LISPSM's shaders are different than ShadowMap's shaders that your used before. It uses a different name for the shadow map sampler, and by default it separates the shaders into main and shadow parts, though you can still disable the shaders that LISPSM adds and use your own (make sure to use the right sampler and uniform names in your shader). Check the source in StandardShadowMap.cpp to see what the shaders look like. [..] Am I supposed to, basically, copy the shader code from StandardShader map and add it to my shaders and turn off the LISPSM shaders? Generally yes, But don't turn them off but rather alter them with your modified shaders. WL ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap problem...
Hi Wojtek, Generally yes, But don't turn them off but rather alter them with your modified shaders. That's useful when the ShadowedScene is the root of the scene, and your entire scene can be rendered with a single shader (or uber-shader with uniforms to select different code paths). But in some cases that might not be the case. I find it more convenient to disable the ShadowTechnique's shaders and just place my own shaders at the root of the scene. Also others may customize the way their shaders are applied to individual nodes. Eventually I intend to start using VirtualProgram too... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] ShadowMap problem...
Generally yes, But don't turn them off but rather alter them with your modified shaders. That's useful when the ShadowedScene is the root of the scene, and your entire scene can be rendered with a single shader (or uber-shader with uniforms to select different code paths). But in some cases that might not be the case. I see, that would work too. I find it more convenient to disable the ShadowTechnique's shaders and just place my own shaders at the root of the scene. Also others may customize the way their shaders are applied to individual nodes. Eventually I intend to start using VirtualProgram too... :-) I really recommend it. We developed VirtualProgram for this particular purpose ie to free user from creating all in one shader. Wojtek __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] Double-click concern.
Hi all, Is there a convention about input events sequences in OSG? I first thought that click and drag sequence would always be: push - [drag]* - release. This should work fine for most cases. The problems come with the double-click event. Although the name of the event refers to a click which usually means a push-release pair, the EventQueue::mouseDoubleButtonPress method is used to adapt the event. This method imply that the event is actually a button press. As an example, this is corroborated by Qt which documents its MouseButtonPress as Mouse press event and its MouseButtonDblClick as Mouse press again event. I have done two tests, one with the osgManipulator example and one with a viewer adapted on Qt, both on Windows Vista. All tests show that the actual double-click sequence is: push - release - doubleclick - [drag]* - release. The problem I see is that the double-click (actually the second-push) breaks the assumption that a drag follows a push This can be seen in most OSG objects that implicitly make this assumption, as about nothing in OSG currently treat the 'doubleclick' event. From example, if you double-click+drag on a Dragger, it ignores the 'drag' events, since they were preceded by a 'release' event that sets the dragger as inactive. I was wondering if this is an intended behaviour? regards, Vincent Gadoury ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgUtil issue with exiting program
Hi, I am having a problem with the osgUtil library crashing my program upon exiting. The error is as follows: Code: glibc detected ./myprog: free(): invalid pointer: 0x00e5b4f8 *** I am pretty sure this is caused by osgUtil. If I comment out all of my osgUtil code and not link the library after the compile it exits fine. Is there something I should be calling to force it to exit properly? I am only linking libosg and libosgUtil into my program. Do I need to link others for osgUtil to work properly? Just to clarify, my program does run properly. This only happens on exit. Other Information: osg version: 2.8.2 osgUtil version: 2.8.2 OS: Linux 2.6.28-gentoo-r5 I should note that I am also using vrjuggler in my program. (I will post the full error in a moment. The forum is complaining that I need to have 2 posts before I can add links) Thank you for your time. Any help would be appreciated. Cheers, Bric -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19525#19525 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil issue with exiting program
Full error: Code: *** glibc detected *** ./myprog: free(): invalid pointer: 0x0115b4f8 *** === Backtrace: = /lib64/libc.so.6[0x7f3553fad19d] /lib64/libc.so.6(cfree+0x76)[0x7f3553faebe6] ../lib/libosg.so.55(_ZN3osg8StateSet5clearEv+0x7e)[0x7f35549fe79e] ../lib/libosg.so.55(_ZN3osg8StateSetD0Ev+0x24)[0x7f35549feb54] ../lib/libosgUtil.so.55(_ZN7osgUtil9RenderBinD0Ev+0x204)[0x7f3554590b54] ../lib/libosgUtil.so.55[0x7f355458fdda] /lib64/libc.so.6(__cxa_finalize+0x94)[0x7f3553f6fe14] ../lib/libosgUtil.so.55[0x7f35545035c3] === Memory map: 0040-00429000 r-xp 08:03 4261679 /home/xolo/source/trunk/build/debug/bin/myprog_09 00628000-00629000 r--p 00028000 08:03 4261679 /home/xolo/source/trunk/build/debug/bin/myprog_09 00629000-0062a000 rw-p 00029000 08:03 4261679 /home/xolo/source/trunk/build/debug/bin/myprog_09 0062a000-0062c000 rw-p 0062a000 00:00 0 010cc000-013db000 rw-p 010cc000 00:00 0 [heap] 4004c000-4004d000 ---p 4004c000 00:00 0 4004d000-4084d000 rwxp 4004d000 00:00 0 40917000-40919000 rwxp 00:0f 2505 /dev/zero 41d3d000-41d3e000 ---p 41d3d000 00:00 0 41d3e000-4253e000 rwxp 41d3e000 00:00 0 4253e000-4253f000 ---p 4253e000 00:00 0 4253f000-42d3f000 rwxp 4253f000 00:00 0 7f354800-7f35480c3000 rw-p 7f354800 00:00 0 7f35480c3000-7f354c00 ---p 7f35480c3000 00:00 0 7f354e766000-7f354eb66000 rw-s 2ef937000 00:0f 8238 /dev/nvidia0 7f354eb66000-7f354ec66000 rw-s 312c32000 00:0f 8238 /dev/nvidia0 7f354ec66000-7f354eca6000 rw-s 3161f 00:0f 8238 /dev/nvidia0 7f354eca6000-7f354ecc6000 rw-s 42288c000 00:0f 8238 /dev/nvidia0 7f354ed9a000-7f354edce000 rw-p 7f354ed9a000 00:00 0 7f354edce000-7f354edd3000 r-xp 08:03 3851712 /usr/lib64/libXfixes.so.3.1.0 7f354edd3000-7f354efd2000 ---p 5000 08:03 3851712 /usr/lib64/libXfixes.so.3.1.0 7f354efd2000-7f354efd3000 r--p 4000 08:03 3851712 /usr/lib64/libXfixes.so.3.1.0 7f354efd3000-7f354efd4000 rw-p 5000 08:03 3851712 /usr/lib64/libXfixes.so.3.1.0 7f354efd4000-7f354efdd000 r-xp 08:03 3851669 /usr/lib64/libXrender.so.1.3.0 7f354efdd000-7f354f1dc000 ---p 9000 08:03 3851669 /usr/lib64/libXrender.so.1.3.0 7f354f1dc000-7f354f1dd000 r--p 8000 08:03 3851669 /usr/lib64/libXrender.so.1.3.0 7f354f1dd000-7f354f1de000 rw-p 9000 08:03 3851669 /usr/lib64/libXrender.so.1.3.0 7f354f1de000-7f354f1e7000 r-xp 08:03 3941507 /usr/lib64/libXcursor.so.1.0.2 7f354f1e7000-7f354f3e7000 ---p 9000 08:03 3941507 /usr/lib64/libXcursor.so.1.0.2 7f354f3e7000-7f354f3e8000 r--p 9000 08:03 3941507 /usr/lib64/libXcursor.so.1.0.2 7f354f3e8000-7f354f3e9000 rw-p a000 08:03 3941507 /usr/lib64/libXcursor.so.1.0.2 7f35507e7000-7f35507ec000 r-xp 08:03 3874872 /usr/lib64/libXdmcp.so.6.0.0 7f35507ec000-7f35509eb000 ---p 5000 08:03 3874872 /usr/lib64/libXdmcp.so.6.0.0 7f35509eb000-7f35509ec000 r--p 4000 08:03 3874872 /usr/lib64/libXdmcp.so.6.0.0 7f35509ec000-7f35509ed000 rw-p 5000 08:03 3874872 /usr/lib64/libXdmcp.so.6.0.0 7f35509ed000-7f35509ef000 r-xp 08:03 3811477 /usr/lib64/libXau.so.6.0.0 7f35509ef000-7f3550bee000 ---p 2000 08:03 3811477 /usr/lib64/libXau.so.6.0.0 7f3550bee000-7f3550bef000 r--p 1000 08:03 3811477 /usr/lib64/libXau.so.6.0.0 7f3550bef000-7f3550bf rw-p 2000 08:03 3811477 /usr/lib64/libXau.so.6.0.0 7f3550bf-7f3550bf1000 r-xp 08:03 4284473 /usr/lib64/opengl/nvidia/tls/libnvidia-tls.so.180.60 7f3550bf1000-7f3550cf1000 ---p 1000 08:03 4284473 /usr/lib64/opengl/nvidia/tls/libnvidia-tls.so.180.60 7f3550cf1000-7f3550cf2000 rw-p 1000 08:03 4284473 /usr/lib64/opengl/nvidia/tls/libnvidia-tls.so.180.60 7f3550cf2000-7f3551a94000 r-xp 08:03 4284459 /usr/lib64/opengl/nvidia/lib/libGLcore.so.180.60 7f3551a94000-7f3551b93000 ---p 00da2000 08:03 4284459 /usr/lib64/opengl/nvidia/lib/libGLcore.so.180.60 7f3551b93000-7f3551fca000 rwxp 00da1000 08:03 4284459 /usr/lib64/opengl/nvidia/lib/libGLcore.so.180.60 7f3551fca000-7f3551fdc000 rwxp 7f3551fca000 00:00 0 7f3551fdc000-7f3551fe3000 r-xp 08:03 9783102 /usr/local/lib64/libOpenThreads.so.2.4.0 7f3551fe3000-7f35521e2000 ---p 7000 08:03 9783102
Re: [osg-users] Announcing osgWorks and osgBullet
Alberto Luaces wrote: I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. This should be fixed in svn head. Thanks for reporting it. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] a question about blender and osgExport
Hi everybody, help me please! i have try this almost a week, but still have proplems Thank you! Cheers, ren -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19531#19531 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget - menu and select from list
Hi, Jeremy Moles wrote: Sorry it's taking so long--I've been incredibly busy trying to reverse-engineering a barcode scanner in Windows so that I can write a driver in Linux. :) Can you contact me on AIM (cubicool) or Googletalk (cubic...@gmail.com)? Might be faster for me to help that way... No worries, I've also got more than enough things to do. The menu is just one item on my list. I'll ping when I'm busy with it again. thanks jp -- 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] Redraw osg::HeightField
Hi, Teodor Hanchevici wrote: Hi, Please bear with me on this one since I'm a newbie with OSG. I am trying to update and redraw an osg::HeightField. I have created a callback and I can get the values from the grid in the event handler, I can set the values back in the grid but the display does not redraw. What is the proper way of doing this? I have attached the code I am using. Any suggestions are appreciated. not sure, but try dirty() function on the geode. jp Thank you! Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19524#19524 ___ 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] [forum] help with osgmovie
Hi, i am kaibaseto again and i am using visual studio 2008 ... Thank you! Cheers, Ivan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19537#19537 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
