Re: [osg-users] Terrain Paging: Knowing Which Tiles are loaded
Hi Paul, The OSG natively supports database paging, and its automatically set up in osgViewer::Viewer/CompositeViewer when your scene contains osg::PagedLOD nodes - it's PagedLOD nodes that provide the information about the what to page in. The OpenFlight loaders doesn't know about paging itself, the format itself doesn't support as far as I'm aware. If you wish to use it for paging then you'll need to take the database and convert to an OSG native format and insert PagedLOD nodes where appropriate. Robert. On Jan 8, 2008 11:26 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, Im currently working with paged databases and need to further my knowlwdge on the way OSG handles terrain paging. I have a 30G OpenFlight database with LOD osgviewer handles paging nativelely yes? Or do I have to manually give osg the name and number of tiles I'm using from my database? or can I just feed it master.flt ? I would also like to know which tiles are being loaded in and which tiles are being loaded out - Does anyone know which are the releveant classes handling this? Best Regards ___ 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] Font Corruption Issue
Hi Gordon, If the graphics context being shared? If not the contextID will need updating for the osg::State associated with the pbuffer. Robert. On Jan 8, 2008 8:39 PM, Gordon Tomlinson [EMAIL PROTECTED] wrote: Hi Y'all We having some issues with osg 1.2 and font corruption ( I know but we cannot yet move on, curse of commercial software and 20k users base, soon though soon... ) Basically we have some fonts and they show normal all is good, we then render to a Pbuffer and the fonts work great in the Pbuffer, the resultant video all is good we then switch back to the normal render and the fonts are now hosed. classic black box/white box syndrome... Is there something we need to do in the fonts to ensure they survive these context switches, Thanks in advance Best Regards Gordon __ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] dynamic shadows
hi, currently we use the classic shadow mapping technique in our work for shadowing an outdoor scene (see VRC at http://yag2002.sf.net). as the shadow quality is not that good, we try to use a better approach, such as parallel split shadow mapping which is integrated into osg in the meantime. what i would like to know is: 1. are any suggestions/considerations for shadowing our outdoor scene in general? is parallel split shadow mapping a good way to do that? reading papers which pray for their techniques can sometimes be misleading :-) 2. is someone willing to help us with integrating the shadow mapping implementation in osg into our project? cheers boto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer Bug+Fix report - traversal number of UpdateVisitor is not incremented
Hello, I have encountered a bug at osgViewer::CompositeViewer in the current SVN version: the traversal number of the UpdateVisitor is not incremented automatically from frame to frame. The bug can be fixed by incrementing the traversal number of the UpdateVisitor in the osgViewer::CompositeViewer::advance() or updateTraversal() method. The problem I had was the fact that osgSim::DOFTransform supports animation - but the animation requires that the traversal number of the UpdateVisitor needs to be incremented between two frames. Another solution to fix this problem would also be to adjust the osgSim::DOFTransform::traverse() method to use the FrameNumber of the FrameStamp instead of the TraversalNumber. Kind regards, Daniel Kallfass ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Bug+Fix report - traversal number of UpdateVisitor is not incremented
HI Daniel, I believe the best fix for this bug looks to be adding code to the begining of CompositeViewer::updateTraversal() method that sets the UpdateVisitor in the same way as the Viewer::updateTraversal() does. Could you do an svn update and let me know if this fixes the problem. Robert. On Jan 9, 2008 1:30 PM, Kallfass, Daniel, SDGE1 [EMAIL PROTECTED] wrote: Hello, I have encountered a bug at osgViewer::CompositeViewer in the current SVN version: the traversal number of the UpdateVisitor is not incremented automatically from frame to frame. The bug can be fixed by incrementing the traversal number of the UpdateVisitor in the osgViewer::CompositeViewer::advance() or updateTraversal() method. The problem I had was the fact that osgSim::DOFTransform supports animation - but the animation requires that the traversal number of the UpdateVisitor needs to be incremented between two frames. Another solution to fix this problem would also be to adjust the osgSim::DOFTransform::traverse() method to use the FrameNumber of the FrameStamp instead of the TraversalNumber. Kind regards, Daniel Kallfass ___ 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::ShadowMap not reacting to changes
Hello Raymond, Can you try to use a ref pointer instead of the regular pointer for osg::Shader* shader. I believe I encountered exactly this issue when working on the PSSM, please see a patch that I sent +/- a week ago. It has no effect, and anyways, it would not have explained why setAmbientBias did not take effect either... Anything else? Just to reiterate, only setTextureSize() takes effect, not setAmbientBias or addShader. Plus, it works in a straight OSG project (modified from the osgshadow example), but not in our application. So I'm just looking for possible explanations. I know fully that the problem is in our code, I'm just puzzled as to what could cause that. Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] what binaries and libs can be used with visual studio 2008 ?
Hello Peter, 1. Can the visual studio 2008 use the compiled win32 binaries and libs in the osg 2.2 release or not ? Which compiler was your 2.2 compiled with? VS2008 is still pretty new, but from what I have seen, it is binary-compatible with 2005 (please don't kill me if this ends up not being true... :-) ). So if your OSG 2.2 binaries and 3rdParty packages were compiled with 2005 (8.0), you should be able to use them with 2008 (9.0). At least, I use the 3rdParty binaries for 8.0 with 9.0 and it seems to work (until now! *crosses fingers*). If the naswer is no, then what do i need to do to get compatiable libs or binaries to use with visual studio 2008 ? If the answer turns out to be no, you can compile OSG from source using VS2008. You need CMake 2.5 (which is in the nightly CVS snapshots section on cmake.org - http://www.cmake.org/files/vCVS/ ) or 2.6 when it comes out. See the compilation instructions on openscenegraph.org, and pay heed to the platform specific info for VS2005, which still applies to 2008. 2. My c++ is a bit rusty, but when you link the libs into your project, and build a final result does it not embed the libs into you application exe and eleiminate the need for the run time osg DLL's. I thought that was the reason to link in the libs ? If this is not the case why not ? In a nutshell, when linking with a dynamic library, you still need a .lib (which is then called an import library instead of just a library). That way, the executable links without undefined symbols. But then at runtime, the symbols that were defined in the import library will try to use those in the DLL. So your application needs to be able to find this DLL, which is the reason we usually either A) place the DLLs needed for an app in the same directory as the app, which is a bit less clean but is useful to create a package that can just be downloaded and run regardless of the DLLs a user has on their machine, or B) change the PATH environment variable to include the directory where the DLLs are contained. The other option is to statically link OSG to your app, but I don't know how well that is supported at the moment (and particularly on Windows). It would likely make a huge executable however... and then what exasctly is needed to run a final application on a XP/vista machine that has a clean install of the os ? EG osg runtime dll + c++ runtime or what ? Exactly. You need any DLLs that your app requires and which are not part of the standard Windows XP/Vista install. In most cases, this will mean OSG's DLLs and the Visual C++ runtime for the version you compiled with (8.0, 8.0SP1, or 9.0 for example). You can use dependency walker (http://www.dependencywalker.com/) to see which DLLs your app depends on, and whether it's able to find them. Other people can help you a bit more on this, but I believe the 3rdParty binaries on https://osgtoy.svn.sourceforge.netsvnroot/osgtoy/3rdParty/branches/ (for the compiler you have) contain all that is needed (and if I'm not mistaken, the binaries installer includes those as well). So you could conceivably make a directory in which you put the DLLs from that package and your executable, and that should work. Correct me if I'm wrong though. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] question about cleaning up an OpenGL context
We are using the OSG along with JOGL to provide and manage contexts. In general, this has worked well, and we have seen others reporting the same thing on this mailing list. (We're not yet using the embedded graphics window, however, but have our own SceneView, etc.) One thing that we had to be careful to do was manage context IDs correctly. We use multiple windows, and windows can be removed and return, so that their contexts can be removed and remade. We discovered that if we were removing a window and creating it again, we could use JOGL and some fancy footwork to tell the OSG to clean up a context (releaseAllGLObjects() and flushAllDeletedGLObjects()) and stop drawing in it until the context is initialized again. We seem to be doing alright with that, since it seems we're getting notified about the context going away (removeNotify() in Java). However, in some cases, as with the JOGL lightweight canvas, which uses a PBuffer, a context can be recreated when the object is resized. We don't seem to be getting any messages in time to clean up OSG's OpenGL objects while the context is current. Is there a way, or would it make sense, to allow us to clean up all of the OpenGL objects associated with a context, without that context being current? I don't know what happens to OpenGL objects when their context goes away, and I'm wondering whether, in this case, we can tell OSG to clean up its stuff but it doesn't need to tell OpenGL anything. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Bug+Fix report - traversal number ofUpdateVisitor is not incremented
Hi Robert, I have tried your latest SVN fix and it worked fine for me! Thank you very much. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, January 09, 2008 2:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer Bug+Fix report - traversal number ofUpdateVisitor is not incremented HI Daniel, I believe the best fix for this bug looks to be adding code to the begining of CompositeViewer::updateTraversal() method that sets the UpdateVisitor in the same way as the Viewer::updateTraversal() does. Could you do an svn update and let me know if this fixes the problem. Robert. On Jan 9, 2008 1:30 PM, Kallfass, Daniel, SDGE1 [EMAIL PROTECTED] wrote: Hello, I have encountered a bug at osgViewer::CompositeViewer in the current SVN version: the traversal number of the UpdateVisitor is not incremented automatically from frame to frame. The bug can be fixed by incrementing the traversal number of the UpdateVisitor in the osgViewer::CompositeViewer::advance() or updateTraversal() method. The problem I had was the fact that osgSim::DOFTransform supports animation - but the animation requires that the traversal number of the UpdateVisitor needs to be incremented between two frames. Another solution to fix this problem would also be to adjust the osgSim::DOFTransform::traverse() method to use the FrameNumber of the FrameStamp instead of the TraversalNumber. Kind regards, Daniel Kallfass ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about cleaning up an OpenGL context
Hi Andy, Sharing contexts should be able to get around some of the issues of resizing cause contexts to be recreated, although this depends very much on the window API your using. W.r.t cleaning all contexts, your can use node-relaseGLObjects() without passing in State* and it'll release all the GL obejcts for all contexts. Now this dumps the GL Object ID's in the respective deleted OpenGL object caches that the OSG maintains, these you then need to flush from the appropriate graphics context, or... if you are using the latest OSG SVN you can use the new discard functionality, that just throws away the cached OpenGL ID's without calling OpenGL at all, so its doesn't require the context to be current, or even still alive. The new functions for doing flush and discard can be found in include/osg/GLObjects: /** Flush all deleted OpenGL objects within the specified availableTime. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushDeletedGLObjects(unsigned int contextID, double currentTime, double availableTime); /** Flush all deleted OpenGL objects. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushAllDeletedGLObjects(unsigned int contextID); /** Discard all deleted OpenGL objects. * Note, unlike flushAllDeletedObjectObjects discard does not * do any OpenGL calls so can be called from any thread, but as a consequence it * also doesn't remove the associated OpenGL resource so discard should only be * called when the associated graphics context is being/has been closed. */ extern OSG_EXPORT void discardAllDeletedGLObjects(unsigned int contextID); I presume this is exactly what you're looking for :-) Robert. On Jan 9, 2008 2:58 PM, Andy Skinner [EMAIL PROTECTED] wrote: We are using the OSG along with JOGL to provide and manage contexts. In general, this has worked well, and we have seen others reporting the same thing on this mailing list. (We're not yet using the embedded graphics window, however, but have our own SceneView, etc.) One thing that we had to be careful to do was manage context IDs correctly. We use multiple windows, and windows can be removed and return, so that their contexts can be removed and remade. We discovered that if we were removing a window and creating it again, we could use JOGL and some fancy footwork to tell the OSG to clean up a context (releaseAllGLObjects() and flushAllDeletedGLObjects()) and stop drawing in it until the context is initialized again. We seem to be doing alright with that, since it seems we're getting notified about the context going away (removeNotify() in Java). However, in some cases, as with the JOGL lightweight canvas, which uses a PBuffer, a context can be recreated when the object is resized. We don't seem to be getting any messages in time to clean up OSG's OpenGL objects while the context is current. Is there a way, or would it make sense, to allow us to clean up all of the OpenGL objects associated with a context, without that context being current? I don't know what happens to OpenGL objects when their context goes away, and I'm wondering whether, in this case, we can tell OSG to clean up its stuff but it doesn't need to tell OpenGL anything. thanks, andy ___ 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] VPB in SVN
Hello Robert, I tried fetching VPB from SVN and compiling it on Windows, and I wonder if the current SVN version is in a state of flux. Apart from a few errors that are down to it not having been tested on Windows, there are a lot of errors that should be flagged on any compiler (methods not returning a value when they should, functions not included, etc.). We can use 0.9.1 for the time being, but is this expected? Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB in SVN
Hi J-S, VPB from SVN does need porting to Windows, in particular the posix functions used for managing the file systems need to have equivalents found. I'd appreciate Windows users tackling this as I don't have the Windows here to test and work on. A sort cut to Windows support would also be to compile using Cygwin as this will provide all the posix functions for you. W.r.t warnings, g++ 4.2.1 isn't reporting any warnings, I haven't upped the warning level from default so perhaps this might winkle so more out. I guess some of the warnings might be related to just targeting posix so far. W.r.t fallback that does work under Windows, 0.9.1 should work fine. Robert. On Jan 9, 2008 3:00 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Robert, I tried fetching VPB from SVN and compiling it on Windows, and I wonder if the current SVN version is in a state of flux. Apart from a few errors that are down to it not having been tested on Windows, there are a lot of errors that should be flagged on any compiler (methods not returning a value when they should, functions not included, etc.). We can use 0.9.1 for the time being, but is this expected? Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB in SVN
Hello Robert,
VPB from SVN does need porting to Windows, in particular the posix
functions used for managing the file systems need to have equivalents
found. I'd appreciate Windows users tackling this as I don't have the
Windows here to test and work on.
OK, I'll probably be able to help there in the coming weeks.
W.r.t warnings, g++ 4.2.1 isn't reporting any warnings, I haven't
upped the warning level from default so perhaps this might winkle so
more out. I guess some of the warnings might be related to just
targeting posix so far.
I didn't mean warnings, there are some errors that should show up on
any compiler, such as a method declared as bool someMethod() not
returning a value... For example, in include/vpb/FileCache :
bool sync() { if (_requiresWrite) write(_filename); }
should be
bool sync() { if (_requiresWrite) return write(_filename); return false; }
or something to that effect. I would have thought gcc would give an
error there... MSVC certainly does.
BTW, to correct the methods, I would like to know what is your
standard for methods returning error? 0/false = no error and 1/true =
error? Or 0/false = failed and 1/true = succeeded?
W.r.t fallback that does work under Windows, 0.9.1 should work fine.
Yep, works fine.
Thanks,
J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/
This message was sent using IMP, the Internet Messaging Program.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about cleaning up an OpenGL context
Thanks, we'll study this. This is the kind of stuff you make changes in very carefully. :) andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, January 09, 2008 10:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] question about cleaning up an OpenGL context Hi Andy, Sharing contexts should be able to get around some of the issues of resizing cause contexts to be recreated, although this depends very much on the window API your using. W.r.t cleaning all contexts, your can use node-relaseGLObjects() without passing in State* and it'll release all the GL obejcts for all contexts. Now this dumps the GL Object ID's in the respective deleted OpenGL object caches that the OSG maintains, these you then need to flush from the appropriate graphics context, or... if you are using the latest OSG SVN you can use the new discard functionality, that just throws away the cached OpenGL ID's without calling OpenGL at all, so its doesn't require the context to be current, or even still alive. The new functions for doing flush and discard can be found in include/osg/GLObjects: /** Flush all deleted OpenGL objects within the specified availableTime. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushDeletedGLObjects(unsigned int contextID, double currentTime, double availableTime); /** Flush all deleted OpenGL objects. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushAllDeletedGLObjects(unsigned int contextID); /** Discard all deleted OpenGL objects. * Note, unlike flushAllDeletedObjectObjects discard does not * do any OpenGL calls so can be called from any thread, but as a consequence it * also doesn't remove the associated OpenGL resource so discard should only be * called when the associated graphics context is being/has been closed. */ extern OSG_EXPORT void discardAllDeletedGLObjects(unsigned int contextID); I presume this is exactly what you're looking for :-) Robert. On Jan 9, 2008 2:58 PM, Andy Skinner [EMAIL PROTECTED] wrote: We are using the OSG along with JOGL to provide and manage contexts. In general, this has worked well, and we have seen others reporting the same thing on this mailing list. (We're not yet using the embedded graphics window, however, but have our own SceneView, etc.) One thing that we had to be careful to do was manage context IDs correctly. We use multiple windows, and windows can be removed and return, so that their contexts can be removed and remade. We discovered that if we were removing a window and creating it again, we could use JOGL and some fancy footwork to tell the OSG to clean up a context (releaseAllGLObjects() and flushAllDeletedGLObjects()) and stop drawing in it until the context is initialized again. We seem to be doing alright with that, since it seems we're getting notified about the context going away (removeNotify() in Java). However, in some cases, as with the JOGL lightweight canvas, which uses a PBuffer, a context can be recreated when the object is resized. We don't seem to be getting any messages in time to clean up OSG's OpenGL objects while the context is current. Is there a way, or would it make sense, to allow us to clean up all of the OpenGL objects associated with a context, without that context being current? I don't know what happens to OpenGL objects when their context goes away, and I'm wondering whether, in this case, we can tell OSG to clean up its stuff but it doesn't need to tell OpenGL anything. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB in SVN
Hi Robert,
Have you put -W -Wall in CMAKE_CXX_FLAGS.
I have a lot of warning too, but I know that your code work fine with
this warning.
So I never take the time to fix them.
Cheers
David
2008/1/9, Robert Osfield [EMAIL PROTECTED]:
On Jan 9, 2008 3:45 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
OK, I'll probably be able to help there in the coming weeks.
Great, much appreciated.
I didn't mean warnings, there are some errors that should show up on
any compiler, such as a method declared as bool someMethod() not
returning a value... For example, in include/vpb/FileCache :
bool sync() { if (_requiresWrite) write(_filename); }
should be
bool sync() { if (_requiresWrite) return write(_filename); return
false; }
or something to that effect. I would have thought gcc would give an
error there... MSVC certainly does.
I've just done a clean build and g++ isn't reporting any warnings
whatsoever.
The above is an error of course, I'll fix this.
BTW, to correct the methods, I would like to know what is your
standard for methods returning error? 0/false = no error and 1/true =
error? Or 0/false = failed and 1/true = succeeded?
Typically true for succeeded/did operation.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB in SVN
On Jan 9, 2008 3:45 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
OK, I'll probably be able to help there in the coming weeks.
Great, much appreciated.
I didn't mean warnings, there are some errors that should show up on
any compiler, such as a method declared as bool someMethod() not
returning a value... For example, in include/vpb/FileCache :
bool sync() { if (_requiresWrite) write(_filename); }
should be
bool sync() { if (_requiresWrite) return write(_filename); return false;
}
or something to that effect. I would have thought gcc would give an
error there... MSVC certainly does.
I've just done a clean build and g++ isn't reporting any warnings whatsoever.
The above is an error of course, I'll fix this.
BTW, to correct the methods, I would like to know what is your
standard for methods returning error? 0/false = no error and 1/true =
error? Or 0/false = failed and 1/true = succeeded?
Typically true for succeeded/did operation.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fwd: CMake and VS 2008
Hello everyone, I just got this from Bill Hoffman, one of the CMake developers, in relation to my saying that you need CMake 2.5.x or eventually 2.6 to use it with VS2008 (9.0). They added support for it in the next version of CMake, and would appreciate it if we could test it. Personally, I only use 9.0 at home for now, so I will test it out tonight when I get back. J-S - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 09 Jan 2008 12:43:58 -0500 From: Bill Hoffman [EMAIL PROTECTED] Reply-To: Bill Hoffman [EMAIL PROTECTED] Subject: CMake and VS 2008 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Via a google alert on CMake, I noticed this post of yours: Re: [osg-users] what binaries and libs can be used with visual ... You need CMake 2.5 (which is in the nightly CVS snapshots section on cmake.org - http://www.cmake.org/files/vCVS/ ) or 2.6 when it comes out. See the compilation instructions on openscenegraph.org, and pay heed to the platform specific info for VS2005, which still applies to 2008. 2. My c++ is a bit rusty, ... I have added support for VS 2008 to 2.4.8 RC 11, that you can find here: http://www.cmake.org/files/v2.4/cmake-2.4.8-RC-11-win32-x86.exe I am not on that list, but it would be nice if you could forward this information to the list. I am about to make the 2.4.8 final release, and it would be good to get some feedback from OSG users. Thanks. -Bill - End forwarded message - -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::ShadowMap not reacting to changes
Jean-Sébastien Guay schrieb: Hello Raymond, Can you try to use a ref pointer instead of the regular pointer for osg::Shader* shader. I believe I encountered exactly this issue when working on the PSSM, please see a patch that I sent +/- a week ago. It has no effect, and anyways, it would not have explained why setAmbientBias did not take effect either... Anything else? Just to reiterate, only setTextureSize() takes effect, not setAmbientBias or addShader. Plus, it works in a straight OSG project (modified from the osgshadow example), but not in our application. So I'm just looking for possible explanations. I know fully that the problem is in our code, I'm just puzzled as to what could cause that. Thanks, J-S Hi, have you run the project with OSG_NOTIFY_LEVEL=debug? There you can see, if your shader-program is faulty. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New osgPPU NodeKit (RTT, multipass postprocessing), take a look!
Hi Art, All the issues with the new nVidia driver are corrected now. It seems that nVidia drivers starts to be more restrictive to the shader code. The shaders were rewritten to be supported on the Shader Model 3.0 hardware. Hence the shaders should link now (However let me know if they still not). thanks, I have tested again and it works fine. I have used a 7600GS for testing. I will try to implement other tests based on osgPPU nodekit. Cool nodekit! regards, Markus. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: CMake and VS 2008
Hi again, They added support for it in the next version of CMake, and would appreciate it if we could test it. Sorry, should have mentioned more specifically the next version of the 2.4.x series which is why it's interesting. 2.4.8 RC 11 is the version in the 2.4 series that contains VS9.0 support. So once 2.4.8 is out of release-candidate status, you'll be able to grab that instead of getting a nightly snapshot of 2.5.x . Sorry for the confusion, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New osgPPU NodeKit (RTT, multipass postprocessing), take a look!
Hi Markus! Cool, I am glad to hear that the library also runs on another machines. As I have mentioned on the osgPPU Homepage I am planning to release Depth of Field example application. In my application I had already that effect running. Hence there is only a proper example application needed to setup it. Currently I have to prepare some video sequences for the upcoming Siggraph deadline, therefor I do not have a lot of free time to improve osgPPU. Because you like to implement another testing application you can try to implement the depth of field effect. I can upload all the shaders and a xml description of the ppu setup to run depth of field as in Eikonal Rendering (demo video on my homepage). What do you think? Best regards, Art Hi Art, All the issues with the new nVidia driver are corrected now. It seems that nVidia drivers starts to be more restrictive to the shader code. The shaders were rewritten to be supported on the Shader Model 3.0 hardware. Hence the shaders should link now (However let me know if they still not). thanks, I have tested again and it works fine. I have used a 7600GS for testing. I will try to implement other tests based on osgPPU nodekit. Cool nodekit! regards, Markus. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture mipmapping parameters (Request)
Hi, folks! I am wonder why the current implementation do not provide any method to specify GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD, GL_TEXTURE_BASE_LEVEL, and GL_TEXTURE_MAX_LEVEL (it exists already since OpenGL v1.2) I need to change the base and max level parameters of a texture (maybe I do not really need this, but there are some bugs which disapears when I use this texture parameters). Would it be a good idea if I provide a patch which do implement this to the osg core? This would probably introduce at least 4 more variables in the osg::Texture class and couple of methods. Are there some objections against this? Best, Art Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INT32 redeifinition with Win32 and VS8 binary package
It appears that the VS8 binary package for osg2.2.0 has a problem in one of the 3rd party header files included. (jmorecfg.h) Compiling against it causes an error regarding redefinition of INT32. Im not sure if there are any repercussions, but there is a simple fix seen in an old patch on the secondlife wiki which protects the define with a check against WIN32 https://wiki.secondlife.com/wiki/Patch_jpeglib in jmorecfg.h: #ifndef XMD_H typedef long INT32; #endif is changed to: #if !defined( XMD_H ) !defined( WIN32 ) typedef long INT32; #endif It also does an #undef on FAR just before it blanks it to remove a warning about redifinition. Im not sure how hard it would be to repackage the current 2.2 VS8 binary package, but at least it can be fixed for for future Visual Studio packages. Regards, Andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INT32 redeifinition with Win32 and VS8 binary package
Just an idle thought in passing with the advent of 64 bit builds, it may not be such a good idea to mark a long as a 32 bit quantity since I believe the redmond 64 bit model defines long as a 64 bit quantity where as an int is 32 bits. On 32 bit systems, the two are the same size and can be freely interchanged. So apply the patch but ensure the build is 32 bits only. Happy New Year PhilT -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Somerville, Andrew Sent: 09 January 2008 21:43 To: osg-users@lists.openscenegraph.org Subject: [osg-users] INT32 redeifinition with Win32 and VS8 binary package It appears that the VS8 binary package for osg2.2.0 has a problem in one of the 3rd party header files included. (jmorecfg.h) Compiling against it causes an error regarding redefinition of INT32. Im not sure if there are any repercussions, but there is a simple fix seen in an old patch on the secondlife wiki which protects the define with a check against WIN32 https://wiki.secondlife.com/wiki/Patch_jpeglib in jmorecfg.h: #ifndef XMD_H typedef long INT32; #endif is changed to: #if !defined( XMD_H ) !defined( WIN32 ) typedef long INT32; #endif It also does an #undef on FAR just before it blanks it to remove a warning about redifinition. Im not sure how hard it would be to repackage the current 2.2 VS8 binary package, but at least it can be fixed for for future Visual Studio packages. Regards, Andy ___ 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] Implementing picking using C#
Hi all, I'm trying to implement picking in OSG using C#. I refer to C++
examples for such an implementation.
Part of the C++ example code is as follows,
class PickHandler : public osgGA::GUIEventHandler
{
public:
PickHandler() : _mX( 0. ),_mY( 0. ) {}
bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa )
{
osgViewer::Viewer* viewer =
dynamic_castosgViewer::Viewer*( aa );
if (!viewer)
return false;
}
bool pick( const double x, const double y,
osgViewer::Viewer* viewer )
{
}
.
}
The method GUIEventHandler::handle() is overridden and the pointer to the
osgGA::GUIActionAdapter object (aa) is cast into a osgViewer::Viewer pointer
(viewer). Then the osgViewer::Viewer pointer is passed to the pick() method.
My problem is that I think such a casting from aa to viewer is infeasible in
C#. Does anyone know deal with this problem?
Thanks!
Ke Li
_
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Implementing picking using C#
Adding to the following email:
osgViewer::Viewer is derived from osgViewer::View and osgViewer::Viewerbase,
and osgViewer::View is derived from
osg::View and osgGA::GUIActionAdapter. These classes are modeled in a typical
way of multiple implementation inheritance which is unacceptable in C#.
Thanks!
Ke Li
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Wed, 9 Jan 2008 16:06:42
-0700Subject: [osg-users] Implementing picking using C#
Hi all, I'm trying to implement picking in OSG using C#. I refer to C++
examples for such an implementation. Part of the C++ example code is as
follows,
class PickHandler : public osgGA::GUIEventHandler
{
public:
PickHandler() : _mX( 0. ),_mY( 0. ) {}
bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa )
{
osgViewer::Viewer* viewer =
dynamic_castosgViewer::Viewer*( aa );
if (!viewer)
return false;
}
bool pick( const double x, const double y,
osgViewer::Viewer* viewer )
{
}
.
}
The method GUIEventHandler::handle() is overridden and the pointer to the
osgGA::GUIActionAdapter object (aa) is cast into a osgViewer::Viewer pointer
(viewer). Then the osgViewer::Viewer pointer is passed to the pick() method.
My problem is that I think such a casting from aa to viewer is infeasible in
C#. Does anyone know deal with this problem?
Thanks!
Ke Li
Put your friends on the big screen with Windows Vista® + Windows Live™. Start
now!
_
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INT32 redeifinition with Win32 and VS8 binary package
Hello Andrew, It appears that the VS8 binary package for osg2.2.0 has a problem in one of the 3rd party header files included. (jmorecfg.h) Compiling against it causes an error regarding redefinition of INT32. [...] in jmorecfg.h: #ifndef XMD_H typedef long INT32; #endif is changed to: #if !defined( XMD_H ) !defined( WIN32 ) typedef long INT32; #endif I just checked, and on my systems, the first block of code is in jmorecfg.h (*no* include guard for WIN32), yet I never got the redefinition warning. I'm using both Windows XP and Vista, with both VC++ 2005 and 2008. Are you sure this isn't caused by some other headers you're including in your app? That is to say, one definition is in jmorecfg.h, where is the other one? If you can post the entire warning (with file names and line numbers) it would be easier to see what's going on. Just to check that this isn't a red herring. To reply to Philip Taylor about the 64-bit issues, this is a 3rd party header, so OSG has little control over it. On the other hand, it comes from libjpeg, which is very popular and is used on almost all linux distros (most of which are built both 32 and 64 bit these days), so I imagine if there were any 64-bit-cleanliness issues, they would have heard about them by now. That is not to discount your point, which could very well be correct, but it's out of OSG's hands anyways. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with .3ds files.
Alberto Luaces wrote:
El Friday 04 January 2008 11:20:30 omkaranathan r escribió:
Hi all,
I am trying to load some .3ds files in OSG. The model becomes white in
colour when I turn off the lighting. Is this a known issue with .3ds files
or is it that I am doing something wrong? I am attaching the .3ds file.
Thanks
Om
I think it's fine. If you convert the model to a .osg file through the osgconv
program, you'll see that only materials are defined. When you disable
lighting, you are discarding OpenGL materials, and using the OpenGL colour
instead, which is white by default. See on the state set of every part of
your model:
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
DataVariance STATIC
ColorMode OFF
ambientColor 0 0 0 1
diffuseColor 0.701961 0.635294 0.576471 1
specularColor 0 0 0 0.4
emissionColor 0 0 0 1
shininess 51.2
}
Alberto
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Thanks for the suggestion.
Is there any tool available to transfer the per-vertex material colour
to OpenGL colour(instead of default white) while converting to any of
the OSG supported formats?
Or is there any other way by which I can overcome this?
Thanks .
Om.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
