Re: [osg-users] Automatic osg wrapper generation.
On 4/4/07, Jose Luis Hidalgo [EMAIL PROTECTED] wrote: Hi David, when one file change, only one file in the wrapper is regenerate so only one file to compile and do a link Amazing!! so forgive my proposal and turn it into a request for a new CMake building step as Luigi said. Using CMake would certainly be the line of least resistance. Automatically running genwrapper is not something one would want on by default though, as it itself is not a quick operation. Would it be possible to CMake to offer the option to rebuild the wrappers, or perhaps just warn the users that the wrappers could potentially be invalidated by a modification to a header. Either way I'd still put this as a lower priority, as the old build system didn't have anything like this and we survived albeit with the wrappers breaking occasionally. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Looking for Cygwin Hang but I need Plugins enlightenment
Hi Brian, The .rgb and .osg plugins are very similar - they both don't have any external dependencies beyond the core osg and osgDB libraries, they both registers their ReaderWriter's the same way. The only big difference is that the osg plugin registers a series of wrappers objects that pass on function pointers to osgDB. However, I wouldn't read too much in to this, as its in princple the same thing as the proxy used to the register the ReaderWriter. As a general background, the .osg and .rgb plugins are oldest plugins in the whole OSG project and have been heavily used by thousands of developers over half a dozen years and many different platforms, if there was some general problem lurking with osgDB and handling of these plugins we'd have seen it long ago. I suspect that the particular plugins and examples that you've picked up on as being problematic are not directly related to the issue at hand. Something is failing somewhere, but the symptoms of this failure that you see could well be somewhere completely different. The fact that all other platforms work fine, but Cygwin has a problem suggest to me either the Cygwin compiler or libs are at fault, or perhaps the build options on the OpenThreads/OSG side. This isn't a very positive place to find the cause of the problem - but it may well save you banging you head against a brick wall trying to look for problems that arn't there on the OSG side, it may soon be more productive to contact the Cygwin community for a solution. Perhaps one last experiment you could try is to set the env var OSG_THREADING = SingleThreaded Then try the examples. The other thing you could try is to use Mingw for compiling OpenThreads and the OSG. Robert. On 4/4/07, Brian Keener [EMAIL PROTECTED] wrote: I need some enlightenment on the osgPlugins and their usage. I am really inexperienced and C++ ( I can read some of it and debug some but not a good coder yet) and I'm in way over my head trying to find this hang in Cygwin but I am persistent. As previously mentioned about 50% of the OSG examples hang when terminating. I have used osghangglide (which closes cleanly) and osgviewer (which hangs) the most for testing. The little option Robert mentioned in another thread: OSG_NOTIFY_LEVEL=DEBUG help me see more of the OSG messages which I think points to a DynamicLibrary hanging on close. In the case of osghanglide you can see the DynamicLibrary cygosgdb_rgb.dll close and then the program continues terminating. I modified osgDB/DynamcLibrary.cpp to not only show the message that it was closing also when the function finished to also show that it did close as shown below. The mutex messages are also my additions just to show me where things might be hanging: Mutex unlocked for 0x1236a098 Mutex unlocked with status 0 Closing DynamicLibrary cygosgdb_rgb.dll Closing DynamicLibrary cygosgdb_rgb.dll succeeded Mutex destructing for 0x1236a098 Mutex 0x1236a098 was not locked so unlocking and deleting Mutex destruction completing for 0 via delete Now in the case of osgviewer cow.osg I get the following on exit: Mutex locked for 0x12367f28 Mutex unlocked for 0x12367f28 Mutex unlocked with status 0 Mutex locked for 0x12367f68 Mutex unlocked for 0x12367f68 Mutex unlocked with status 0 Closing DynamicLibrary cygosgdb_osg.dll Here you can see it trying to close a different dll cygosgdb_osg.dll but you never see my message that the close succeeded not do you see the program continue. You have to use task manager to kill it. Now at this point since I'm not to sure of the plugins I'm not sure where to look. What would be different about cygosgdb_rgb.dll vs cygosgdb_osg.dll. Any insight/enlightenment greatly appreciated. Now my guess is some part of osgviewer (or more like osgviewer using OSG) is using something in osgdb which uses the plugin and something is still active causing the thread but that's (I realize) a lot of somethings. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] quad buffer stereo + osgViewer + win32 + latest SVN
Hi Drew, The error makes me wonder if osgViewer isn't request or setting up the QUAD_BUFFER visual correctly. I'll have a browse through the source. Which platforms are you on? Robert. On 4/5/07, Drew Whitehouse [EMAIL PROTECTED] wrote: Hi all, Just wondering if anyone else is seeing this. I'm trying to achieve quad buffer stereo, but I'm getting this error after each frame - Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I'm setting up the stereo with osgViewer::Viewer viewer; osg::DisplaySettings::instance()-setStereo(true); osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::QUAD_BUFFER); If I don't set QUAD_BUFFER I get anaglyphic looking ok. Also, other non OpenSceneGraph quadbuffer stereo apps are working fine suggesting the graphics card (nVidia Quadro FX3000) is configured properly. Any ideas ? -Drew -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] How to provide secured access to a SceneGraph in multithread ?
Hi there... I think a lot of people are facing the same problem than me: - My application is multithreaded - I may use multiple 3D windows, with multiple views, based on a single OSG graph (multiple threads accessing the graph to draw) - I have a script thread performing modifications on the graph The only solution I figured out to prevent dead locks until now is to use a BIG mutex to prevent script execution while drawing a frame in a window... but, the performance are very low, so I really need to understand: What's the best solution for multithread access to an OSG graph ??? by the way, aren't visitors supposed to be able to traverse the graph without locking it before ?? regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Cound not find plugin to read objects from file...
Hi Christian, Could you forward the errors on OSX build to this list or the osg-build on. Eric Wing now has write permission on the Xcode project so will be able to update things. W.r.t not finding the plugin, then it'll be because the OSG isn't finding the plugins on your library path. I would have thought installing it would allow things to work without defining env vars. Perhaps an OSX expert can jump in here. As a general note I'd recommend using the SVN versions of OpenThreads and OpenSceneGraph as these are easier to grab updates incrementally. Robert. On 4/4/07, christian hresko [EMAIL PROTECTED] wrote: I just downloaded the latest tarballs and compiled everything under Mac OS X (there's still problems with the make file AND the Xcode project... it would be great if someone would fix this someday). So anyway, after fixing all the build problems, I tried running osgviewer and I get: Could not find plugin to read objects from file... filename here osgviewer worked fine before I downloaded these latest tarballs. I've 'installed' all the plugins in the System Libraries. Any ideas? Thanks. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] default parameters in OSG
Could anyone please tell me What's the default near, far clip plane in OSG? What's the default eye coordination in OSG? How can I reset them? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] How to provide secured access to a SceneGraph in multithread ?
Hi Emmanuel, The OSG does not support multi-threaded write at any time. The OSG does support single threaded write, and multi-threaded read only access where the single threaded write is done outside the rendering traversals (the cull and draw). With the advent of osgViewer we have a new threading model that relaxes this constraint and uses double buffering of the rendering backend data structures to facilitate threading of update and draw in a parallel with draw, with the overlap between the two such that the draw thread only releases the main thread once all the dynamic drawable and stateset's have been drawn. This threading model is rather orthogonal to your needs though. Visitors don't have any knowledge of mutexes in the scene graph so will carry on regardless of any mutexes you have unless you explictly use a visitor that checks them first. Use of mutexes is very expensive so should only be used when absolutely necessary - this is major reason for the approach the OSG uses to multi-threading - its deliberately light weight and efficient. Application level mutexes are fine as long as your not lock-unlock thousands of times a second. Robert. On 4/5/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hi there... I think a lot of people are facing the same problem than me: - My application is multithreaded - I may use multiple 3D windows, with multiple views, based on a single OSG graph (multiple threads accessing the graph to draw) - I have a script thread performing modifications on the graph The only solution I figured out to prevent dead locks until now is to use a BIG mutex to prevent script execution while drawing a frame in a window... but, the performance are very low, so I really need to understand: What's the best solution for multithread access to an OSG graph ??? by the way, aren't visitors supposed to be able to traverse the graph without locking it before ?? regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgUtil::SceneView cull() and draw() separated
Hi Emmanuel, I strongly recommend that you using osgViewer's support for multi-threading, it will manage multiple views onto one or more scene graphs safely. The only time that it isn't safe to modify the scene graph is when Viewer::renderingTraversals is running. One things I've considering is adding a read/writre mutex osgViewer::Scene which would facilate the types of operations that you wish to do. Robert. On 4/5/07, Emmanuel Roche [EMAIL PROTECTED] wrote: Hello again, I have another question concerning multithreading issues: for example, is it possible to : 1) lock a scene graph in thread 1 2) perform cull() with a sceneView 3) unlock the graph 4) lock the graph in thread 2 5) modify somthing (could be anything: a nodemask, an osgText::Text color, an attitude, etc...) 6) unlock the graph 7) lock the graph again in thread 1 8) perform draw() with the previous sceneView 9) unlock the graph ... this is the whole story of my life in fact... So any explanation on why this is safe or unsafe would be really helpful :-) regards, Emmanuel. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] default parameters in OSG
On 4/5/07, xiaoshuxing [EMAIL PROTECTED] wrote: Could anyone please tell me What's the default near, far clip plane in OSG? There isn't a default, the default is for the OSG to compute the near/far plane on each frame according to what geometry is in the view frustum. What's the default eye coordination in OSG? Do you mean the view matrix? The projection matrix? Using osgViewer::Viewer you simple do: viewer.getCamera()-setProjectionMatrix(..); viewer.getCamera()-setViewMatrix(..); Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] VirtualPlanetBuilder SVN build problem.
Hi Robert, I tried to build VirtualPlanetBuilder, which i checked from svn tree today.I got some errors and finally i managed to build it. The problems are in osgdem.cpp and are as follows 1.instead of using vpb/DataSet osgTerrain/DataSet is included as header. 2.instead of using vpb::DataSet::functions osgTerrain::DataSet::functions is used every where. So I just replaced osgTerrain with vpb everywhere in the file osgdem.cpp and also set the path of libvpb.so in make file and everything worked. People will not face this problem if they are not using the latest SVN version of OSG as old osgTerrain has file DataSet.cpp. Best Regards RJ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] VirtualPlanetBuilder SVN build problem.
Hi RJ, Sorry about this, it looks like I missed a SVN check in as I had already fixed all the build problems. A have just done a SVN check in so everything should now be fixed. Robert. On 4/5/07, RJ [EMAIL PROTECTED] wrote: Hi Robert, I tried to build VirtualPlanetBuilder, which i checked from svn tree today.I got some errors and finally i managed to build it. The problems are in osgdem.cpp and are as follows 1.instead of using vpb/DataSet osgTerrain/DataSet is included as header. 2.instead of using vpb::DataSet::functions osgTerrain::DataSet::functions is used every where. So I just replaced osgTerrain with vpb everywhere in the file osgdem.cpp and also set the path of libvpb.so in make file and everything worked. People will not face this problem if they are not using the latest SVN version of OSG as old osgTerrain has file DataSet.cpp. Best Regards RJ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Doing op Render
Hi Robert -- GraphicsContext.cpp and GraphicsWindow.cpp display lots of messages to notify level INFO that might better be displayed to DEBUG_INFO. The most offensive is Doing op, which is displayed once per frame when the render operation is executed. This makes it pretty much impossible to display one-shot messages to INFO and view it in the console before it scrolls off the top at high velocity. :-) While looking at the code, I encountered the following comment: // commenting out debug info as it was cashing crash on exit, presumable // due to osg::notify or std::cout destructing earlier than this destructor. This made me think that there was some reason you weren't using DEBUG_INFO (you had apparently encountered a crash). Yet, I've changed these files to all use DEBUG_INFO instead of INFO and I'm not experiencing a crash... I could submit these changes, but I'm not sure a blanket search and replace is in order, rather some messages should rightly be INFO and some others should be DEBUG_INFO, so I'm requesting you take a look at this when you have time and make the appropriate changes. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Doing op Render
Hi Paul, DEBUG_INFO hasn't ever caused crashes as far I'm aware, rather what was caused a crash before related to notify is that under OSX the destruction order can be that the standard io libraries are unloaded before various elements of the OSG are destructed, and this caused a crash when the OSG tries to using notify at any notification level. The debug warnings you are thinking of right now can certainly be changed to DEBUG_INFO or commented out, the later route would be the more efficient. These messages were really important while debugging the osgViewer library, but now its generally working well. I have commented these messages out and check this into SVN. Robert. On 4/5/07, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- GraphicsContext.cpp and GraphicsWindow.cpp display lots of messages to notify level INFO that might better be displayed to DEBUG_INFO. The most offensive is Doing op, which is displayed once per frame when the render operation is executed. This makes it pretty much impossible to display one-shot messages to INFO and view it in the console before it scrolls off the top at high velocity. :-) While looking at the code, I encountered the following comment:// commenting out debug info as it was cashing crash on exit, presumable // due to osg::notify or std::cout destructing earlier than this destructor. This made me think that there was some reason you weren't using DEBUG_INFO (you had apparently encountered a crash). Yet, I've changed these files to all use DEBUG_INFO instead of INFO and I'm not experiencing a crash... I could submit these changes, but I'm not sure a blanket search and replace is in order, rather some messages should rightly be INFO and some others should be DEBUG_INFO, so I'm requesting you take a look at this when you have time and make the appropriate changes. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Doing op Render
DEBUG_INFO hasn't ever caused crashes as far I'm aware, rather what was caused a crash before related to notify is that under OSX the destruction order can be that the standard io libraries are unloaded before various elements of the OSG are destructed, and this caused a crash when the OSG tries to using notify at any notification level. Always a fun problem to try to debug. :-) The debug warnings you are thinking of right now can certainly be changed to DEBUG_INFO or commented out, the later route would be the more efficient. These messages were really important while debugging the osgViewer library, but now its generally working well. I have commented these messages out and check this into SVN. Thanks! That'll clean the output stream up quite a bit. -Paul ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Next release of OpenSceneGraph, what version number?
Hi All, Originally I had planned for the next release of the OpenSceneGraph to be out in the later half of last year with a modest number of new features, but... for various different reasons this window of opportunity closed and the release wasn't made. Fast forward today, still I haven't had a break in work schedule that has allowed for me to push for release, throw in a few spanners like website migration, version control migration, build system migration, RSI etc, and we have a recipe for this major slippage in getting the release out. While time has moved on, development of the OSG certainly hasn't slowed, and rather than a couple of minor additions to the OSG between 1.2 and 1.3 we now have a slew of major changes. I have started to list these on the new LatestDevelopments page: http://www.openscenegraph.com/osgwiki/pmwiki.php/Documentation/LatestDevelopments This list isn't fully inclusive yet though... as I've missed out a few items already added, and few pending (please add items I've missed). Obviously highlights to all these changes are osgShadow, osgViewer, osgManipulator, refactoring of osgTerrain. All these changes rather dewarf the changes between 1.0, 1.1 and 1.2, so a minor version bump to 1.3 doesn't really capture the breadth of changes. These leads me to wonder if we shouldn't bump up a major version number, i..e go for 2.0. Thoughts? Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] osgTDS
Hi Guys, Do anybody know about the licensing of osgTDS as nothing is written in the TDSLoaders files. best regards RJ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] osgUtil::SceneView cull() and draw() separated
I think you need to be careful not to make any major changes to the scene graph during the cull/draw cycle. If you can queue up changes from thread 2, so that thread 1 (the thread with sync, update and frame) processes all of them between calls to sync and frame, you'll be safe. The update callbacks that can be attached to nodes work this way. In the past, I've implemented a mutex controlled queue that gets populated with update callbacks by external threads and gets processed/cleared during the update phase of the thread 1. Chase -Original Message- From: [EMAIL PROTECTED] on behalf of Emmanuel Roche Sent: Thu 4/5/2007 2:34 AM To: OSG Users Subject: [osg-users] osgUtil::SceneView cull() and draw() separated Hello again, I have another question concerning multithreading issues: for example, is it possible to : 1) lock a scene graph in thread 1 2) perform cull() with a sceneView 3) unlock the graph 4) lock the graph in thread 2 5) modify somthing (could be anything: a nodemask, an osgText::Text color, an attitude, etc...) 6) unlock the graph 7) lock the graph again in thread 1 8) perform draw() with the previous sceneView 9) unlock the graph ... this is the whole story of my life in fact... So any explanation on why this is safe or unsafe would be really helpful :-) regards, Emmanuel. winmail.dat___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] OSG Quick Start Guide - alpha release imminent
Hi Paul, Good to hear the QSG is nearing completion. In the spirit of making an alpha release of the QSG I guess it'd be useful to have an alpha release of the next release of the OSG itself, as I presume the QSG assumes the use several of the latest features. An alpha release of the OSG could be made quite soon, as long as we don't expect everything to be perfect ;-) Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Next release of OpenSceneGraph, what version number?
Hi Robert, 2007/4/5, Robert Osfield [EMAIL PROTECTED]: [...] All these changes rather dewarf the changes between 1.0, 1.1 and 1.2, so a minor version bump to 1.3 doesn't really capture the breadth of changes. These leads me to wonder if we shouldn't bump up a major version number, i..e go for 2.0. Thoughts? Robert. I would understand bumping to 2.0 as the drop of Producer/osgProducer by itself is a major API change. -- Mathieu ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] state bug workaround
So I finally found a workaround for that weird state bug. If I add an empty shader Program to the top of my scene like so: Program* rootprog = new Program; mRoot-getOrCreateStateSet()-setAttributeAndModes(rootprog, osg::StateAttribute::ON); Then I don't see the wrong shader getting applied anymore. So it seems that explicitly telling OSG to turn off shaders fixes the problem. Hey Robert, is that a good clue to where the problem might be? I still don't grok all the internals of the OSG state code well enough to figure this out. -- Terry Welsh - mogumbo 'at' gmail.com www.reallyslick.com | www.mogumbo.com ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] osgTDS real-time?
Hi Guys Just a beginners question about osgTDS and osg database. Lets say i have generated a terrain using osgdem with the following input. ./osgdem -t texture.tif -d height.dem -l 2 -o peg.ive -a pegout.osga. The tiles in my archive file pegout.osga are written with names peg_L0_X0_Y0_subtile.ive etc. Am i right ? Now if i want to use this terrain database with osgTDS . Then the in the .TDS file, the Base element will be pegout.osga and the Terrain FileNamePattern=peg*.ive / Am i right ? best regards RJ . osgTDS currently makes a copy of the geometric data owned by a single Geometry object, processes it, then swaps the processed data for the old data. In this way, processing doesn't block any of the update/cull/draw traversals, allowing real-time rendering. However, the consequence of that is accumulated deformations will need to be done sequentially -- each new deformation will have to wait until processing of the previous deformation is complete. For snow plowing, I imagine you'd grow a linear deformation a vertex at a time as the plow moves, so it's possible that you might run into some latency there. If you can quickly modify a texture for snow plowing, then perhaps you could implement some combination that uses a texture while the geometry is processed in the background, which is displayed later. Is Phase III a possibility to this SBIR? There's no Phase III planned, but osgTDS is now open source, so anyone can do what they want with it, including adapting it for snow plowing. Both Don and I have new work lined up, and I can't speak for him but I might be available in the future for contract enhancements to osgTDS if necessary. I'm certainly available to answer questions at any time. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Looking for Cygwin Hang but I need Plugins enlightenment
Thank you Robert for you continued patience with me on this. Robert Osfield wrote: As a general background, the .osg and .rgb plugins are oldest plugins in the whole OSG project and have been heavily used by thousands of developers over half a dozen years and many different platforms, if there was some general problem lurking with osgDB and handling of these plugins we'd have seen it long ago. Yeah I sort of thought so. I suspect that the particular plugins and examples that you've picked up on as being problematic are not directly related to the issue at hand. Something is failing somewhere, but the symptoms of this failure that you see could well be somewhere completely different. yes I beleive you are right and the true issue may be exactly what was discussed in the thread : http://openscenegraph.net/pipermail/osg-users/2006-December/071664.html where a std::string issue was mentioned and of course other stuff regarding recompiling the libstdc++ and such (as well as changing to mingw). Last evening I finally figured out enough of gdb to get a break on dlclose and stepping through got the following which at least to me appears to correlate with a string issue. save you banging you head against a brick wall trying to look for problems that arn't there on the OSG side, it may soon be more productive to contact the Cygwin community for a solution. Banging my head is pretty much it. I'm pretty frustrated with my lack of knowledge on this and trying to fumble my way through - just because I got interested in FlightGear. The problem with tunring to the Cygwin community is they are not inclined to look for it as would be true of even you and osg with my Cygwin problem. I mean you give you pointer and assistance because you know Unix/Windows and you know OSG but I must find the problem and give a test case showing the fault and then someone might fix or I provide a patch. This is pretty much the case of all OpenSource unless the problem is in the mainline of development. Perhaps one last experiment you could try is to set the env var OSG_THREADING = SingleThreaded Then try the examples. tried it - osgviewer still hangs closing the cygosgdb_osg.dll The other thing you could try is to use Mingw for compiling OpenThreads and the OSG. Well the thing there is from what I've understood MingW is more of just the GNU Compiler and such for Windows where is Cygwin appears to be more of a Unix environment on windows that can handle windows and unix (within reason) type functionality but that is just my understanding. I'll keep digging. bk ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] state bug workaround
Hi Terry, On 4/5/07, Terry Welsh [EMAIL PROTECTED] wrote: So I finally found a workaround for that weird state bug. If I add an empty shader Program to the top of my scene like so: Program* rootprog = new Program; mRoot-getOrCreateStateSet()-setAttributeAndModes(rootprog, osg::StateAttribute::ON); Then I don't see the wrong shader getting applied anymore. So it seems that explicitly telling OSG to turn off shaders fixes the problem. Hey Robert, is that a good clue to where the problem might be? I still don't grok all the internals of the OSG state code well enough to figure this out. Its certainly another useful clue. In theory you shouldn't need to set an default Program to switch off GLSL programs, as osg::State should create one automatically for you when the first Program is applied. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Looking for Cygwin Hang but I need Plugins enlightenment
Well the thing there is from what I've understood MingW is more of just the GNU Compiler and such for Windows where is Cygwin appears to be more of a Unix environment on windows that can handle windows and unix (within reason) type functionality but that is just my understanding. I'll keep digging. Hi, what kind of thing do you want to do? I know both mingw and cygwin. In short: cygwin is a unix-emulation (kind of...) whereas mingw is a port of gnu-tools to windows. If you want do develop windows-apps, but use gnu-tools for it, use mingw. If you want to have a unix-emulation but for some kind of reason cannot use unix (linux, for instance), use cygwin. This dll-stuff sounds as if you would have to dig deep into the dark side of programming to solve it. Doesn´t sound like fun to me, I would try mingw. But tell me, what you want to do, and I can tell you if you can do it with mingw. Regards, Andreas ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Window resize events + Mouse position
Hey Eron, The code inside Producer::RenderSurface_Win32 that used to dispatch that event is commented out (I'm not sure why). When I uncomment it, the mouse coordinates get messed up because producer normalizes them before dispatching the mouse event to the osgGA KeyboardMouse callback, and the osgGA event queue also normalizes them against the window dimensions. Since the window dimensions default to 1x1, the normalize calculation in osgGA::EventQueue is a no-op, unless it gets the window resize event and updates the window dimension (perhaps that's why the resize event is no longer dispatch?). Hope that convoluted explanation helps :p Chase -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Eron Steger Sent: Thursday, April 05, 2007 12:17 PM To: osg-users@openscenegraph.net Subject: [osg-users] Window resize events + Mouse position Hello, I'm currently working with latest stable release of OSG (1.1), using osgProducer to render the scene. I would like to know if there is a way to determine when the window has been resized. I've tried handling the 'osgGA::GUIEventAdapter::RESIZE' event, but it doesn't appear to actually be called. Is this something that is (or planned to be) used in the SVN version with osgViewer? Also, when getting mouse events, it appears as though the maximum and minimum x/y positions are always 1 and -1. Is this different if you have multiple views of the same scene? Ideally I would like these coordinates to be in pixel space, but if that is no the intent I suppose I can still get the pixel using osgProducer::computePixelCoords. Thanks - Eron ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] question about osg::TexMat
Hi Tim, The OSG tracks OpenGL state via the osg::State object, there is one osg::State managed per graphics context. The osg::State tracks which StateAttributes are applied, and when a new one comes alone it clones a default constructed version of that StateAttribute and later uses this to apply the default state for that attribute for when the orignal attribute goes out of scope. In the case of TexMat, a default one should be the identity matrix. Robert. On 4/5/07, Tim Moore [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm looking at a bug in the FlightGear flight simulator in which all the textures on the ground and aircraft start sliding around. It seems to be related to the use of TexMat in some animations in the aircraft models. In looking at the code for TexMat, I don't see anything that would restore the texture matrix to identity for states that don't use the texture matrix at all. So, 1) am I confused, 2) is this a bug or 3) is the proper use of TexMat to attach a StateSet with an identity texture matrix at the root of the scene graph? Thanks, Tim - -- Red Hat France SARL, 171 Avenue Georges Clemenceau 92024 Nanterre Cedex, France. Siret n° 421 199 464 00056 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGFU3LeDhWHdXrDRURArASAJ4wBS0sdOI6nTDv6UF2r0Lf1Vr76ACfXoAg qTrC9ys8PkB9RAEmnGhqWYc= =oJu4 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] quad buffer stereo + osgViewer + win32 + latest SVN
Try to disable the stereo configuration for games (DirectX) and only leave enabled stereo configurantion in OpenGL. On 4/4/07, Drew Whitehouse [EMAIL PROTECTED] wrote: Hi all, Just wondering if anyone else is seeing this. I'm trying to achieve quad buffer stereo, but I'm getting this error after each frame - Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I'm setting up the stereo with osgViewer::Viewer viewer; osg::DisplaySettings::instance()-setStereo(true); osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::QUAD_BUFFER); If I don't set QUAD_BUFFER I get anaglyphic looking ok. Also, other non OpenSceneGraph quadbuffer stereo apps are working fine suggesting the graphics card (nVidia Quadro FX3000) is configured properly. Any ideas ? -Drew -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] quad buffer stereo + osgViewer + win32 + latest SVN
WinXP SP2, VS8, latest nVidia driver, latest SVN built using cmake I haven't got a linux machine set up for stereo at the moment, is anyone able to test this under linux ? If someone doesn't get to it sooner I'll set one up to test this after the Easter break, though I imagine the visual setup under windows is a completely different chunk of code. -Drew Which platforms are you on? Robert. -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] quad buffer stereo + osgViewer + win32 + latest SVN
Thanks Fabio, I'll look at this when I get back to my machine. I haven't installed the directx stereo stuff, so I think this probably isn't the problem. Also the fact that non osg opengl apps are working properly in stereo suggests that this probably isn't the problem. -Drew On 4/6/07, Fábio Mierlo [EMAIL PROTECTED] wrote: Try to disable the stereo configuration for games (DirectX) and only leave enabled stereo configurantion in OpenGL. On 4/4/07, Drew Whitehouse [EMAIL PROTECTED] wrote: Hi all, Just wondering if anyone else is seeing this. I'm trying to achieve quad buffer stereo, but I'm getting this error after each frame - Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I'm setting up the stereo with osgViewer::Viewer viewer; osg::DisplaySettings::instance()-setStereo(true); osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::QUAD_BUFFER); If I don't set QUAD_BUFFER I get anaglyphic looking ok. Also, other non OpenSceneGraph quadbuffer stereo apps are working fine suggesting the graphics card (nVidia Quadro FX3000) is configured properly. Any ideas ? -Drew -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] quad buffer stereo + osgViewer + win32 + latest SVN
I just looked at the osg submissions list and was delighted to see Laurens Voerman has just submitted a fix. Isn't open source development fantastic. Thanks Laurens :-) -Drew On 4/6/07, Drew Whitehouse [EMAIL PROTECTED] wrote: WinXP SP2, VS8, latest nVidia driver, latest SVN built using cmake I haven't got a linux machine set up for stereo at the moment, is anyone able to test this under linux ? If someone doesn't get to it sooner I'll set one up to test this after the Easter break, though I imagine the visual setup under windows is a completely different chunk of code. -Drew Which platforms are you on? Robert. -- Drew Whitehouse ANU Supercomputer Facility Vizlab -- Drew Whitehouse ANU Supercomputer Facility Vizlab ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] VS8 Express build problems
Hi Luigi (Calori) and others, There seems to be an issue with Visual Studio 8 Express 32 bit debug build. When I ran CMakeSetup (2.4.6) it created a VS 8 solution file for OpenSceneGraph but not for OpenThreads. I already had the existing VS 8 project files for OpenThreads, so I re-ran these to produce the OpenThreadsWin32d_s.lib file. Then I loaded the new OpenSceneGraph solution and since it was highlighted built the ALL_BUILD (debug) project. 11 of the projects failed to build. The build environment was invoked using the Microsoft Platform SDK for Windows Server 2003 R2 SetEnvLaunchWinXP32Debug.Cmd. The final statistics of the build were: 43 succeeded, 11 failed, 0 skipped Looking at just the osg build, I got osg - 48 error(s), 226 warning(s) All of these errors/warnings are due to a build conflict between OpenSceneGraph and OpenThreads, and I have no idea how to resolve the problem when everyone using VS8 Express seems to get a clean build. Suggestions? The one thing that comes to mind is reinstalling VS8 and the PSDK, but I am just not convinced that this will actually fix anything. One other point - where is the Mike 3dparty dependency package held? Regards PhilT My VS8 Express includes SP1. == Typical VS8 Express build errors -- do VS8 Standard Professional editions suffer the same problem? == 2msvcprtd.lib(MSVCP80D.dll) : error LNK2005: public: __thiscall std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ::~basic_stringchar,struct std::char_traitschar,class std::allocatorchar (void) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]) already defined in OpenThreadsWin32d_s.lib(Win32Thread.obj) == 2LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library == 2dxtctool.obj : warning LNK4217: locally defined symbol [EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z (public: __thiscall OpenThreads::Barrier::Barrier(int)) imported in function public: __thiscall std::_Treeclass std::_Tset_traitsclass osg::ref_ptrclass osg::Program::PerContextProgram const ,struct std::lessclass osg::ref_ptrclass osg::Program::PerContextProgram const ,class std::allocatorclass osg::ref_ptrclass osg::Program::PerContextProgram const ,0 ::~_Treeclass std::_Tset_traitsclass osg::ref_ptrclass osg::Program::PerContextProgram const ,struct std::lessclass osg::ref_ptrclass osg::Program::PerContextProgram const ,class std::allocatorclass osg::ref_ptrclass osg::Program::PerContextProgram const ,0 (void) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@ osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@osg@@@osg@@@std@@V?$a [EMAIL PROTECTED]@[EMAIL PROTECTED]@osg@@@osg@@@[EMAIL PROTECTED]@@std@@@ std@@[EMAIL PROTECTED]) == 2TextureRectangle.obj : warning LNK4049: locally defined symbol [EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z (public: __thiscall OpenThreads::Barrier::Barrier(int)) imported == -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Luigi Calori Sent: 04 April 2007 11:14 To: osg users Subject: Re: [osg-users] cmake and VS8 Robert Osfield wrote: Hi philip: I work with VS 7.1, I do like that: 1) checkout OpenThreads and OpenSceneGraph under the same parent dir (this is not strictly required, just common practice) 2) make a common install dir where to install OT and OSG 3) create two empy building dir for OT and OSG 4) configure (using CmakeSetup) OT with install prefix set up to common install 5) open generated VS projects inside OT build dir, build the Install target (I suggest do it in both Debug and Release, so to build and iinstall both) 6) download and expand Mike 3dparty dependency package side to OT and OSG sources 7) configure (using CmakeSetup) OSG with install prefix set up to common install, use the Gui to eventually select optinal parts (examples,wrappers) 8) open VS .sln solution in OSG build dir and build target you like. I'm trying to set up a script to automatixe these steps, I ' ll post when available, let me know weather this is setup could fit your needs. I' m also trying to automatically building .bat setup to set env-var for running examples. Regards Luigi Hi Philip, On 4/3/07, Philip Taylor [EMAIL PROTECTED] wrote: Just setting the source code and build directories to the top level OSG directory was indeed the answer. (It still failed because I have to add the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY environmental variables, but it got well beyond the SETUP_PLUGIN problem.) I believe that if you have OpenThreads and OpenSceneGraph placed in the same directory then the CMake scripts for finding OpenThreads should find it. Perhaps Luigi can jump in here as he's the author of much of the Windows side. Robert.
