[osg-users] utf-8?
Can the scenegraph represent utf-8 on the screen? -- Mr. Johan Johnsson AutoSim AS, Strandveien 106, 9006 Tromsø Visit us at http://www.autosim.no ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgconv and missing textures
Hi Justim, I'm afraid there is no support for this, the filename is part of the osg::Image object, and if the readImageFile fails due to no texture being found then it'll just pass back a NULL. You could possibly use a Registry::ReadFileCallback to catch all readImage calls and create a dummy osg::Image and assign a name for every time that it fails. Robert. On Nov 20, 2007 11:37 PM, KSpam [EMAIL PROTECTED] wrote: When running osgconv, textures that are not found or that are missing plugins will not be added to the resulting OSG file. Is there a way to force the writer to add the texture name into the output file? Often times, I receive models with incorrect texture names. In one case, I have a 3DS file with textures that are missing extensions (i.e. filename instead of filename.jpg or filename.JP instead of filename.JPG). Since OSG plugins are used based on the file extension, there are no plugins that will match the texture file. If there is a way to force the texture names to the output file, I could easily hand-edit the OSG file to fix the texture names. Thanks, Justin ___ 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] crash in GL2Extensions::glDeleteShader
Hi Sherman, On Nov 21, 2007 2:15 AM, sherman wilcox [EMAIL PROTECTED] wrote: Good call Robert. makeCurrent() was/is failing. If makeCurrent is failing then its either due to window itself having been already destroyed or another thread still hanging on to the context and not releasing it. I have added an if (makeCurrent()) { ... } into the GraphicsContext::close() method, hopefully this will avoid the crash. The close call won't clean up OpenGL objects, but these should in theory be cleaned up by the OpenGL driver on closing a graphics context anyway, at least on a well behaved one. I've attached modified GaphicsContext.cpp. Its also cehcked into OSG SVN. Robert. /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ #include stdlib.h #include osg/GraphicsContext #include osg/Camera #include osg/View #include osg/FrameBufferObject #include osg/Program #include osg/Drawable #include osg/FragmentProgram #include osg/VertexProgram #include OpenThreads/ReentrantMutex #include osg/Notify #include map #include sstream #include algorithm using namespace osg; / // // GraphicsContext static method implementations // static ref_ptrGraphicsContext::WindowingSystemInterface s_WindowingSystemInterface; void GraphicsContext::setWindowingSystemInterface(WindowingSystemInterface* callback) { s_WindowingSystemInterface = callback; osg::notify(osg::INFO)GraphicsContext::setWindowingSystemInterface() s_WindowingSystemInterface.get()\ts_WindowingSystemInterfacestd::endl; } GraphicsContext::WindowingSystemInterface* GraphicsContext::getWindowingSystemInterface() { osg::notify(osg::INFO)GraphicsContext::getWindowingSystemInterface() s_WindowingSystemInterface.get()\ts_WindowingSystemInterfacestd::endl; return s_WindowingSystemInterface.get(); } GraphicsContext* GraphicsContext::createGraphicsContext(Traits* traits) { if (s_WindowingSystemInterface.valid()) return s_WindowingSystemInterface-createGraphicsContext(traits); else return 0; } GraphicsContext::ScreenIdentifier::ScreenIdentifier(): displayNum(0), screenNum(0) {} GraphicsContext::ScreenIdentifier::ScreenIdentifier(int in_screenNum): displayNum(0), screenNum(in_screenNum) {} GraphicsContext::ScreenIdentifier::ScreenIdentifier(const std::string in_hostName,int in_displayNum, int in_screenNum): hostName(in_hostName), displayNum(in_displayNum), screenNum(in_screenNum) {} std::string GraphicsContext::ScreenIdentifier::displayName() const { std::stringstream ostr; ostrhostName:displayNum.screenNum; return ostr.str(); } void GraphicsContext::ScreenIdentifier::readDISPLAY() { const char* ptr = 0; if ((ptr=getenv(DISPLAY)) != 0) { setScreenIdentifier(ptr); } } void GraphicsContext::ScreenIdentifier::setScreenIdentifier(const std::string displayName) { std::string::size_type colon = displayName.find_last_of(':'); std::string::size_type point = displayName.find_last_of('.'); if (point!=std::string::npos colon==std::string::npos point colon) point = std::string::npos; if (colon==std::string::npos) { hostName = ; } else { hostName = displayName.substr(0,colon); } std::string::size_type startOfDisplayNum = (colon==std::string::npos) ? 0 : colon+1; std::string::size_type endOfDisplayNum = (point==std::string::npos) ? displayName.size() : point; if (startOfDisplayNumendOfDisplayNum) { displayNum = atoi(displayName.substr(startOfDisplayNum,endOfDisplayNum-startOfDisplayNum).c_str()); } else { displayNum = -1; } if (point!=std::string::npos point+1displayName.size()) { screenNum = atoi(displayName.substr(point+1,displayName.size()-point-1).c_str()); } else { screenNum = -1; } #if 0 osg::notify(osg::NOTICE) hostName [hostName]std::endl; osg::notify(osg::NOTICE) displayNum displayNumstd::endl; osg::notify(osg::NOTICE) screenNum screenNumstd::endl; #endif } class ContextData { public: ContextData(): _numContexts(0) {} unsigned int _numContexts; void incrementUsageCount() { ++_numContexts; } void decrementUsageCount() { --_numContexts;
Re: [osg-users] STLport and OSG on windows?
Hi, It might be easier just to dual boot linux and then use linux as a way of testing things with a totally different environment. Testing on multiple OS with multiple compilers is a good way to shake down bugs. Robert. On Nov 21, 2007 5:14 AM, [EMAIL PROTECTED] wrote: Has anyone else ported an OSG project from the standard library that ships with visual studio 8 to STLport? Are there any bugaboos with doing this? Do the OSG dll's need to be completely recompiled, or will they place nice with STLport even though they were compiled with the default standard library? Is it worthwhile to even bother? We are having serious threading issues that look like lock-contention that occurs occasionally when multiple threads are doing OSG stuff; in the debugger, it looks like this occurs when these threads are all in the standard library (especially, during iterator destruction), so we are hoping that moving to STLport might fix this. ___ 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] Mixing GL
There's a pretty good example here of mixing systems. You could apply it either way around.. The way I have gnerally done it is to put OSG inside the other applications loop. http://www.3drealtimesimulation.com/osg/osg_faq_1.htm#f40 Not sure how deprecated it is now, but worked for me not so long ago.. Kind regards, Stephen. On Nov 21, 2007, at 6:49 AM, Paul Martz wrote: Have you tried pushing and popping around the call to your OpenGL code? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ 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] utf-8?
Hi Johan, Did you check that the font file itself does include the glyphs that you try to display ? Also, try to pass your input data as a wide character string, i.e. Lلْعَرَبيّة I have a similar problem in the past and solved it using wchar_t strings in my source files, and using a different font that actually had the glyphs. Hope this helps Thibault On Nov 21, 2007 1:15 PM, Johan Johnsson [EMAIL PROTECTED] wrote: I may be doing this wrong, because its just showing some wierd letters: osgText::Text* text1 = new osgText::Text; osgText::String* string = new osgText::String(لْعَرَبيّة, osgText::String::ENCODING_UTF8); std::string test = string-createUTF8EncodedString(); On Wed, 21 Nov 2007 10:50:39 +0100, Robert Osfield [EMAIL PROTECTED] wrote: On Nov 21, 2007 9:04 AM, Johan Johnsson [EMAIL PROTECTED] wrote: Can the scenegraph represent utf-8 on the screen? You mean does osgText support UTF-8 encoding of strings? The answer is yes, have a look at osgText::String for details. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mr. Johan Johnsson AutoSim AS, Strandveien 106, 9006 Tromsø Visit us at http://www.autosim.no ___ 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] utf-8?
tnx very much -the problem was the font. On Wed, 21 Nov 2007 13:24:47 +0100, Thibault Genessay [EMAIL PROTECTED] wrote: Hi Johan, Did you check that the font file itself does include the glyphs that you try to display ? Also, try to pass your input data as a wide character string, i.e. Lلْعَرَبيّة I have a similar problem in the past and solved it using wchar_t strings in my source files, and using a different font that actually had the glyphs. Hope this helps Thibault On Nov 21, 2007 1:15 PM, Johan Johnsson [EMAIL PROTECTED] wrote: I may be doing this wrong, because its just showing some wierd letters: osgText::Text* text1 = new osgText::Text; osgText::String* string = new osgText::String(لْعَرَبيّة, osgText::String::ENCODING_UTF8); std::string test = string-createUTF8EncodedString(); On Wed, 21 Nov 2007 10:50:39 +0100, Robert Osfield [EMAIL PROTECTED] wrote: On Nov 21, 2007 9:04 AM, Johan Johnsson [EMAIL PROTECTED] wrote: Can the scenegraph represent utf-8 on the screen? You mean does osgText support UTF-8 encoding of strings? The answer is yes, have a look at osgText::String for details. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mr. Johan Johnsson AutoSim AS, Strandveien 106, 9006 Tromsø Visit us at http://www.autosim.no ___ 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 -- Mr. Johan Johnsson AutoSim AS, Strandveien 106, 9006 Tromsø Visit us at http://www.autosim.no ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] utf-8?
I may be doing this wrong, because its just showing some wierd letters: osgText::Text* text1 = new osgText::Text; osgText::String* string = new osgText::String(لْعَرَبيّة, osgText::String::ENCODING_UTF8); std::string test = string-createUTF8EncodedString(); On Wed, 21 Nov 2007 10:50:39 +0100, Robert Osfield [EMAIL PROTECTED] wrote: On Nov 21, 2007 9:04 AM, Johan Johnsson [EMAIL PROTECTED] wrote: Can the scenegraph represent utf-8 on the screen? You mean does osgText support UTF-8 encoding of strings? The answer is yes, have a look at osgText::String for details. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mr. Johan Johnsson AutoSim AS, Strandveien 106, 9006 Tromsø Visit us at http://www.autosim.no ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hiding the Mouse Pointer
From osgcatch, osgphotoalbum, and osgstereoimage examples: // switch off the cursor osgViewer::Viewer::Windows windows; viewer.getWindows(windows); for(osgViewer::Viewer::Windows::iterator itr = windows.begin(); itr != windows.end(); ++itr) { (*itr)-useCursor(false); } On Nov 21, 2007 6:42 AM, Kim C Bale [EMAIL PROTECTED] wrote: How do you hide the mouse cursor in the viewer window? Cheers, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Hiding the Mouse Pointer
How do you hide the mouse cursor in the viewer window? Cheers, Kim.* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hiding the Mouse Pointer
My apologies, I should have checked. Thanks for the rapid response. K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Donald Cipperly Sent: 21 November 2007 12:58 To: OpenSceneGraph Users Subject: Re: [osg-users] Hiding the Mouse Pointer From osgcatch, osgphotoalbum, and osgstereoimage examples: // switch off the cursor osgViewer::Viewer::Windows windows; viewer.getWindows(windows); for(osgViewer::Viewer::Windows::iterator itr = windows.begin(); itr != windows.end(); ++itr) { (*itr)-useCursor(false); } On Nov 21, 2007 6:42 AM, Kim C Bale [EMAIL PROTECTED] wrote: How do you hide the mouse cursor in the viewer window? Cheers, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] KeyboardEventHandler interferes with MatrixManipulator selection
Hi folks I switched from OSG 2.0 to version 2.2 and stumbled over the keyboard handler. I add to my viewer some manipulators like in osgviewer: osgGA::KeySwitchMatrixManipulator* ksm = new osgGA::KeySwitchMatrixManipulator(); ksm-addMatrixManipulator( '1', Trackball, new osgGA::TrackballManipulator() ); ksm-addMatrixManipulator( '2', Flight, new osgGA::FlightManipulator() ); ksm-addMatrixManipulator( '3', Drive, new osgGA::DriveManipulator() ); ksm-addMatrixManipulator( '4', Terrain, new osgGA::TerrainManipulator() ); viewer.setCameraManipulator( ksm ); After that I add for example the stats handler and my own keyboard event handler (also like in the examples): viewer.addEventHandler( new osgViewer::StatsHandler ); viewer.addEventHandler( new KeyboardEventHandler ); KeyboardEventHandler looks like this: class KeyboardEventHandler : public osgGA::GUIEventHandler { public: KeyboardEventHandler() {} ~KeyboardEventHandler() {} virtual bool KeyboardEventHandler::handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter) { switch(ea.getEventType()) { case(osgGA::GUIEventAdapter::KEYDOWN): { KeyboardEventHandler::handle_keyboard((char)ea.getKey()); return true; } case(osgGA::GUIEventAdapter::KEYUP): { return true; } default: return false; } } virtual void KeyboardEventHandler::accept(osgGA::GUIEventHandlerVisitor v) { v.visit(*this); } virtual void KeyboardEventHandler::handle_keyboard(char lastkey) { switch (lastkey) { case('x'): { std::cout x std::endl; break; } default: std::cout - ' lastkey ' ( (int)lastkey ) isn't maped jet std::endl; break; } }; }; If I press in the running app the key 'x', x is printed. If I press 's' I see the stats. But if I press '1', '2', '3' or '4' nothing happens, the manipulators don't switch. Without adding my own handler to the viewer I can press '3' and drive around, pressing 's' and viewing stats (and of cause don't print x). Can somebody tell me why a self-made keyboard handler in OSG 2.2 stops only the manipulators from switching and how to cure this problem (working on WinXP SP2)? Looking forward to your answers. -- Andreas Richter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KeyboardEventHandler interferes with MatrixManipulator selection
Hi Andreas, The KeySwitchMatrixManipulator only handles events that havent' already been handled, and in your case you are signalling that you've handled the event by returning true from your own handler. Just return false and the key switch handler with work with it just fine. Robert. On Nov 21, 2007 2:49 PM, [EMAIL PROTECTED] wrote: Hi folks I switched from OSG 2.0 to version 2.2 and stumbled over the keyboard handler. I add to my viewer some manipulators like in osgviewer: osgGA::KeySwitchMatrixManipulator* ksm = new osgGA::KeySwitchMatrixManipulator(); ksm-addMatrixManipulator( '1', Trackball, new osgGA::TrackballManipulator() ); ksm-addMatrixManipulator( '2', Flight, new osgGA::FlightManipulator() ); ksm-addMatrixManipulator( '3', Drive, new osgGA::DriveManipulator() ); ksm-addMatrixManipulator( '4', Terrain, new osgGA::TerrainManipulator() ); viewer.setCameraManipulator( ksm ); After that I add for example the stats handler and my own keyboard event handler (also like in the examples): viewer.addEventHandler( new osgViewer::StatsHandler ); viewer.addEventHandler( new KeyboardEventHandler ); KeyboardEventHandler looks like this: class KeyboardEventHandler : public osgGA::GUIEventHandler { public: KeyboardEventHandler() {} ~KeyboardEventHandler() {} virtual bool KeyboardEventHandler::handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter) { switch(ea.getEventType()) { case(osgGA::GUIEventAdapter::KEYDOWN): { KeyboardEventHandler::handle_keyboard((char)ea.getKey()); return true; } case(osgGA::GUIEventAdapter::KEYUP): { return true; } default: return false; } } virtual void KeyboardEventHandler::accept(osgGA::GUIEventHandlerVisitor v) { v.visit(*this); } virtual void KeyboardEventHandler::handle_keyboard(char lastkey) { switch (lastkey) { case('x'): { std::cout x std::endl; break; } default: std::cout - ' lastkey ' ( (int)lastkey ) isn't maped jet std::endl; break; } }; }; If I press in the running app the key 'x', x is printed. If I press 's' I see the stats. But if I press '1', '2', '3' or '4' nothing happens, the manipulators don't switch. Without adding my own handler to the viewer I can press '3' and drive around, pressing 's' and viewing stats (and of cause don't print x). Can somebody tell me why a self-made keyboard handler in OSG 2.2 stops only the manipulators from switching and how to cure this problem (working on WinXP SP2)? Looking forward to your answers. -- Andreas Richter ___ 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] OSG book sale, and OSG training
Hi folks -- I have a small number of OSG books on hand to sell directly through my Web page at http://www.skew-matrix.com. I'd like to clear out my inventory by the end of the year. So, while supplies last, I'll pay the shipping charge. Just go to http://www.skew-matrix.com, select Books, and place your order. Your shipping charge will be zero. Unfortunately, I can't service orders outside the US at this time, so this offer is made to shipping destinations within the US only. While you're there looking at the books, please also take a look at the latest OSG Training course description. Just click on the Training link. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GL
yup. I might be missing something though. Don;'t know intelligent way to do other than to push each mode,attr, then pop them. Is there an overall one? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 20, 2007 5:50 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Mixing GL Have you tried pushing and popping around the call to your OpenGL code? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] STLport and OSG on windows?
On Wednesday 21 November 2007 02:49:18 Robert Osfield wrote: It might be easier just to dual boot linux and then use linux as a way of testing things with a totally different environment. Testing on multiple OS with multiple compilers is a good way to shake down bugs. I have found that given the same hardware, the load time for files is literally double on Windows what it is on Linux. In my case, I am running a 64 bit Linux system and a 32 bit Windows system, which might account for some of the speed difference. However, I truly believe that the performance difference between Windows and Linux is primarily due to differences in the STL implementations, and I believe that STLport is the best way to fix that on Windows. I have put together some test projects (non-OSG) with STLport that show an approximate 30% improvement in load speed on Windows. STLport does provide a slight speed advantage on Linux as well, but the improvement is only a few percent. It is important to note that these results are based on release mode performance. Debug mode is much harder to characterize, as Microsoft STL and STLport both use checked STL implementations (a very good thing), and gcc does not (unfortunately). The STLport checked STL implementation seems to be more thorough, but it also runs slower than the Microsoft STL. Most of the STL is a header-only library. Many implementations allow setting defines to configure the implementation. Libraries and executables that rely on the STL and include STL types in the interface should be compiled with the same configuration. The checked STL configuration is not compatible with the optimized configuration. This is the reason why debug libraries are specifically required to link to debug executables in Windows. On Linux with the gcc STL, it is not a problem to link release libraries to a debug executable. A change in STL implementation (on any platform) will require rebuilding all libraries that utilize an interface with STL types. For instance, OSG passes std::string as part of its interface; therefore is has a STL interface. On the other hand, QT has its own string class. As far as I can tell, QT would not have to be recompiled with STLport support, but OSG would. I am still trying to get funding in order to do a porting effort to STLport in our software. If that happens, I will be able to provide better numbers. Justin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GL
Never mind, just read stephen's post Haven't tried yet though. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Wednesday, November 21, 2007 10:33 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Mixing GL yup. I might be missing something though. Don;'t know intelligent way to do other than to push each mode,attr, then pop them. Is there an overall one? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 20, 2007 5:50 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Mixing GL Have you tried pushing and popping around the call to your OpenGL code? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixing GL
The FAQ is for 1.2 http://www.vis-sim.com/osg/osg_faq_1.htm#f40 so it may be different for 2.x not, I'm still stuck on 1.2 until the new year But you can push all bits along the lines of glPushAttrib( GL_ALL_ATTRIB_BITS ); glMatrixMode( GL_PROJECTION ); glPushMatrix(); glMatrixMode( GL_TEXTURE ); glPushMatrix(); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); // // // Your code here... // // // glMatrixMode( GL_TEXTURE ); glPopMatrix(); glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Wednesday, November 21, 2007 11:33 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Mixing GL yup. I might be missing something though. Don;'t know intelligent way to do other than to push each mode,attr, then pop them. Is there an overall one? _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 20, 2007 5:50 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Mixing GL Have you tried pushing and popping around the call to your OpenGL code? -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Tuesday, November 20, 2007 3:29 PM To: OpenSceneGraph Users Subject: [osg-users] Mixing GL Hi all, What is the easiest way to protect myself from a GL app that I am calling that isn't cleaning up after itself? I think that it is changing the states or attrs, or vertex arrays or something, so that osg lazy eval gets messed up. We have called state::dirtyAllModes dirtyAllAttributes dirtyAllVertexArrays() but it doesn't seem enough. Maybe we are missing a state. Is there either a getAllStates() that we can call to do this to, or a disableLazyEval, or something? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and Threads
Hi all, I'm in the process of redesigning our OSG application (the current version is little better than a proof-of-principle prototype, and wasn't written by me) and I'm trying to sort out how the threads will interact. The application has to render imagery from one or more views of a common scene which is updated via a network connection. The rendered imagery will probably need to be delivered back over the network, either by reading back each frame or by using a separate video capture card. My current plan is to have a thread which interacts with the network and converts the packets into updates to the scene graph, then have a second thread which does the rendering, and possibly a third thread to readback and compress the imagery (though this may be done separately via a video capture card). I am also considering a fourth thread to do the scene management stuff, like applying updates from the network and loading models in the background, but I'm not sure how necessary this is. So my questions are as follows: Is my architecture sensible? - Is there a 'better' way to do it? - How closely should I integrate my application with OSG? From a design point of view I'm tempted to create lots of adapters or facades (ie do it properly), but as I will also be the one doing the implementation I'm not sure I can be bothered. How easy is it use OSG in a multi-threaded environment? - Do I need to provide my own mutual exclusion code when modifying the scene graph or is it already taken care of? I think I will need each of the viewpoints to be rendered to a separate window, what is the best mechanism for doing this? - Each view should use the same scene graph except they will each have a different set of render passes and some different shaders and uniforms, is this achievable, and how? - Will each view need to run in a separate thread, or can they all run in one thread? Are there performance implications either way? Thanks in advance for any help. Rob. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdot - a tool to generate a picture ofascenegraph'sstructure
Hi Alberto, There are docs to help with 32-64 migration, I don't remember now the name but there is a type for the pointers that is defined for both 32 and 64. ( in 64bit is the same size as unsigned long, not portable though ) -- Radu Mihai [EMAIL PROTECTED] On 16-Nov-07, at 4:06 AM, Alberto Luaces wrote: It doesn't compile out of the box on 64bit, because of the casts from pointer to 'unsigned int'. Changing those casts to 'unsigned long' works, but it is an ugly hack. El Thursday 15 November 2007 18:14:23 Mike Weiblen escribió: whups, moved it to http://osgtoy.svn.sourceforge.net/viewvc/osgtoy/osgtoy/trunk/application s/osgdot/ -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Thursday, November 15, 2007 10:58 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgdot - a tool to generate a picture ofascenegraph'sstructure -Original Message- On Nov 15, 2007 4:35 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Very cool! Maybe whip up a plugin Writer wrapper around it, permitting osgconv cow.osg cow.dot Then, what about enabling that osgdb_dot.dll plugin as a Reader as well? ;-O I love the sound of some one volunteering :-D Heh, more than you think: I put the source in the osgToy SVN for safekeeping and further refinement. I'm glad to move it to OSG core SVN later if you wish. See http://osgtoy.svn.sourceforge.net/viewvc/osgtoy/osgtoy/trunk/s rc/osgToy/ osgdot.cpp In the mean time, I'm glad to accept code submissions. Pls submit them via the osgToy SourceForge Tracker http://sourceforge.net/tracker/?group_id=139833 cheers -- mew osgdot.cpp___ 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] Creating shapes using Geometry
Hi, How do I create simple shapes, specifically spheres, cylinders and boxes using osg::Geometry? Can't find tutorials for that. Thanks. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating shapes using Geometry
Hi, You can take a look at the osg::ShapeDrawable and osg::Shape classes to draw simple objects such as spheres, cylinders, and boxes easily. For more complicated objects, you can build them using vertex arrays and osg::Geometry. Hope this helps. Will On Nov 21, 2007 4:58 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, How do I create simple shapes, specifically spheres, cylinders and boxes using osg::Geometry? Can't find tutorials for that. Thanks. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating shapes using Geometry
Also I still use these tutorials to remind me.. even on 2.0 and onwards they work. http://www.nps.navy.mil/cs/sullivan/osgtutorials/ Hope that helps. Stephen. On Nov 22, 2007, at 6:58 AM, Renan Mendes wrote: Hi, How do I create simple shapes, specifically spheres, cylinders and boxes using osg::Geometry? Can't find tutorials for that. Thanks. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org