Re: [osg-users] Geometry kernels?
Hi Cory, What do you mean by "geometry engine"? I guess you'll be able to easily create a kind of exporter that converts your geometry to an OSG/OpenGL one. Perhaps geometries would even be directly read and added to Geodes. I don't know HOOPS, but be aware that OSG is "only" (!) a scene graph (with many features and plugins), but not a CAD/infrastructure/mining/whatever software. Please tell us if you find useful things. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 07 Jan 2009 16:44:15 +0100, Cory Riddell a écrit: > I'm looking for comments and suggestions for using OSG with a geometry > engine like ACIS, Parasolid, or Open Cascade. Can they work well > together? Is it a useful combination? The application is CAD-like and > involves interactively building up a model from discrete components. > > I found OSG when looking for HOOPS competitors. Is it fair to compare > HOOPS with OSG? > > Thanks, > Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hi Robert, Matthew et al., IMHO, the "!=0" syntax in a "if" statement is the most portable. I know "if ((a=b)!=0)" does not generate warning under MSVC and GCC. So I guess it would be the same for "if ( (a = fxn()) != 0 )". For my part, I always use the "!=0" syntax... and I avoid as much as possible the affectations in a "if" statement by splitting the instruction. :) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 07 Jan 2009 17:51:58 +0100, Robert Osfield a écrit: > Hi Matthew, > > On Wed, Jan 7, 2009 at 4:36 PM, Matthew Fuesz wrote: >> Blanket-supression of C4706 isn't really a good thing, since as you pointed >> out, it can actually point out an error (usually a typo by the developer). >> C4706 will not be generated if it is made explicitly clear what the intent >> of the conditional is. >> >> i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 >> )". This is covered in the MSDN page on C4706. >> >> I actually prefer the latter syntax (which doesn't generate C4706) anyway, >> since it eliminates any possible confusion as to the intended operations. > > All the instances if assignment in condtionaly already have a () added > around the conditional to avoid the warning under gcc, I had hoped > that this would be the end of it... but no... > > Personally I've got others things to chase up right now that are more > important than adding more superfluous code to the OSG to fix silly > warnings that have no relevance to fixing bugs in the OSG. Feel free > to dive in if you feel so inclined, otherwise I'll be happy to stick > with the surpression of this warning under VS. > > 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] getYnormalized() and camera transforms
Hi Robert, The behaviour you describe is exactly what I was hoping for: x in the range -3 to +3 and y -1 to +1. But that's not what I get. I've created a small program derived from the osgcamera example. It builds three panels: left looks at -90 degrees, middle straight ahead, and the right panel at +90. Everything works as expected moving the cow model using your Trackball manipulator. The program also spits out the normalized xy values into the shell window on each frame. The middle panel behaves as one would expect for a scaled viewport: x -.33 to +.33 and y -1 to +1. But move the mouse into the left or right viewport and the numbers are all over the place. Funny, because the manipulator works just fine. Any ideas? Thanks, Guy -- #include #include #include #include class ModelHandler : public osgGA::GUIEventHandler { public: ModelHandler(){} bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa) { switch(ea.getEventType()) { case(osgGA::GUIEventAdapter::FRAME):{ printf("%f %f\n", ea.getXnormalized(), ea.getYnormalized()); return true; } default: break; } return false; } }; void multipleWindowMultipleCameras(osgViewer::Viewer& viewer) { osg::GraphicsContext::WindowingSystemInterface* wsi = osg::GraphicsContext::getWindowingSystemInterface(); unsigned int width=1000, height=600; unsigned int numCameras = 3; double aspectRatioScale = (double)numCameras; double translate_x = double(numCameras)-1; for(unsigned int i=0; i traits = new osg::GraphicsContext::Traits; traits->screenNum = 0; traits->x = (i*width)/numCameras; traits->y = 0; traits->width = width/numCameras-1; traits->height = height; traits->windowDecoration = false; traits->doubleBuffer = true; traits->sharedContext = 0; osg::ref_ptr gc = osg::GraphicsContext::createGraphicsContext(traits.get()); osg::ref_ptr camera = new osg::Camera; camera->setGraphicsContext(gc.get()); camera->setViewport(new osg::Viewport(0,0, width/numCameras, height)); GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT; camera->setDrawBuffer(buffer); camera->setReadBuffer(buffer); viewer.addSlave(camera.get(), osg::Matrix::scale(aspectRatioScale, 1.0, 1.0), osg::Matrix::rotate(osg::inDegrees(-90.0f+90.0f*i),0.0f,1.0f,0.0f)); } } int main( int argc, char **argv ) { osgViewer::Viewer viewer; osg::ref_ptr loadedModel; ModelHandler* modelHandler = new ModelHandler; multipleWindowMultipleCameras(viewer); viewer.setCameraManipulator( new osgGA::TrackballManipulator()); loadedModel = osgDB::readNodeFile("cow.osg"); viewer.setSceneData(loadedModel.get()); viewer.addEventHandler(modelHandler); viewer.realize(); while(!viewer.done()) { viewer.frame(); } return 0; } ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] High resolution screencast
I tried it but I encountered few problems. I will send you the detailed tomorrow. Still thanks for the tip. On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles wrote: > Not trying to hijack this thread--and I can't really read it all for now > because I'm still fighting off lots of complications from a recent oral > surgery--but what you want is called "bugle." I used it to make all of > the old osgWidget and osgPango videos and it works like a charm. > > What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a > version that shimmies off data to ffmpeg for encoding. Simple, clean, > and easy for basic usage. > > On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote: > > Hi, > > > > I apology in advance if this thread have been heavily answered before > > (if so just tell where I can find the solution). Still I would like to > > know the different alternative (the good ones) to record a video of my > > scene. > > So far I was using an external tool for screenCast (called istanbul). > > But I'm not satisfied by this because when my scene is very complex, > > my osg based application is lagging and this leads to a poor quality > > of th video. > > > > I'm especially interested if there is a way to create an > > RecordCameraPathHandler to record a path, and then instead of saving > > it as a .path file compute the video in a batch mode. By batch mode I > > mean that the creation of the video doesn't need to be real time. In > > that way I could hopefully control the lag effects and eventually the > > resolution of the video. > > > > Sincerely, > > > > -- > > Loïc Simon > > ___ > > 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 > -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osganimationskinning broken?
Hi Roland, I updated osgAnimation and if forget to update this example, all others have been tested and it should work with updated data. Robert did you commited the updated data in the trunk ? Else if not yet updated data of osgAnimation are here http://hg.plopbyte.net/osg-data/ you can grab this mercurial repository to get new osgAnimation data. Yes now UpdateCallback are not set in the constructor, so a explicit call has to be made, that why this example segfault. I will fix the example tomorrow. Thank you for the report Cheers, Cedric Roland Smeenk wrote: Is it me or is osganimationskinning broken? line 198: Code: osgAnimation::AnimationUpdateCallback* cb = dynamic_cast(right0->getUpdateCallback()); returns NULL, because the updatecallback was never set. This is easily fixed, but then I run into the problem that the SkinGeometry is not updated. The bones move OK. -- Roland -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4267#4267 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Head mounted display for OSG...
David, Thanks for that feedback. This will help out...:) -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Spilling Sent: Wednesday, January 07, 2009 3:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Head mounted display for OSG... Shayne, We use these (http://www.vuzix.com/iwear/products_vr920.html) experimentally, because they are cheap, and slightly surprisingly support quad buffer stereo, which means they more or less work with OSG (on Nvidia Quadro's, at least) straight out of the box. Unfortunately, most of our in-house OSG apps hijack the camera in one way or another and assume that they are not being run stereo, so all goes a bit awry. Work in progress... David smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Head mounted display for OSG...
Shayne, We use these (http://www.vuzix.com/iwear/products_vr920.html) experimentally, because they are cheap, and slightly surprisingly support quad buffer stereo, which means they more or less work with OSG (on Nvidia Quadro's, at least) straight out of the box. Unfortunately, most of our in-house OSG apps hijack the camera in one way or another and assume that they are not being run stereo, so all goes a bit awry. Work in progress... David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Your recommendation below seems like it would depend on what type fxn() returns, am I correct? For example, if fxn() returns an int (and 'a' is declared as an int), then the following is correct: "if ( (a = fxn()) != 0 ) But the above is incorrect - and possibly inefficient - if fxn() returns a bool (and 'a' is declared as a bool), because that code would causes a bool to be compared against an int (0). If fxn() returns a bool, the following should be sufficient (and should not generate a warning IMHO): "if ( a = fxn() )" This is off topic for a scene graph mailing list, but I would like to prevent someone from going through the code and doing a blanket replace of good code with bad code. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Matthew Fuesz Sent: Wednesday, January 07, 2009 9:36 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Warning level Skylark (J-S) wrote: > > I'm fine with suppressing C4706 as it's true that it's a warning that > only tells you that you *might* be doing something unsafe... Whether > it's actually safe or not is totally context-dependent. > Blanket-supression of C4706 isn't really a good thing, since as you pointed out, it can actually point out an error (usually a typo by the developer). C4706 will not be generated if it is made explicitly clear what the intent of the conditional is. i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 )". This is covered in the MSDN page on C4706. I actually prefer the latter syntax (which doesn't generate C4706) anyway, since it eliminates any possible confusion as to the intended operations. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4253#4253 ___ 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] osganimationskinning broken?
Is it me or is osganimationskinning broken? line 198: Code: osgAnimation::AnimationUpdateCallback* cb = dynamic_cast(right0->getUpdateCallback()); returns NULL, because the updatecallback was never set. This is easily fixed, but then I run into the problem that the SkinGeometry is not updated. The bones move OK. -- Roland -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4267#4267 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warnings in VS
Interesting. With current svn, I am able to toggle OSG_USE_AGGRESSIVE_WARNINGS from OFF to ON without deleting my cache. This seems to have fixed itself (I'm not using Mattias' fix). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, January 07, 2009 2:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Warnings in VS Hello Mattias, > Makes it kind of hard to test. Sorry about that. Trying again before > submitting the file to osg-submissions. Got the file, thanks. (third time's a charm right? ;-) ) I'll try it out tomorrow. > i didn't either at first. I was really trying to get my head around > the internal cache variables involved and things didn't behave as > expected. I have now tested this on linux with cmake-2.6.3-RCx and > there this problem doesn't exist. Btw I'm currently using > msvc90Express on Vista 32-bit and cmake-2.6.2. I'm on msvc8 but the rest is the same for me. It would be surprising if it was Linux itself that fixed the problem, so it must be cmake-2.6.3-RCx... I'll try downloading RC5 from http://www.cmake.org/files/v2.6/ and see. > Cool. And I'm working on a submission for the cpack stuff we talked > about before the holidays ;-) Excellent, I was just about to ask you if that was still planned or not... :-) Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warnings in VS
Hello Mattias, Makes it kind of hard to test. Sorry about that. Trying again before submitting the file to osg-submissions. Got the file, thanks. (third time's a charm right? ;-) ) I'll try it out tomorrow. i didn't either at first. I was really trying to get my head around the internal cache variables involved and things didn't behave as expected. I have now tested this on linux with cmake-2.6.3-RCx and there this problem doesn't exist. Btw I'm currently using msvc90Express on Vista 32-bit and cmake-2.6.2. I'm on msvc8 but the rest is the same for me. It would be surprising if it was Linux itself that fixed the problem, so it must be cmake-2.6.3-RCx... I'll try downloading RC5 from http://www.cmake.org/files/v2.6/ and see. Cool. And I'm working on a submission for the cpack stuff we talked about before the holidays ;-) Excellent, I was just about to ask you if that was still planned or not... :-) Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warnings in VS
Hi again, yes I forgot again. I'm terrible at this. Mattias On Wed, Jan 7, 2009 at 10:09 PM, Mattias Helsing wrote: > Hi J-S, > > On Wed, Jan 7, 2009 at 2:57 PM, Jean-Sébastien Guay > wrote: >> Hello Mattias, >> >> >> I'd like to test, but it seems you forgot to attach the file? > > Makes it kind of hard to test. Sorry about that. Trying again before > submitting the file to osg-submissions. > >> >>> I stumbled upon another problem with the aggresive warnings. I needed >>> to configure twice before a changed aggresive setting would take >>> effect because the changes to CMAKE_CXX_FLAGS are made after source is >>> processed. Have you seen this? >>> Actually this should be seen on any platform. Have people on other >>> platforms seen it? >> >> I didn't see this specifically, but didn't try either. I just changed the >> value, generated the project files and noticed that the actual compiler >> flags hadn't changed. I didn't think to click "configure" twice. > > i didn't either at first. I was really trying to get my head around > the internal cache variables involved and things didn't behave as > expected. I have now tested this on linux with cmake-2.6.3-RCx and > there this problem doesn't exist. Btw I'm currently using > msvc90Express on Vista 32-bit and cmake-2.6.2. > >> >> I'll investigate. > > Cool. And I'm working on a submission for the cpack stuff we talked > about before the holidays ;-) > > cheers > Mattias > >> >> J-S >> -- >> __ >> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com >> http://www.cm-labs.com/ >>http://whitestar02.webhop.org/ >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > IF(WIN32) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR) ELSE(WIN32) IF(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) ELSE(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR) ENDIF(APPLE) ENDIF(WIN32) if(COMMAND cmake_policy) # Works around warnings libraries linked against that don't # have absolute paths (e.g. -lpthreads) cmake_policy(SET CMP0003 NEW) # Works around warnings about escaped quotes in ADD_DEFINITIONS # statements. cmake_policy(SET CMP0005 NEW) # cmake-2.6.1 introduces policy cmp0008 decide how to treat full path libraries that do not appear to be valid library file names # quote from cvslog "Such libraries worked by accident in the VS IDE and Xcode generators in CMake 2.4 and below." if(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4 AND ${CMAKE_PATCH_VERSION} GREATER 0) cmake_policy(SET CMP0008 OLD) endif(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4 AND ${CMAKE_PATCH_VERSION} GREATER 0) endif(COMMAND cmake_policy) PROJECT(OpenSceneGraph) SET(OPENSCENEGRAPH_MAJOR_VERSION 2) SET(OPENSCENEGRAPH_MINOR_VERSION 7) SET(OPENSCENEGRAPH_PATCH_VERSION 8) SET(OPENSCENEGRAPH_SOVERSION 53) # set to 0 when not a release candidate, non zero means that any generated # svn tags will be treated as release candidates of given number SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 0) SET(OPENSCENEGRAPH_VERSION ${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION}) SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION}) SET(OSG_PLUGIN_PREFIX "") IF (CYGWIN) SET(OSG_PLUGIN_PREFIX "cygwin_") ENDIF(CYGWIN) IF(MINGW) SET(OSG_PLUGIN_PREFIX "mingw_") ENDIF(MINGW) # We want to build SONAMES shared librariess SET(OPENSCENEGRAPH_SONAMES TRUE) SET(OPENTHREADS_SONAMES TRUE) SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR}) # We have some custom .cmake scripts not in the official distribution. # Maybe this can be used override existing behavior if needed? SET(CMAKE_MODULE_PATH "${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH}") # Okay, here's the problem: On some platforms, linking against OpenThreads # is not enough and explicit linking to the underlying thread library # is also required (e.g. FreeBSD). But OpenThreads may be built with different # backends (Pthreads, Sproc, Windows) so we don't know what the underlying # thread library is because some platforms support multiple backends (e.g. # IRIX supports Sproc and Pthreads). Linking all libraries won't work # because the libraries may be incompatible. # So the current solution is to attempt best guess linking and exempt certain # cases. With IRIX, we're going to hope explicit linking to the underlying # library is not necessary. We currently don't case for pthreads on Windows # which might be an issue on things like Cygwin. This may need to be fixed. FIND_PACKAGE(Threads) IF(CMAKE_SYSTEM MATCHES IRIX) # Erase CMAKE_THREAD_LIBS_INIT and hope it works SET(CMAKE_THREAD_LIBS_INIT "" CACHE IN
Re: [osg-users] Warnings in VS
Hi J-S, On Wed, Jan 7, 2009 at 2:57 PM, Jean-Sébastien Guay wrote: > Hello Mattias, > > > I'd like to test, but it seems you forgot to attach the file? Makes it kind of hard to test. Sorry about that. Trying again before submitting the file to osg-submissions. > >> I stumbled upon another problem with the aggresive warnings. I needed >> to configure twice before a changed aggresive setting would take >> effect because the changes to CMAKE_CXX_FLAGS are made after source is >> processed. Have you seen this? >> Actually this should be seen on any platform. Have people on other >> platforms seen it? > > I didn't see this specifically, but didn't try either. I just changed the > value, generated the project files and noticed that the actual compiler > flags hadn't changed. I didn't think to click "configure" twice. i didn't either at first. I was really trying to get my head around the internal cache variables involved and things didn't behave as expected. I have now tested this on linux with cmake-2.6.3-RCx and there this problem doesn't exist. Btw I'm currently using msvc90Express on Vista 32-bit and cmake-2.6.2. > > I'll investigate. Cool. And I'm working on a submission for the cpack stuff we talked about before the holidays ;-) cheers Mattias > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with pointlightmanip.exe example?
Cory Riddell wrote: I've been running the pointlightmanip.exe example and as soon as I rotate even a tiny amount (using either the hand or the wheels), the top right sphere disappears. I've attached a screenshot but I suspect that will get filtered out by the list software. Is this an instance of http://www.vis-sim.com/osg/osg_faq_1.htm#f22 ? I'm seeing similar behavior with the plasmafun.exe sample as well. A section out of the torus is missing (or rather, it's there but flashes constantly). Any idea what this might be? Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgSWIG/Py available
All right! The best news, and just in time for my project. :-) Thanks Randolph Hartmut Seichter wrote: Dear OSG Community, first of all a late Happy New Year! The osgSWIG team is happy to announce osgSWIG/Py 0.9.1 for Python 2.6 which corresponds to the OpenSceneGraph 2.6.1 version. There is an installer for Win32/Python 2.6 or if you feel funky you can try to compile osgSWIG/Py straight from the source. Please note that on Windows we can only support you with Python 2.6 - hence build with Visual Studio 2008. And another note, we decided to only support stable releases, like 2.6.x or the upcoming 2.8.x releases as the maintenance of the interface files becomes more problematic. Be assured we are looking into some alternative ways to generate them :) For those users looking for an update of the version including osgART (http://www.osgart.org) - please be patient, we are working on the release of osgART 2.x and would like to keep things in sync - there will be an update but not right now. Please give the installer a spin - let us know of your problems in the issue tracker. Now, head over to http://code.google.com/p/osgswig/ Cheers, Hartmut -- Dr Hartmut Seichter, Post-Doctoral Research Fellow, Human Interface Technology Laboratory New Zealand ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Randolph Fritz design machine group architecture department university of washington rfr...@u.washington.edu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] atomic_xor_uint_nv on Solaris
I've not heard from Blasius Czink yet, but I have found out that there is a /usr/include/sys/atomic.h that declares things like atomic_or_uint_nv(), but does not declare atomic_xor_uint_nv(). Maybe the xor operation could be removed instead of the whole thing. I can't find any reference to xor in the header file. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the "and", "or" and "xor" features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37 lines >From Blasius Czink, "Among other things I added support for atomic operations on BSD-like systems and additional methods (for "and", "or", "xor"). " and a later post the same osg-submissions thread: "it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config. Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds." And another post from Blasius on this topic: "I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005. In case anyone is interested the lines: __MACHINEI(unsigned char _interlockedbittestandset(long *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b)) should be changed to: __MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b)) The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used. Which reminds me another small glitch in the Atomic header so I attached a corrected version. Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere. OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that. " ___ 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] Problem with pointlightmanip.exe example?
I've been running the pointlightmanip.exe example and as soon as I rotate even a tiny amount (using either the hand or the wheels), the top right sphere disappears. I've attached a screenshot but I suspect that will get filtered out by the list software. Is this an instance of http://www.vis-sim.com/osg/osg_faq_1.htm#f22 ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer aftersettingscene data
This issue is resolved with current svn of OSG. Thanks for the quick fix, Robert! Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Wednesday, January 07, 2009 9:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Bug in adding view to compositeViewer aftersettingscene data I also encountered this with one of my own test programs. I got around it by swapping the lines of code. I'll back that change out and test the latest. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 7:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Bug in adding view to compositeViewer after settingscene data Hi Alexandre, I've just fixed the problem and checked it in. Could you try out the svn version of the OSG. Thanks, Robert. On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric wrote: > Hi Robert, > > here is the modified example. > > 2009/1/7 Robert Osfield >> >> HI Alexandre, >> >> Could you post the modified example in the form that reproduces the crash. >> >> Thanks, >> Robert. >> >> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric >> >> wrote: >> > Hi osg-users and Happy New Year to all of you :-) >> > >> > I recently downloaded OSG 2.7.8 to link with my application (wich >> > was linked before with OSG 2.7.4) and I discovered a bug wich can >> > be easily produced by modifying osgcompositeviewer.cpp in Examples >> > osgcompositeviewer. >> > >> > At line 236 : >> > >> > osgViewer::View* view = new osgViewer::View; viewer.addView(view); >> > >> > view->setSceneData(scene.get()); >> > >> > replace by swapping 2 lines (setting scene data before adding new >> > view) >> > : >> > >> > osgViewer::View* view = new osgViewer::View; >> > >> > view->setSceneData(scene.get()); >> > viewer.addView(view); >> > >> > Be sure to run the example to call this code section... >> > >> > It crashes in osgViewer::View::setSceneData when calling >> > >> > getViewerBase()->getThreadingModel() >> > >> > because viewerbase is NULL >> > >> > With older version 2.7.4 it works, apparently not with new 2.7.8. >> > >> > I need my application to stay the same, setting data scene before >> > adding new view to the composite viewer, if you have any tips to do >> > this let me hear. >> > >> > -- >> > Alexandre AMALRIC Ingénieur R&D >> > === >> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille >> > http://www.pixxim.fr >> > >> > ___ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegra >> > ph.org >> > >> > >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph >> .org > > > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Head mounted display for OSG...
Can anyone give me an update on the maturity of the head mounted display support in OSG? Is it a work in progress? What is its capability? Any input or details would be appreciated. Also does anyone have a particular recommendation for a Head-mounted display brand or hardware that works well with OSG? Thanks, -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hi Matthew, On Wed, Jan 7, 2009 at 4:36 PM, Matthew Fuesz wrote: > Blanket-supression of C4706 isn't really a good thing, since as you pointed > out, it can actually point out an error (usually a typo by the developer). > C4706 will not be generated if it is made explicitly clear what the intent of > the conditional is. > > i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 > )". This is covered in the MSDN page on C4706. > > I actually prefer the latter syntax (which doesn't generate C4706) anyway, > since it eliminates any possible confusion as to the intended operations. All the instances if assignment in condtionaly already have a () added around the conditional to avoid the warning under gcc, I had hoped that this would be the end of it... but no... Personally I've got others things to chase up right now that are more important than adding more superfluous code to the OSG to fix silly warnings that have no relevance to fixing bugs in the OSG. Feel free to dive in if you feel so inclined, otherwise I'll be happy to stick with the surpression of this warning under VS. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Support for draw_instanced
Hi Paul and Lionel, In the implementation that I went for in osg::State for the required calls glDraw*Instanced*() calls I used a query for glDraw*Instanced and glDraw*InstancedEXT. glDraw*Instanced doesn't exist yet but the code will pick up on it when it comes along. We could add a check for glDraw*InstancedARB into the mix as well. There isn't presently any extension checking beyond the query for the function pointers. Robert. On Wed, Jan 7, 2009 at 4:24 PM, Paul Martz wrote: > Draw_instanced was promoted to an ARB extension in the OpenGL 3.0 timeframe > (last August), and I found it was only available as ARB in NVIDIA's beta > OpenGL 3.0 drivers. Rather than require OSG users to upgrade to beta drivers > to access this functionality, I opted to use the EXT version. > > Using EXT also simplifies the vertex shader. To use the ARB extension, I > would've been forced to use GLSL 1.3, which removes all the predefined > uniforms. It's a whole new world of shader development, and one I wasn't > quite ready to dive into given the non-existent funding for this feature. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > > From: osg-submissions-boun...@lists.openscenegraph.org > [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of > Lionel Lagarde > Sent: Wednesday, January 07, 2009 1:52 AM > To: OpenSceneGraph Submissions > Subject: Re: [osg-submissions] Support for draw_instanced > > Hi, > > Why you use the EXT version of draw_instanced. This extension has an ARB > version. > > Paul Martz wrote: > > Hi Robert -- My update and build of OSG went fine, and my draw instanced > test programs ported to your implementation smoothly. Thanks again for your > help on this great new feature of OSG. > > Hi to all -- Current svn head of OSG now supports EXT_draw_instanced. Check > out the osgdrawinstanced example, which creates a scene graph consisting of > a single Geode with a single Geometry with four vertices, but draws several > hundred quads at different orientations, positions, and colors. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > > -Original Message- > From: osg-submissions-boun...@lists.openscenegraph.org > [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of > Robert Osfield > Sent: Tuesday, January 06, 2009 9:14 AM > To: OpenSceneGraph Submissions > Subject: Re: [osg-submissions] Support for draw_instanced > > Hi Paul, > > On Tue, Jan 6, 2009 at 4:06 PM, Paul Martz wrote: > > > Especially thanks for placing the extension support check in State. I > disliked having it in the draw() method, but wasn't sure where it should > > > go. > > Extension checking/function call set up is both a strong and a weak point in > the OSG, there are motivations for centralising extension setup and > motivations for keeping them local to classes - so the OSG has ended up > doing both in different places, sometimes for good reasons, sometime for the > wrong reasons... It'd be nice to have a simpler and more manageable scheme > that avoids the issues of being pulled in different directions. OpenGL ES > and OpenGL 3.x into the mix will further complicate things unless we do come > up with a new scheme... > > > > I'm updating and building now. I'll let you know if I find any issues. > > > Thanks, > Robert. > ___ > osg-submissions mailing list > osg-submissi...@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. > org > > ___ > osg-submissions mailing list > osg-submissi...@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > __ Information provenant d'ESET NOD32 Antivirus, version de la base > des signatures de virus 3745 (20090107) __ > > Le message a été vérifié par ESET NOD32 Antivirus. > > http://www.eset.com > > > > > > > ___ > 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] Warning level
Skylark (J-S) wrote: > > I'm fine with suppressing C4706 as it's true that it's a warning that > only tells you that you *might* be doing something unsafe... Whether > it's actually safe or not is totally context-dependent. > Blanket-supression of C4706 isn't really a good thing, since as you pointed out, it can actually point out an error (usually a typo by the developer). C4706 will not be generated if it is made explicitly clear what the intent of the conditional is. i.e., instead of checking "if ( a = fxn() )", check "if ( (a = fxn()) != 0 )". This is covered in the MSDN page on C4706. I actually prefer the latter syntax (which doesn't generate C4706) anyway, since it eliminates any possible confusion as to the intended operations. Matthew W Fuesz Software Engineer Asc Lockheed Martin STS -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4253#4253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Support for draw_instanced
Draw_instanced was promoted to an ARB extension in the OpenGL 3.0 timeframe (last August), and I found it was only available as ARB in NVIDIA's beta OpenGL 3.0 drivers. Rather than require OSG users to upgrade to beta drivers to access this functionality, I opted to use the EXT version. Using EXT also simplifies the vertex shader. To use the ARB extension, I would've been forced to use GLSL 1.3, which removes all the predefined uniforms. It's a whole new world of shader development, and one I wasn't quite ready to dive into given the non-existent funding for this feature. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com <http://www.skew-matrix.com/> +1 303 859 9466 _ From: osg-submissions-boun...@lists.openscenegraph.org [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of Lionel Lagarde Sent: Wednesday, January 07, 2009 1:52 AM To: OpenSceneGraph Submissions Subject: Re: [osg-submissions] Support for draw_instanced Hi, Why you use the EXT version of draw_instanced. This extension has an ARB version. Paul Martz wrote: Hi Robert -- My update and build of OSG went fine, and my draw instanced test programs ported to your implementation smoothly. Thanks again for your help on this great new feature of OSG. Hi to all -- Current svn head of OSG now supports EXT_draw_instanced. Check out the osgdrawinstanced example, which creates a scene graph consisting of a single Geode with a single Geometry with four vertices, but draws several hundred quads at different orientations, positions, and colors. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-submissions-boun...@lists.openscenegraph.org [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, January 06, 2009 9:14 AM To: OpenSceneGraph Submissions Subject: Re: [osg-submissions] Support for draw_instanced Hi Paul, On Tue, Jan 6, 2009 at 4:06 PM, Paul Martz <mailto:pma...@skew-matrix.com> wrote: Especially thanks for placing the extension support check in State. I disliked having it in the draw() method, but wasn't sure where it should go. Extension checking/function call set up is both a strong and a weak point in the OSG, there are motivations for centralising extension setup and motivations for keeping them local to classes - so the OSG has ended up doing both in different places, sometimes for good reasons, sometime for the wrong reasons... It'd be nice to have a simpler and more manageable scheme that avoids the issues of being pulled in different directions. OpenGL ES and OpenGL 3.x into the mix will further complicate things unless we do come up with a new scheme... I'm updating and building now. I'll let you know if I find any issues. Thanks, Robert. ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. org ___ osg-submissions mailing list osg-submissi...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. org __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 3745 (20090107) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hi Paul, On Wed, Jan 7, 2009 at 4:08 PM, Paul Martz wrote: > If I understand correctly from this discussion, the intended usage is that > developers will leave OSG_USE_AGGRESSIVE_WARNINGS set to the default ON, and > we'll then tackle any warnings on a case by case basis, is that correct? If we can leave the aggressive warnings on then I think this will be better, but we can only leave it on if the vast majority of the build is clean from warnings, spurious or not. I think the way to tackle this is to fix what warnings are practical and sensible to fix, and then disable the spurious ones. If we can't easily get a build clean from warnings on the major platforms then we'll need to disable the aggressive warnings by default on all platforms. I'd rather strive for a bit longer before falling back to this position. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after settingscene data
I also encountered this with one of my own test programs. I got around it by swapping the lines of code. I'll back that change out and test the latest. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 7:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Bug in adding view to compositeViewer after settingscene data Hi Alexandre, I've just fixed the problem and checked it in. Could you try out the svn version of the OSG. Thanks, Robert. On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric wrote: > Hi Robert, > > here is the modified example. > > 2009/1/7 Robert Osfield >> >> HI Alexandre, >> >> Could you post the modified example in the form that reproduces the crash. >> >> Thanks, >> Robert. >> >> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric >> >> wrote: >> > Hi osg-users and Happy New Year to all of you :-) >> > >> > I recently downloaded OSG 2.7.8 to link with my application (wich >> > was linked before with OSG 2.7.4) and I discovered a bug wich can >> > be easily produced by modifying osgcompositeviewer.cpp in Examples >> > osgcompositeviewer. >> > >> > At line 236 : >> > >> > osgViewer::View* view = new osgViewer::View; viewer.addView(view); >> > >> > view->setSceneData(scene.get()); >> > >> > replace by swapping 2 lines (setting scene data before adding new >> > view) >> > : >> > >> > osgViewer::View* view = new osgViewer::View; >> > >> > view->setSceneData(scene.get()); >> > viewer.addView(view); >> > >> > Be sure to run the example to call this code section... >> > >> > It crashes in osgViewer::View::setSceneData when calling >> > >> > getViewerBase()->getThreadingModel() >> > >> > because viewerbase is NULL >> > >> > With older version 2.7.4 it works, apparently not with new 2.7.8. >> > >> > I need my application to stay the same, setting data scene before >> > adding new view to the composite viewer, if you have any tips to do >> > this let me hear. >> > >> > -- >> > Alexandre AMALRIC Ingénieur R&D >> > === >> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille >> > http://www.pixxim.fr >> > >> > ___ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegra >> > ph.org >> > >> > >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph >> .org > > > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
If I understand correctly from this discussion, the intended usage is that developers will leave OSG_USE_AGGRESSIVE_WARNINGS set to the default ON, and we'll then tackle any warnings on a case by case basis, is that correct? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 8:30 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Warning level Hi Jean, On Wed, Jan 7, 2009 at 3:13 PM, Jean-Sébastien Guay wrote: > I just did an update and it doesn't seem you fixed the "warning C4512: > 'classname' : assignment operator could not be generated" warning? > That's the most frequent... I'd like to see it fixed or suppressed if > you don't feel like adding a dummy assignment operator... I might not have caught all instances, but I did implement a bucket load of dummy assignment operators. A quick review of the change to to NodeAcceptOp in include/osg/NodeVisitor shows that I got the parameter type wrong though... now fixed and checked in. Hopefully my other changes were a bit more reliable... > I'm fine with suppressing C4706 as it's true that it's a warning that > only tells you that you *might* be doing something unsafe... Whether > it's actually safe or not is totally context-dependent. I've just checked in suppression of this warning. Should clearly some of the blizzard of misleading warnings. > As for the other warnings, I can have a look at their descriptions and > see, but that might be more your alley since it requires a judgement > call. As I mentioned, just use site:microsoft.com to > look up the documentation on a warning type. > > Thanks, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] overriding keyboard events in osgViewer::View...
Thank you Robert. That helps a lot...:) -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 4:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] overriding keyboard events in osgViewer::View... Hi Shayne, There are no default event handlers in osgViewer save for the escape sets done facility that you can turn off via viewer.setKeyEventSetsDone(0); >From your email it looks like you must be manually adding the osgGA::StateSetManipulator, and if you still want this functionality but want to customize the keys ysed just use the its setKeyEvent*() methods: void setKeyEventToggleBackfaceCulling(int key) { _keyEventToggleBackfaceCulling = key; } void setKeyEventToggleLighting(int key) { _keyEventToggleLighting = key; } void setKeyEventToggleTexturing(int key) { _keyEventToggleTexturing = key; } void setKeyEventCyclePolygonMode(int key) { _keyEventCyclePolygonMode = key; } Robert. On Wed, Jan 7, 2009 at 12:25 AM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > All, > > > > This may be a stupid and/or trivial question but here goes. > > > > Is there a way to override the default keyboard event handlers when using an > osgViewer::View class? For example, if I create a viewer and then press the > "l" (lowercase L) key, it causes my rendered scene to enable and disable > lighting. I want a different behavior when I press this key and other keys. > > > > Thanks, > > -Shayne > > ___ > 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 smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry kernels?
I'm looking for comments and suggestions for using OSG with a geometry engine like ACIS, Parasolid, or Open Cascade. Can they work well together? Is it a useful combination? The application is CAD-like and involves interactively building up a model from discrete components. I found OSG when looking for HOOPS competitors. Is it fair to compare HOOPS with OSG? Thanks, Cory PGP.sig Description: PGP signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hi Jean, On Wed, Jan 7, 2009 at 3:13 PM, Jean-Sébastien Guay wrote: > I just did an update and it doesn't seem you fixed the "warning C4512: > 'classname' : assignment operator could not be generated" warning? That's > the most frequent... I'd like to see it fixed or suppressed if you don't > feel like adding a dummy assignment operator... I might not have caught all instances, but I did implement a bucket load of dummy assignment operators. A quick review of the change to to NodeAcceptOp in include/osg/NodeVisitor shows that I got the parameter type wrong though... now fixed and checked in. Hopefully my other changes were a bit more reliable... > I'm fine with suppressing C4706 as it's true that it's a warning that only > tells you that you *might* be doing something unsafe... Whether it's > actually safe or not is totally context-dependent. I've just checked in suppression of this warning. Should clearly some of the blizzard of misleading warnings. > As for the other warnings, I can have a look at their descriptions and see, > but that might be more your alley since it requires a judgement call. As I > mentioned, just use site:microsoft.com to look up the > documentation on a warning type. > > Thanks, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hello Robert, I've now checked in a number of warning fixes, out of over 1000 warnings that should be removed (mainly repeats) I think just four were actual bugs fixes, whilst they might be minor bugs it's still nice to see them caught and hopefully fixed . The bulk left are unused parameter and assignment in conditionals. I just did an update and it doesn't seem you fixed the "warning C4512: 'classname' : assignment operator could not be generated" warning? That's the most frequent... I'd like to see it fixed or suppressed if you don't feel like adding a dummy assignment operator... My though now is to add suppression of C4706 into include/osg/Export and then review each of the existing suppressed warnings to see if we can remove ones that no longer effect us. The warning codes used date back to VS 6.0 days, and things have moved on a lot in compiler and on the OSG side to warrant a revist of which warnings get suppressed. I'm fine with suppressing C4706 as it's true that it's a warning that only tells you that you *might* be doing something unsafe... Whether it's actually safe or not is totally context-dependent. As for the other warnings, I can have a look at their descriptions and see, but that might be more your alley since it requires a judgement call. As I mentioned, just use site:microsoft.com to look up the documentation on a warning type. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
Robert Osfield wrote: On Wed, Jan 7, 2009 at 2:53 PM, Alexandre Amalric wrote: It will be a pleasure to check your fix but I'm sorry, I'm not well familiar with SVN, I know it's not your role to do this but could you please send me some information on how to do, is there a good tutorial on how works subversion ? It really isn't my place to teach people about 3rd party tools, there are hundreds of websites out there that cover subversion usage, just bring up a search engine in your browser and go learn about it. I can give you a bit of help if you want. What platform are you working on? If Linux, find the subversion package for your distro (usually called "subversion" or "svn"). If you're on Windows, go to http://tortoisesvn.tigris.org/ and download the latest tortoisesvn and install it. Tortoisesvn is an add-on that contains Suversion, and that allows you to use it conveniently from Windows Explorer. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
On Wed, Jan 7, 2009 at 2:53 PM, Alexandre Amalric wrote: > It will be a pleasure to check your fix but I'm sorry, I'm not well familiar > with SVN, I know it's not your role to do this but could you please send me > some information on how to do, is there a good tutorial on how works > subversion ? It really isn't my place to teach people about 3rd party tools, there are hundreds of websites out there that cover subversion usage, just bring up a search engine in your browser and go learn about it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
Hi Robert, It will be a pleasure to check your fix but I'm sorry, I'm not well familiar with SVN, I know it's not your role to do this but could you please send me some information on how to do, is there a good tutorial on how works subversion ? 2009/1/7 Robert Osfield > Hi Alexandre, > > I've just fixed the problem and checked it in. Could you try out the > svn version of the OSG. > > Thanks, > Robert. > > On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric > wrote: > > Hi Robert, > > > > here is the modified example. > > > > 2009/1/7 Robert Osfield > >> > >> HI Alexandre, > >> > >> Could you post the modified example in the form that reproduces the > crash. > >> > >> Thanks, > >> Robert. > >> > >> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric < > alex.pix...@gmail.com> > >> wrote: > >> > Hi osg-users and Happy New Year to all of you :-) > >> > > >> > I recently downloaded OSG 2.7.8 to link with my application (wich was > >> > linked > >> > before with OSG 2.7.4) and I discovered a bug wich can be easily > >> > produced by > >> > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer. > >> > > >> > At line 236 : > >> > > >> > osgViewer::View* view = new osgViewer::View; > >> > viewer.addView(view); > >> > > >> > view->setSceneData(scene.get()); > >> > > >> > replace by swapping 2 lines (setting scene data before adding new > view) > >> > : > >> > > >> > osgViewer::View* view = new osgViewer::View; > >> > > >> > view->setSceneData(scene.get()); > >> > viewer.addView(view); > >> > > >> > Be sure to run the example to call this code section... > >> > > >> > It crashes in osgViewer::View::setSceneData when calling > >> > > >> > getViewerBase()->getThreadingModel() > >> > > >> > because viewerbase is NULL > >> > > >> > With older version 2.7.4 it works, apparently not with new 2.7.8. > >> > > >> > I need my application to stay the same, setting data scene before > adding > >> > new > >> > view to the composite viewer, if you have any tips to do this let me > >> > hear. > >> > > >> > -- > >> > Alexandre AMALRIC Ingénieur R&D > >> > === > >> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > >> > http://www.pixxim.fr > >> > > >> > ___ > >> > 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 > > > > > > > > -- > > Alexandre AMALRIC Ingénieur R&D > > === > > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > > http://www.pixxim.fr > > > > ___ > > 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 > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
Hi Alexandre, I've just fixed the problem and checked it in. Could you try out the svn version of the OSG. Thanks, Robert. On Wed, Jan 7, 2009 at 2:10 PM, Alexandre Amalric wrote: > Hi Robert, > > here is the modified example. > > 2009/1/7 Robert Osfield >> >> HI Alexandre, >> >> Could you post the modified example in the form that reproduces the crash. >> >> Thanks, >> Robert. >> >> On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric >> wrote: >> > Hi osg-users and Happy New Year to all of you :-) >> > >> > I recently downloaded OSG 2.7.8 to link with my application (wich was >> > linked >> > before with OSG 2.7.4) and I discovered a bug wich can be easily >> > produced by >> > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer. >> > >> > At line 236 : >> > >> > osgViewer::View* view = new osgViewer::View; >> > viewer.addView(view); >> > >> > view->setSceneData(scene.get()); >> > >> > replace by swapping 2 lines (setting scene data before adding new view) >> > : >> > >> > osgViewer::View* view = new osgViewer::View; >> > >> > view->setSceneData(scene.get()); >> > viewer.addView(view); >> > >> > Be sure to run the example to call this code section... >> > >> > It crashes in osgViewer::View::setSceneData when calling >> > >> > getViewerBase()->getThreadingModel() >> > >> > because viewerbase is NULL >> > >> > With older version 2.7.4 it works, apparently not with new 2.7.8. >> > >> > I need my application to stay the same, setting data scene before adding >> > new >> > view to the composite viewer, if you have any tips to do this let me >> > hear. >> > >> > -- >> > Alexandre AMALRIC Ingénieur R&D >> > === >> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille >> > http://www.pixxim.fr >> > >> > ___ >> > 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 > > > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > ___ > 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] atomic_xor_uint_nv on Solaris
Thanks. I've sent an email to Blasius (hoping I got the email from Gmane correctly), and will see if he has a suggestion. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the "and", "or" and "xor" features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37 lines >From Blasius Czink, "Among other things I added support for atomic operations on BSD-like systems and additional methods (for "and", "or", "xor"). " and a later post the same osg-submissions thread: "it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config. Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds." And another post from Blasius on this topic: "I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005. In case anyone is interested the lines: __MACHINEI(unsigned char _interlockedbittestandset(long *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b)) should be changed to: __MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b)) The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used. Which reminds me another small glitch in the Atomic header so I attached a corrected version. Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere. OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that. " ___ 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] Is it necessary a while cycle to remove a child?
Hello Francesco, 2)If i use a while that cycle until the removal is not possible it remove the child correctly. This suggests that the child has simply been added multiple times to the same parent. Just break at that location in the debugger and examine the parent's children vector, and see if the same address (i.e. child) is there multiple times. Then examine your addition code to make sure you're only adding it once if that's what you expect. Perhaps add a test to check if the parent already has the child in its children before adding it... OSG won't add children by itself. So if you need to use a while loop to remove a child which you *think* was only added once to the parent, that means you didn't just add it once... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why the wave simulation so inefficiency?
Hello flying5? (2) Then, I realize it use OSG. But when I render 128*128*2 = 32768 triangles grid and the FPS is only 13!!!. (3) I don't think there is any difference between the two way I realize the wave. But why the great disparity in efficiency? There must be a difference, or else the performance would be identical. As a first step to investigation, what are you using for your grids? osg::Geometry using VBOs would be the most efficient path. Make sure you're at least disabling display lists on your osg::Geometry objects, then you'll be using Vertex Buffers which on dynamic geometry will gain a few orders of magnitude of performance, since OSG won't have to recompile display lists every frame. Then investigate using VBOs which will be the next step, search the mailing list archives for how to use those. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
Hi Robert, here is the modified example. 2009/1/7 Robert Osfield > HI Alexandre, > > Could you post the modified example in the form that reproduces the crash. > > Thanks, > Robert. > > On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric > wrote: > > Hi osg-users and Happy New Year to all of you :-) > > > > I recently downloaded OSG 2.7.8 to link with my application (wich was > linked > > before with OSG 2.7.4) and I discovered a bug wich can be easily produced > by > > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer. > > > > At line 236 : > > > > osgViewer::View* view = new osgViewer::View; > > viewer.addView(view); > > > > view->setSceneData(scene.get()); > > > > replace by swapping 2 lines (setting scene data before adding new view) : > > > > osgViewer::View* view = new osgViewer::View; > > > > view->setSceneData(scene.get()); > > viewer.addView(view); > > > > Be sure to run the example to call this code section... > > > > It crashes in osgViewer::View::setSceneData when calling > > > > getViewerBase()->getThreadingModel() > > > > because viewerbase is NULL > > > > With older version 2.7.4 it works, apparently not with new 2.7.8. > > > > I need my application to stay the same, setting data scene before adding > new > > view to the composite viewer, if you have any tips to do this let me > hear. > > > > -- > > Alexandre AMALRIC Ingénieur R&D > > === > > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > > http://www.pixxim.fr > > > > ___ > > 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 > -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr /* OpenSceneGraph example, osgcompositeviewer. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include // class to handle events with a pick class PickHandler : public osgGA::GUIEventHandler { public: PickHandler(): _mx(0.0f), _my(0.0f) {} ~PickHandler() {} bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa) { osgViewer::View* view = dynamic_cast(&aa); if (!view) return false; switch(ea.getEventType()) { case(osgGA::GUIEventAdapter::PUSH): { _mx = ea.getX(); _my = ea.getY(); break; } case(osgGA::GUIEventAdapter::RELEASE): { if (_mx==ea.getX() && _my==ea.getY()) { pick(view, ea.getX(), ea.getY()); } break; } default: break; } return false; } void pick(osgViewer::View* view, float x, float y) { osg::Node* node = 0; osg::Group* parent = 0; osgUtil::LineSegmentIntersector::Intersections intersections; if (view->computeIntersections(x, y, intersections)) { osgUtil::LineSegmentIntersector::Intersection intersection = *intersections.begin(); osg::NodePath& nodePath = intersection.nodePath; node = (nodePath.size()>=1)?nodePath[nodePath.size()-1]:0; parent = (nodePath.size()>=2)?dynamic_cast(nodePath[nodePath.size()-2]):0; } // now we try to decorate the hit node by the osgFX::Scribe to show that its been "picked" if (parent && node) { osgFX::Scribe* parentAsScribe = dynamic_cast(parent);
Re: [osg-users] Bug in adding view to compositeViewer after setting scene data
HI Alexandre, Could you post the modified example in the form that reproduces the crash. Thanks, Robert. On Wed, Jan 7, 2009 at 1:52 PM, Alexandre Amalric wrote: > Hi osg-users and Happy New Year to all of you :-) > > I recently downloaded OSG 2.7.8 to link with my application (wich was linked > before with OSG 2.7.4) and I discovered a bug wich can be easily produced by > modifying osgcompositeviewer.cpp in Examples osgcompositeviewer. > > At line 236 : > > osgViewer::View* view = new osgViewer::View; > viewer.addView(view); > > view->setSceneData(scene.get()); > > replace by swapping 2 lines (setting scene data before adding new view) : > > osgViewer::View* view = new osgViewer::View; > > view->setSceneData(scene.get()); > viewer.addView(view); > > Be sure to run the example to call this code section... > > It crashes in osgViewer::View::setSceneData when calling > > getViewerBase()->getThreadingModel() > > because viewerbase is NULL > > With older version 2.7.4 it works, apparently not with new 2.7.8. > > I need my application to stay the same, setting data scene before adding new > view to the composite viewer, if you have any tips to do this let me hear. > > -- > Alexandre AMALRIC Ingénieur R&D > === > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > ___ > 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] atomic_xor_uint_nv on Solaris
Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the "and", "or" and "xor" features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37 lines >From Blasius Czink, "Among other things I added support for atomic operations on BSD-like systems and additional methods (for "and", "or", "xor"). " and a later post the same osg-submissions thread: "it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config. Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds." And another post from Blasius on this topic: "I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005. In case anyone is interested the lines: __MACHINEI(unsigned char _interlockedbittestandset(long *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b)) should be changed to: __MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b)) The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used. Which reminds me another small glitch in the Atomic header so I attached a corrected version. Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere. OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that. " ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warnings in VS
Hello Mattias, I had a look at this. I suspect this was caused by the INTERNALly cached OLD_CMAKE:CXX_FLAGS. I'm not sure I had your setup but made some changes and at the same time removed a "fixme". I have attached my current CMakeLists.txt. If you have the time please test, though I guess your setups are fixed by now. I'd like to test, but it seems you forgot to attach the file? I stumbled upon another problem with the aggresive warnings. I needed to configure twice before a changed aggresive setting would take effect because the changes to CMAKE_CXX_FLAGS are made after source is processed. Have you seen this? Actually this should be seen on any platform. Have people on other platforms seen it? I didn't see this specifically, but didn't try either. I just changed the value, generated the project files and noticed that the actual compiler flags hadn't changed. I didn't think to click "configure" twice. I'll investigate. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning level
Hi JS et. al., I've now checked in a number of warning fixes, out of over 1000 warnings that should be removed (mainly repeats) I think just four were actual bugs fixes, whilst they might be minor bugs it's still nice to see them caught and hopefully fixed . The bulk left are unused parameter and assignment in conditionals. I've reviewed almost all the assignment in conditional warnings and all look perfectly correct code, fixing the code to not use an assignment in an if() statement would lead to more code, so rather award scoping and more opportunities to introducing bugs. I really detest it when warnings appear on valid C/C++ code that has no ambiguity in it, this one boils down to prohibiting use of a particular feature of the language because some careless programmers might misuse it, but in the process screwing up things for programmers who actually know what they are doing. For these stopid warning cases I think the right thing to do is just disable them as they cause more harm than good. The warning number is C4706. The unused parameter warnings are for typically benign non usage of parameters that won't affect anything, but are easily fixable by /* commenting out */ the variable name or just deleting it. Sometime the variable name implies so extra information so is useful to keep in. My though now is to add suppression of C4706 into include/osg/Export and then review each of the existing suppressed warnings to see if we can remove ones that no longer effect us. The warning codes used date back to VS 6.0 days, and things have moved on a lot in compiler and on the OSG side to warrant a revist of which warnings get suppressed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in adding view to compositeViewer after setting scene data
Hi osg-users and Happy New Year to all of you :-) I recently downloaded OSG 2.7.8 to link with my application (wich was linked before with OSG 2.7.4) and I discovered a bug wich can be easily produced by modifying osgcompositeviewer.cpp in Examples osgcompositeviewer. *At line 236 :* osgViewer::View* view = new osgViewer::View; viewer.addView(view); view->setSceneData(scene.get()); *replace by swapping 2 lines (setting scene data before adding new view) :* osgViewer::View* view = new osgViewer::View; view->setSceneData(scene.get()); viewer.addView(view); *Be sure to run the example to call this code section...* It crashes in osgViewer::View::setSceneData when calling getViewerBase()->getThreadingModel() because viewerbase is NULL With older version 2.7.4 it works, apparently not with new 2.7.8. I need my application to stay the same, setting data scene before adding new view to the composite viewer, if you have any tips to do this let me hear. -- Alexandre AMALRIC Ingénieur R&D === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] atomic_xor_uint_nv on Solaris
A const cast does remove the second error (and atomic_cas_ptr does seem like it could have used a const argument, since this is the comparison arg, which shouldn't be changed). I still haven't gotten rid of the atomic_xor_uint_nv issue, though, so I can't build the OpenSceneGraph on all our platforms. The code looks like: _OPENTHREADS_ATOMIC_INLINE unsigned Atomic::XOR(unsigned value) { #if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS) return __sync_fetch_and_xor(&_value, value); #elif defined(_OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS) return __xor_and_fetch(&_value, value); #elif defined(_OPENTHREADS_ATOMIC_USE_SUN) return atomic_xor_uint_nv(&_value, value); #elif defined(_OPENTHREADS_ATOMIC_USE_MUTEX) ScopedLock lock(_mutex); _value ^= value; return _value; #else _value ^= value; return _value; #endif } The line that complains that atomic_xor_uint_nv() needs a prototype is the one inside the condition for _OPENTHREADS_ATOMIC_USE_SUN. If anyone has an idea of a include I'm supposed to have, or something I'm supposed to define, please help. thanks, andy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner Sent: Tuesday, January 06, 2009 1:45 PM To: OpenSceneGraph Users Subject: [osg-users] atomic_xor_uint_nv on Solaris I'm trying to build a recent SVN version, and get errors for include/OpenThreads/Atomic: line 183: Error, badfunccp: The function "atomic_xor_uint_nv" must have a prototype. I'm not sure about this one. How is that supposed to be defined? line 243: Error, badargtype2: Formal argument 2 of type void* in call to atomic_cas_ptr(volatile void* void* void*) is being passed const void*const. Is this one just a const issue? Should it use a const cast, or is this a sign of a problem? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG on ohloh
Hi all, I just discovered ohloh.net and saw OSG don't have much registered users (only 18 users!). So, for OSG's visibility, I suggest that those who want go there and click the "I use this" button, or rate/review the project. If like me you didn't know, it's an open source projects and developpers directory... well go and see! Registering is very fast. https://www.ohloh.net/p/osg Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it necessary a while cycle to remove a child?
Hi Francesco, There is waaay too little information about the code that is doing the operations to know what might be wrong. Please post the surrounding code to your removeChild calls. Robert. On Wed, Jan 7, 2009 at 11:45 AM, Francesco Argese wrote: > Hi guys, > > i begin thanking all users that are helping me on this mailing list; > i don't thank always after the response to avoid the opening of a new > thread because i receive only digest and i don't know if it is > possible to receive as complete messages only the message in responce > to me. > > i have a doubt: During my application event generated by user led to > change my scenegraph deleting some child nodes. With version 1.2 on > windows i have obtained the following behaviour: > > 1)If i remove the node in question with the following command > > this->unitTransform->removeChild(this->geodeSphere.get(); > > it doesn't cancel it always but also sometimes. > > 2)If i use a while that cycle until the removal is not possible it > remove the child correctly. > > My doubt is the following: is it necessary or could it be possible > that i have done some errors that generate this behaviour? > > Thanks in advance > Francesco Argese > ___ > 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] overriding keyboard events in osgViewer::View...
Hi Shayne, There are no default event handlers in osgViewer save for the escape sets done facility that you can turn off via viewer.setKeyEventSetsDone(0); >From your email it looks like you must be manually adding the osgGA::StateSetManipulator, and if you still want this functionality but want to customize the keys ysed just use the its setKeyEvent*() methods: void setKeyEventToggleBackfaceCulling(int key) { _keyEventToggleBackfaceCulling = key; } void setKeyEventToggleLighting(int key) { _keyEventToggleLighting = key; } void setKeyEventToggleTexturing(int key) { _keyEventToggleTexturing = key; } void setKeyEventCyclePolygonMode(int key) { _keyEventCyclePolygonMode = key; } Robert. On Wed, Jan 7, 2009 at 12:25 AM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > All, > > > > This may be a stupid and/or trivial question but here goes… > > > > Is there a way to override the default keyboard event handlers when using an > osgViewer::View class? For example, if I create a viewer and then press the > "l" (lowercase L) key, it causes my rendered scene to enable and disable > lighting. I want a different behavior when I press this key and other keys… > > > > Thanks, > > -Shayne > > ___ > 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] getYnormalized() and camera transforms
Hi Guy, I don't know what is up, usually things just work. I wouldn't expect a x range of -1 to 1 give the center screen will be -1 to 1, so the overall x range would be more like -3 to 3 given that things are scaled ralted to the master camera. Robert. On Wed, Jan 7, 2009 at 8:26 AM, Guy Wallis wrote: > Hi Robert, > First, thanks for the quick reply. > Second, oops, yes sorry, a slip of the keyboard there. I did mean to alter > the view matrix, not the projection matrix. > > I am setting up a 3 screen viewing cube with front, left and right screens > each rotated by 90 degrees to their neighbour(s). So, I meant to say the > following: > > If I ask for the camera to be swung around the y-axis: > > viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix::rotate(-pi/2, 0.0f, > 1.0f, 0.0f)); > > the values for x and y no longer lie within the range -1 to 1. In fact the > values are a bit wild, I guess the pointer is regarded as no longer moving in > the x-y plane. > > At this stage I'm just looking to use the mouse position as a control for > speed (x-coord) and heading (y-coord) across all three windows. > > Cheers, > > Guy > > > > From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield > Sent: Tue 1/6/2009 10:43 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] getYnormalized() and camera transforms > > > > Hi Guy, > > The osgViewer library projects the slave cameras coordinates into the > master cameras coordinates to enable seamless movement of the mouse > from slave camera viewport to the next, this actually solves one of > the problems that existed when handling mouse coords with multiple > channels in Performer. > > I a bit surprised you are trying to rotate the projection matrix. > Typically you shear the projection matrix or rotate the view matrix. > What type of display set up are you trying to address? > > Robert. > > On Tue, Jan 6, 2009 at 11:13 AM, Guy Wallis wrote: >> G'Day from Down Under, >> >> >> >> I'm running OSG 2.6 under windows XP and on a trusty old SGI Octane (Yes, it >> compiles nicely and even the Performer plug-in works!) >> >> >> >> I'm new to OSG and am struggling with the getXnormalized() routine (part of >> osgGA::GUIEventAdapter). >> >> >> >> If I add a matrix transform to the viewer camera it affects the routine's >> output. >> >> >> >> >> >> So, setting up the camera like this: >> >> >> >> viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix()) >> >> >> >> gives me normal behaviour with mouse xy values scaled between -1 and 1. >> >> >> >> >> >> >> >> >> >> But if I ask for the camera to be swung around the x-axis like this: >> >> >> >> viewer.addSlave(camera.get(),osg::Matrix::rotate(pi/2, 1.0f, 0.0f, 0.0f), >> osg::Matrix()); >> >> >> >> the numbers returned by getYnormalized() are no longer in the range -1 to 1. >> >> >> >> >> >> How do I retrieve the simple, untransformed mouse xy position data? >> >> >> >> Thanks, >> >> >> >> Guy >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why the wave simulation so inefficiency?
Hi ? (Could you sign with the name you wished to be addressed as, it good list etiquete) You shouldn't see a performance drop, the fact you do suggests that your doing something wrong on the OSG, but your've provide way too little information about how you've set up your scene graph to suggest what this might be. As a general note a 128x128 grid on modern is trivial for both OpenGL and OSG. With modern hardware you get render 1000x1000 grids at still get 60Hz. Your low end card might not quite be able to do this but it won't be a long way off. This clearly says that there is something serious up with the way you are doing things. Robert. On Wed, Jan 7, 2009 at 4:41 AM, flying5 wrote: > In a rain scene, I try to simulate rain ripple follow this article: > http://www.gamedev.net/reference/articles/article915.asp. > (1) First, I realize it use openGL, it works all right. I render > 256*256*2 =131072 triangles grid and the FPS is 85 on my > Intel Pentium(R)4 2*3.00GHz Cpu and GF7300GT(128M) video card. > (2) Then, I realize it use OSG. But when I render 128*128*2 = 32768 > triangles grid and the FPS is only 13!!!. > (3) I don't think there is any difference between the two way I realize > the wave. But why the great disparity in efficiency? > > Do anyone hava a better wave simulation way? > > Some code likes: > /*** process wave ***/ > void ProcessWave() > { > float temp; > for (int i=1; i for (int j=1; j { >temp = ((wavemap[currentMap][i-1][j] + > wavemap[currentMap][i+1][j] + > wavemap[currentMap][i][j-1] + > wavemap[currentMap][i][j+1] + > wavemap[currentMap][i-1][j+1] + > wavemap[currentMap][i+1][j+1] + > wavemap[currentMap][i-1][j-1] + > wavemap[currentMap][i+1][j-1]) / 4) - > wavemap[lastMap][i][j]; >temp = temp - (temp / damp); >if (temp < 0.01) temp = 0; >wavemap[nextMap][i][j] = temp; > } > } > /** invert wave map ***/ > void InvertWaveMap() > { > float temp[MAPY][MAPX]; > for (int i = 0; i < MAPX; i++) > for (int j = 0; j < MAPY; j++) > { > temp[i][j] = wavemap[nextMap][i][j]; > wavemap[nextMap][i][j] = wavemap[lastMap][i][j]; > wavemap[lastMap][i][j] = wavemap[currentMap][i][j]; > wavemap[currentMap][i][j] = temp[i][j]; > } > } > > > [广告] 出名要趁"小",快来上传宝贝照片赢大奖吧! > ___ > 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] Is it necessary a while cycle to remove a child?
Hi guys, i begin thanking all users that are helping me on this mailing list; i don't thank always after the response to avoid the opening of a new thread because i receive only digest and i don't know if it is possible to receive as complete messages only the message in responce to me. i have a doubt: During my application event generated by user led to change my scenegraph deleting some child nodes. With version 1.2 on windows i have obtained the following behaviour: 1)If i remove the node in question with the following command this->unitTransform->removeChild(this->geodeSphere.get(); it doesn't cancel it always but also sometimes. 2)If i use a while that cycle until the removal is not possible it remove the child correctly. My doubt is the following: is it necessary or could it be possible that i have done some errors that generate this behaviour? Thanks in advance Francesco Argese ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using DatabasePager And Precompile Data Option Within osgViewer
Hi Ryan, I have fixed a couple of items in the precompile path of DatabasePager since 2.6, so even though it's now disabled by default, when you do enable it should function better. So I'd recommend reviewing the code in svn/trunk 2.7.7 rather than 2.6.0. Robert. On Tue, Jan 6, 2009 at 11:33 PM, Kawicki, Ryan H wrote: > OSG Version: 2.6.0 > OS: Windows XP SP2 > Compiler: MS Version 13.10.3077 ( .NET 2003 ) > > I am a little confused on how the precompile option works within OSG > 2.6.0. From what I understand, the intended use is to have all gl > objects compiled in the background before they are merged with the scene > graph. I do not believe this is working as intended. Please correct me > if I am wrong about any of my assumptions. > > By default, the code indicates that this option is on. This can be seen > in the constructor of the DatabasePager. As database requests are > processed, the requests are placed inside of the _dataToCompileList. A > few statements later, an if statement is evaluated to see if loaded > objects need to be compiled and that there are active graphics contexts. > This statement evaluates to true, but when it tries to obtain a compile > context for the graphics context, it returns NULL. Because of this, I > believe the objects to be compiled are being compiled on the same thread > that is rendering the scene. > > void DatabasePager::DatabaseThread::run() > { > < ... Code Removed ... > > // move the databaseRequest from the front of the fileRequest to the end > of > // dataToCompile or dataToMerge lists. > if (loadedObjectsNeedToBeCompiled) > { > OpenThreads::ScopedLock > lock(_pager->_dataToCompileList->_requestMutex); > databaseRequest->_requestQueue = _pager->_dataToCompileList.get(); > > _pager->_dataToCompileList->_requestList.push_back(databaseRequest); > } > < ... Code Removed ... > > if (loadedObjectsNeedToBeCompiled && > !_pager->_activeGraphicsContexts.empty()) > { > for(ActiveGraphicsContexts::iterator itr = > _pager->_activeGraphicsContexts.begin(); > itr != _pager->_activeGraphicsContexts.end(); > ++itr) > { > osg::GraphicsContext* gc = > osg::GraphicsContext::getCompileContext(*itr); > if (gc) > { > < ... Code Removed ... > > } > } > < ... Code Removed ... > > } > > I did some digging to see what needed to be provided to osgViewer to > create the compile context. I found that there was a command line > argument ( "--cc" ) that could be passed to indicate to the pager that a > compile context should be used. This allowed for a compile context to > be obtained, but the scene was no longer visible. Nodes were being > requested and being inserted into the data to compile list, but the > graphics thread seems not to be compiling the data because nothing > visually was showing up. > > if (gc) > { > osg::GraphicsThread* gt = gc->getGraphicsThread(); > if (gt) > { > gt->add(new DatabasePager::CompileOperation(_pager)); > } > else > { > gc->makeCurrent(); > _pager->compileAllGLObjects(*(gc->getState())); > gc->releaseContext(); > } > } > > To make it even more interesting, I NOPed out all of the if statement > and had it go straight to the first statement of the else clause, and > the terrain began showing up, minus the textures. I have not quite > figured that one out yet. > > I do not claim to be an expert on the DatabasePager, but it looks like > there might be a few things wrong with the precompile option. I know it > is going to be defaulted to off in later versions of OSG, but I wanted > to do some testing with our terrains having this option on and off. To > me, it looked like having it on or off made no difference, and this is > why I started to investigate. > > Can anyone confirm that this is the intended behavior of the precompile > option? Have I made any bad assumptions on how the system is intended > to work? Are there missing command line arguments that I have not > explored? > > I am assuming that the graphics context created for the window is the > same graphics context that is used to precompile the data. What kind of > system is in place to make sure that only one thread has access to the > graphics context? > > Thanks for any help. I'll report anything else I might find. > > Ryan H. Kawicki > The Boeing Company > Training Systems & Services > Software Engineer > > ___ > 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] overriding keyboard events in osgViewer::View...
Hi, The Handlers can be set when you need them. By default, the statesetHandler is set, and manage the 'l' key for instance. If you make your own viewer, you can put the handlers you want. I'm not sure on how to remove the default handler, but If you set your view(er), and add the eventHandlers you need and nothing more, that will let you obtain what you need. Hope it can help you... Regards, Vincent. 2009/1/7 Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC < shayne.tuel...@hill.af.mil> > All, > > > > This may be a stupid and/or trivial question but here goes… > > > > Is there a way to override the default keyboard event handlers when using > an osgViewer::View class? For example, if I create a viewer and then press > the "l" (lowercase L) key, it causes my rendered scene to enable and disable > lighting. I want a different behavior when I press this key and other keys… > > > > Thanks, > > -Shayne > > ___ > 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] getYnormalized() and camera transforms
Hi Robert, First, thanks for the quick reply. Second, oops, yes sorry, a slip of the keyboard there. I did mean to alter the view matrix, not the projection matrix. I am setting up a 3 screen viewing cube with front, left and right screens each rotated by 90 degrees to their neighbour(s). So, I meant to say the following: If I ask for the camera to be swung around the y-axis: viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix::rotate(-pi/2, 0.0f, 1.0f, 0.0f)); the values for x and y no longer lie within the range -1 to 1. In fact the values are a bit wild, I guess the pointer is regarded as no longer moving in the x-y plane. At this stage I'm just looking to use the mouse position as a control for speed (x-coord) and heading (y-coord) across all three windows. Cheers, Guy From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Tue 1/6/2009 10:43 PM To: OpenSceneGraph Users Subject: Re: [osg-users] getYnormalized() and camera transforms Hi Guy, The osgViewer library projects the slave cameras coordinates into the master cameras coordinates to enable seamless movement of the mouse from slave camera viewport to the next, this actually solves one of the problems that existed when handling mouse coords with multiple channels in Performer. I a bit surprised you are trying to rotate the projection matrix. Typically you shear the projection matrix or rotate the view matrix. What type of display set up are you trying to address? Robert. On Tue, Jan 6, 2009 at 11:13 AM, Guy Wallis wrote: > G'Day from Down Under, > > > > I'm running OSG 2.6 under windows XP and on a trusty old SGI Octane (Yes, it > compiles nicely and even the Performer plug-in works!) > > > > I'm new to OSG and am struggling with the getXnormalized() routine (part of > osgGA::GUIEventAdapter). > > > > If I add a matrix transform to the viewer camera it affects the routine's > output. > > > > > > So, setting up the camera like this: > > > > viewer.addSlave(camera.get(), osg::Matrix(), osg::Matrix()) > > > > gives me normal behaviour with mouse xy values scaled between -1 and 1. > > > > > > > > > > But if I ask for the camera to be swung around the x-axis like this: > > > > viewer.addSlave(camera.get(),osg::Matrix::rotate(pi/2, 1.0f, 0.0f, 0.0f), > osg::Matrix()); > > > > the numbers returned by getYnormalized() are no longer in the range -1 to 1. > > > > > > How do I retrieve the simple, untransformed mouse xy position data? > > > > Thanks, > > > > Guy > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org