Re: [osg-users] What is the meanings of setMinimumScale(1)and setMaximumScale(2)?
Hi Wangjian, please don't post the same question twice. You probably didn't receive an answer, because the question was too vague. It would have been clearer if you said that setMinimumScale and setMaximumScale are part of AutoTransform. When I run the program You are probably talking about the example program osgautotransform. Through use of the source (see Tip 2 (http://forum.openscenegraph.org/viewtopic.php?t=2283)) I learned the following: When the transform is far from the viewpoint it's scale is limited by the maximum scale. So it disappears because the transform is not allowed to scale to a larger value than 2. If it is close to the viewpoint it's scale is limited by the minimumscale. In that case it will not be fixed in screenspace anymore an appear to grow due to perspective projection. kind regards, Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10771#10771 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG .NET demo using C++/CLI / again
Hi I've been playing with the various settings in C++ (no need to do this in C#), which are new to me. Eventually, the program compile and ran correctly. I changed from Debug to Release mode as well. Still don't understand what I did to make it work. Any help on how I managed to fix the problem would be appreciated. Ernest Abbott ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG .NET demo using C++/CLI / again
Hi Ernest, Good to hear that you have your program running now. I can't really guess what you did to fix it. I'm using C++/CLI with OpenSceneGraph as well (also started from Hesicong's great example) and the SEHexception that you encountered in my case was that either an OpenSceneGraph .dll was not found (check the environment vars for the OSG_BIN_PATH and if the OSG_BIN_PATH is in your PATH var) or that the OpenSceneGraph .dll's were build in Release mode, while my C++/CLI program was build in Debug mode (or the other way around of course). Kind regards, Ruben From: osg-users-boun...@lists.openscenegraph.org on behalf of Ernest Abbott Sent: Fri 4/24/2009 9:37 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] OSG .NET demo using C++/CLI / again Hi I've been playing with the various settings in C++ (no need to do this in C#), which are new to me. Eventually, the program compile and ran correctly. I changed from Debug to Release mode as well. Still don't understand what I did to make it work. Any help on how I managed to fix the problem would be appreciated. Ernest Abbott ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi JS, On Thu, Apr 23, 2009 at 7:27 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: As an additional data point, on Windows, the NVidia drivers ship with vsync enabled by default, but ATI ships with it disabled. This always bugs me when setting up a new machine. Thanks for the info. If you want to add a feature for capping the frame rate, then I'd like to suggest having a key, a command-line arg and an environment variable to enable/disable this, and perhaps a way of setting the target frame rate. Personally I prefer letting users have the choice, through the vsync setting in their driver, whether they want to cap the frame rate or not. It's only be the run convenience method that would do the frame rate management, and perhaps we could expose a viewer method to help the frame management done in user code. With the frame rate management my expectation would be offer a couple of different settings so that calling code could choose how that want to run the frame management, be it lazy frame loop, continuous but capped to be at or below a specified max frame rate, or free running where the frame rate run just at full pelt only help back by vsynvc (if enabled). We could possible provide an env var to provide a hint to DisplaySettings for what the defaults should be. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
Hi Paul, we are handling it like the 'perContextData' of StateAttributes gets handled, assuming that we don't have multiple threads per context. Like Robert pointed out some data can be created on the fly - which we are doing with context- and view-dependend statesets. Richard Schmidt -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Paul Martz Gesendet: Donnerstag, 23. April 2009 22:30 An: 'OpenSceneGraph Users' Betreff: Re: [osg-users] Modifying SG based on viewpoint location Yeah, what does modify mean, that's the question. I have a client who is modifying the scene graph in a number of ways during the cull traversal and is therefore only able to run SingleThreaded. I'm still digging in to find out exactly what it is they are doing that isn't thread safe (even the client isn't exactly sure, or isn't able to spell it out precisely for some reason), but it seems to be some type of viewpoint-dependent LOD-like modification. In the meantime, I wanted to poll the community for thread-safe alternatives. So I want to thank all that have replied, especially Robert for telling me how those OSG classes handle this requirement. At some point, I'll summarize all this into some kind of document or posting, so that people don't go down the non-thread safe path in the future. 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 Chris 'Xenon' Hanson Sent: Thursday, April 23, 2009 10:15 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Modifying SG based on viewpoint location Paul Martz wrote: Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph I guess the important question is, what kind of modifications exactly? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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] OpenSceneGraph-2.8.1 release candidate three tagged
On Thu, Apr 23, 2009 at 9:17 PM, Paul Martz pma...@skew-matrix.com wrote: Just tested the following with my current software project and encountered no issues: 2.8.1 rc3 on WinXP using VS8 with Quadro 1500M svn head on WinXP using VS8 with Quadro 1500M svn head on Mac OS X using makefiles/gcc with GeForce 8800 Thanks. Testing much appreciate. Everyone else?? ;-) I have a couple of submissions in my inbox this morning that request merging in the OSG-2.8 branch so it looks like I may have to make an rc4 We'll have to make a cut off soon though, we can't have 2.8.1 never going out because other fixes might be on their way. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing problems with multi context views
Hi, I'm having problems with rendering multiple views of a scene, consisting of a terrain with PagedLODs (generated using VPB), and various other models. The problems that arise are missing textures in one or several viewports and sometimes corrupted vertex data as well. I have tested the following configurations: One CompositeViewer with multiple osgViewer::View objects. This renders fine when only a single View is attached to the CompositeViewer. When a second View is added, it will render the terrain without textures at particular parts of the terrain surface. On occasion the polygons are distorted as well. The order in which the View-objects are added to the CompositeViewer affects the result: The View that is added first to the CompositeViewer will work fine. The scene data is the same for all views. The same problems occur when using multiple osgViewer::Viewer objects instead of a CompositeViewer. I have tried to use getCamera()-getGraphicsContext()-makeCurrent(); before frame() is called for each Viewer. I have checked that the context ID's varies among the Views. Initially the windows were based on wxWidgets, using a canvas class (inheriting from wxGLCanvas and GraphicsWindow) as graphics contexts. But the problems are the same when I simply use the Viewer's setUpViewInWindow(.). However, what does work is setting/creating the graphics contexts like: unsigned int contextID = osg::GraphicsContext::createNewContextID(); osg::GraphicsContext* gc = osg::GraphicsContext::getOrCreateCompileContext(contextID); m_pView-getCamera()-setGraphicsContext(gc); Does this make any sense? Since we would like to render the views inside of wxFrame-derived windows, could a canvas class (inheriting from wxGLCanvas and GraphicsWindow) be created that does the same as getOrCreateCompileContext? Or is there something I might be missing? Helpful for any input. Regards, Linus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] update of zNear and zFar during drawing
Hi all. I have a strange behavior when I let OSG update the near and far clipping planes during drawing. When I use a perspective projection, and I move the camera inside the model (I mean, inside the global bounding sphere of the model), the near clipping plane is placed very near to the camera, so to clip as few objects as possible. I like this behavior, and I would like to use it also for Orthogonal projections. But in that case, when I move the camera into the model, the near clipping plane becomes negative, so the viewing volume includes always the whole model. And I don't like this now. Is this the right behavior, or did I miss something/make some mistake? If this is the way it works for orthogonal projections, is there a way to make it work like perspective one? Thanks in advance. Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Hey Abhinav did you tried my early suggestion? put ../ in front of your name or prefix property as I' ve already suggested. the ../ hack is also used in osg CMake files, look at OsgMacroUtils.cmake, in particular line 263 Luigi Abhinav Dubey ha scritto: Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum hey dear it works but the only problem is that it creates a subfolder DEBUG under BIN which i dont want ..i want the files to directly come under BIN. Any solution for this??? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10770#10770 ___ 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] [build] how do i generate project.exe file and .pdb file in specified folder
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RUNTIME_OUTPUT_DIRECTORY $ENV{N3DBINARY_PATH}/N3DApp/Derived/bin/plugins)
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
LIBRARY_OUTPUT_DIRECTORY $ENV{N3DBINARY_PATH}/N3DApp/Derived/bin/plugins)
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY $ENV{N3DBINARY_PATH}/N3DApp/Derived/lib)
IF(MSVC_IDE)
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RELEASE_OUTPUT_NAME ../$ENV{N3DBINARY_PATH})
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
DEBUG_OUTPUT_NAME ../$ENV{N3DBINARY_PATH}plugintest)
This is the entire code that worked for me..thx guyz..! i am a newbee on cmake
will be needing ur help often..thx again guyz..u rock
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10789#10789
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
Thank you again, Robert. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.54 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing On Fri, Apr 24, 2009 at 10:39 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) You can do what you want with the near + far clipping planes in orthographic and perspetive projections simply by switch off the automatic compute of the near and planes via camera-setComputeNearFar(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); But this won't make othrographic magically appropriate for doing internal views. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
HI Gianluca, Arggghhg... You can't use orthographic projects in the same way that you use perspective projections, it simply doesn't work. Use orthographic projections for external views of the scene where clipping is not used. Do *not* use it for internal views where clipping is critical. Try to do this on and you'll just waste lots of your time and lots of the communities time trying to explain to you why it won't work. Robert. On Fri, Apr 24, 2009 at 9:44 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Hi all. I have a strange behavior when I let OSG update the near and far clipping planes during drawing. When I use a perspective projection, and I move the camera inside the model (I mean, inside the global bounding sphere of the model), the near clipping plane is placed very near to the camera, so to clip as few objects as possible. I like this behavior, and I would like to use it also for Orthogonal projections. But in that case, when I move the camera into the model, the near clipping plane becomes negative, so the viewing volume includes always the whole model. And I don’t like this now. Is this the right behavior, or did I miss something/make some mistake? If this is the way it works for orthogonal projections, is there a way to make it work like perspective one? Thanks in advance. Gianluca Natale ___ 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] update of zNear and zFar during drawing
Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) Thanks, Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.02 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing HI Gianluca, Arggghhg... You can't use orthographic projects in the same way that you use perspective projections, it simply doesn't work. Use orthographic projections for external views of the scene where clipping is not used. Do *not* use it for internal views where clipping is critical. Try to do this on and you'll just waste lots of your time and lots of the communities time trying to explain to you why it won't work. Robert. On Fri, Apr 24, 2009 at 9:44 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Hi all. I have a strange behavior when I let OSG update the near and far clipping planes during drawing. When I use a perspective projection, and I move the camera inside the model (I mean, inside the global bounding sphere of the model), the near clipping plane is placed very near to the camera, so to clip as few objects as possible. I like this behavior, and I would like to use it also for Orthogonal projections. But in that case, when I move the camera into the model, the near clipping plane becomes negative, so the viewing volume includes always the whole model. And I dont like this now. Is this the right behavior, or did I miss something/make some mistake? If this is the way it works for orthogonal projections, is there a way to make it work like perspective one? Thanks in advance. Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth 1.1 Released
Paul, Don't know the answer to that yet but I will let you know. If so, we would certainly be happy to do a demo. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Thu, Apr 23, 2009 at 5:44 PM, Paul Martz pma...@skew-matrix.com wrote: Will one of you be at SIGGRAPH this year? The OSG BOF is Wednesday afternoon, and it'd be great to get a demo of osgEarth (if you can get to the internet). I'll post a call for participation as SIGGRAPH approaches. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com +1 303 859 9466 -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Jason Beverage *Sent:* Thursday, April 23, 2009 2:46 PM *To:* osg users *Subject:* [osg-users] osgEarth 1.1 Released Hi all, Cross posting from the osgEarth forums. We've just tagged the osgEarth 1.1 release. Changes in this release include: *Enhanced WCS driver with support for ArcGIS Server *Added GDAL dependency to osgEarth to support new SpatialReference classes *Added new GeoExtent class *Added a memory cache to TileSources to increase performance when performing compositing *Added ability to use Mercator data in a geodetic globe. *All geocentric globes now use a global-geodetic profile now that osgEarth can mix Mercator and Geodetic imagery. *Added ElevationManager class to provide support for multiple heightfield sources *Bug fixes and performance enhancements You can find the tag here: http://wush.net/svn/osgearth/tags/osgearth_1.1_T2009-04-23/ Enjoy! Jason ___ 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] dll tiff
Sounds like it could either be a manifest problem, or your mixing release and debug libs, Also turn up the OSG notify level to debug to get more info , are you sure that image file is being found etc. __ Gordon Tomlinson mailto:gor...@gordontomlinson.com gor...@gordontomlinson.com IM: mailto:gordon3db...@3dscenegraph.com gordon3db...@3dscenegraph.com http://www.vis-sim.com/ www.vis-sim.com http://www.gordontomlinson.com/ www.gordontomlinson.com __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Adaya Lorenzo Sent: Friday, April 24, 2009 7:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] dll tiff I forgot some things. The code is like this: osg::ref_ptrosg::Image dummy; std::string icon_path = C:\\file.tif; dummy = osgDB::readImageFile(icon_path.c_str()); and the dummy returns null. 2009/4/24 Adaya Lorenzo adayalorenzol...@gmail.com Hi! I have some problems with osgdb_tiff and osgdb_tiffd.I have compiled osg 2.8, 3rdStudio with visual studio 2008 express Edition. I used Cmake first and I included all the dependencies for that image format. When I execute a program with that dll (in release or in debug) the dll loads and inmediatly it unloads.Does somebody know why??What can I do?? Thx! -- Adaya Lorenzo Leon -- Adaya Lorenzo Leon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth 1.1 Released
Capaware team will be in SIGGRAPH!!! 2009/4/24 Glenn Waldron gwald...@gmail.com Paul, Don't know the answer to that yet but I will let you know. If so, we would certainly be happy to do a demo. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Thu, Apr 23, 2009 at 5:44 PM, Paul Martz pma...@skew-matrix.comwrote: Will one of you be at SIGGRAPH this year? The OSG BOF is Wednesday afternoon, and it'd be great to get a demo of osgEarth (if you can get to the internet). I'll post a call for participation as SIGGRAPH approaches. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com +1 303 859 9466 -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Jason Beverage *Sent:* Thursday, April 23, 2009 2:46 PM *To:* osg users *Subject:* [osg-users] osgEarth 1.1 Released Hi all, Cross posting from the osgEarth forums. We've just tagged the osgEarth 1.1 release. Changes in this release include: *Enhanced WCS driver with support for ArcGIS Server *Added GDAL dependency to osgEarth to support new SpatialReference classes *Added new GeoExtent class *Added a memory cache to TileSources to increase performance when performing compositing *Added ability to use Mercator data in a geodetic globe. *All geocentric globes now use a global-geodetic profile now that osgEarth can mix Mercator and Geodetic imagery. *Added ElevationManager class to provide support for multiple heightfield sources *Bug fixes and performance enhancements You can find the tag here: http://wush.net/svn/osgearth/tags/osgearth_1.1_T2009-04-23/ Enjoy! Jason ___ 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 -- Adaya Lorenzo Leon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] dll tiff
Hi! I have some problems with osgdb_tiff and osgdb_tiffd.I have compiled osg 2.8, 3rdStudio with visual studio 2008 express Edition. I used Cmake first and I included all the dependencies for that image format. When I execute a program with that dll (in release or in debug) the dll loads and inmediatly it unloads.Does somebody know why??What can I do?? Thx! -- Adaya Lorenzo Leon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dll tiff
I forgot some things. The code is like this: osg::ref_ptrosg::Image dummy; std::string icon_path = C:\\file.tif; dummy = osgDB::readImageFile(icon_path.c_str()); and the dummy returns null. 2009/4/24 Adaya Lorenzo adayalorenzol...@gmail.com Hi! I have some problems with osgdb_tiff and osgdb_tiffd.I have compiled osg 2.8, 3rdStudio with visual studio 2008 express Edition. I used Cmake first and I included all the dependencies for that image format. When I execute a program with that dll (in release or in debug) the dll loads and inmediatly it unloads.Does somebody know why??What can I do?? Thx! -- Adaya Lorenzo Leon -- Adaya Lorenzo Leon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Luigi Calori wrote: Hey Abhinav did you tried my early suggestion? put ../ in front of your name or prefix property as I' ve already suggested. the ../ hack is also used in osg CMake files, look at OsgMacroUtils.cmake, in particular line 263 Luigi Abhinav Dubey ha scritto: Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum hey dear it works but the only problem is that it creates a subfolder DEBUG under BIN which i dont want ..i want the files to directly come under BIN. Any solution for this??? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10770#10770 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Hey thx dear it worked...pdb is also coming along with it in bin. Now i want to move .exp and .lib file too the same way..how can it b done?? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10786#10786 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective texture mapping with occluders/ visibility computation
Hi, Firstly, thanks Paul, it's a good idea, I'll seriously look at it when my projective texture mapping will run correctly. I've got a few questions for you: 1)When I activate the ptm, light of the scene seems to be changed, the only responsible instruction seems to be: Code: texgen-setPlanesFromMatrix(MVPT); Does anyone know why? Can I desactivate it? 2)I'm still working on my ptm but I've some results. Here's a screenshot: [Image: http://img5.hostingpics.net/pics/487500ptm.png ] My question is: Why is the texture stretched? Again, can I desactivate it? 3)It seems I can't do the PTM using osg::TextureRectangle but osg::Texture2D works. I'm running OpenSceneGraph 2.6 maybe this have been fixed since that version. Thus I need to know the new width and height of my resized image (which is done in order to match to Texture2D). But when I execute: Code: ref_ptrImage img = osgDB::readImageFile(../Data_Calibrage/Image/IMG_5316_small.jpg); //TextureRectangle doesn't seem to be supported for projective texture mapping ref_ptrTexture2D tex = new Texture2D(img.get()); std::coutWidth of the texture: tex-getTextureWidth()std::endl; std::coutHeight of the texture: tex-getTextureHeight()std::endl; std::coutWidth of the image of the texture: tex-getImage()-s()std::endl; std::coutHeight of the image of the texture: tex-getImage()-t()std::endl; I've got: Code: 0 0 640 480 How can I know these new width and height ? 4) Is there any tensor product in osg? Thanks a lot to all of you, Max -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10783#10783 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
On Fri, Apr 24, 2009 at 10:39 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) You can do what you want with the near + far clipping planes in orthographic and perspetive projections simply by switch off the automatic compute of the near and planes via camera-setComputeNearFar(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); But this won't make othrographic magically appropriate for doing internal views. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Hello Abhinav, hey dear Err, dear? We don't even know each other. :-) it works but the only problem is that it creates a subfolder DEBUG under BIN which i dont want ..i want the files to directly come under BIN. Any solution for this??? Weird, for me it goes directly into bin. For example, I get both osgversion.exe and osgversiond.exe in OpenSceneGraph\bin. I'm not sure what else to suggest. Maybe try Luigi's suggestion? 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] DBPager continuously reloading tiles
Hi Robert, We could possible provide an env var to provide a hint to DisplaySettings for what the defaults should be. Yes, that would be nice. As a related point, in Vortex we have a frame lock which will sleep a given number of milliseconds at the end of the post-update phase before starting the next frame. The amount of time it sleeps is dictated by a given frame rate, i.e. if the time taken by the pre-update, update, post-update phases was less than say 1/60th of a second then it sleeps for the remaining time. This can be disabled at any time, and the physics work whether it's on or not, it's just to give a consistent user experience whether vsync is on or off. From what you've said you want to do something similar. So then, we'd have three frame-rate control mechanisms: vsync, OSG's mechanism and Vortex's mechanism. So you see why I'd want a way to disable the one in OSG easily (since we have more control over the one in Vortex to make sure it does exactly what we want). Also, I've always been suspicious of this kind of scheme when related to vsync. What if both vsync and the frame-rate control scheme in OSG are turned on, but the frames finish rendering in between vsync cycles. Won't that introduce tearing? We'd have to synchronize the end of OSG frame rendering with the vsync so that the swap occurs at the right time, wouldn't we? (this is a question I have about our own scheme too, I haven't had the chance to look into how it's done that much) Anyways, just curious. 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] update of zNear and zFar during drawing
Robert, is there a quick way to simply update near and far clipping planes for perspective projection, without calling an explicitly redraw (I mean, some visitor that computes for example the bounding box of the model and updates near and far clipping plane also)? Thanks, Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Gianluca Natale Sent: venerdì 24 aprile 2009 12.29 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] update of zNear and zFar during drawing Thank you again, Robert. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.54 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing On Fri, Apr 24, 2009 at 10:39 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) You can do what you want with the near + far clipping planes in orthographic and perspetive projections simply by switch off the automatic compute of the near and planes via camera-setComputeNearFar(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); But this won't make othrographic magically appropriate for doing internal views. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Qt4.5 + Textures
please... [Shocked] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10802#10802 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 300 forum members
Hi folks, if somebody of you is interested in the numbers, I have computed the overlap between mailing list members and the forum users. There are currently: 1825 mailing list users. 300 forum users and 106 users, who are registered on both systems. Of course this is just an overlap by comparing the email adresses. This doesn't mean that the other 200 forum users are do not use the mailing list too. However this can be seen as a simple overlap measure ;) Cheers, art[/b] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10803#10803 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi JS, On Fri, Apr 24, 2009 at 2:37 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: As a related point, in Vortex we have a frame lock which will sleep a given number of milliseconds at the end of the post-update phase before starting the next frame. The amount of time it sleeps is dictated by a given frame rate, i.e. if the time taken by the pre-update, update, post-update phases was less than say 1/60th of a second then it sleeps for the remaining time. This can be disabled at any time, and the physics work whether it's on or not, it's just to give a consistent user experience whether vsync is on or off. From what you've said you want to do something similar. The frame scheme I'm working on right now only affect Viewer::run(), and you'll be able to switch it on/off as well. So if you don't use Viewer::run() then you won't get this facility, and even if you do use run then you'll be able to control the whether or not it does cap the frame rate. So then, we'd have three frame-rate control mechanisms: vsync, OSG's mechanism and Vortex's mechanism. So you see why I'd want a way to disable the one in OSG easily (since we have more control over the one in Vortex to make sure it does exactly what we want). Also, I've always been suspicious of this kind of scheme when related to vsync. What if both vsync and the frame-rate control scheme in OSG are turned on, but the frames finish rendering in between vsync cycles. Won't that introduce tearing? We'd have to synchronize the end of OSG frame rendering with the vsync so that the swap occurs at the right time, wouldn't we? (this is a question I have about our own scheme too, I haven't had the chance to look into how it's done that much) If vsync is on then the OSG side frame capping won't affect this, it won't cause tearing. The OSG frame rate capping might cause you to loose a frame occasionally though as the microSleep timing code is not perfectly accurate. The frame rate capping can be turned off so if you have vysnc on this may well be what you'd want to do. I'm still playing with the implementation + API. More info once I have something concrete to share. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
On Fri, Apr 24, 2009 at 2:42 PM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Robert, is there a quick way to simply update near and far clipping planes for perspective projection, without calling an explicitly redraw (I mean, some visitor that computes for example the bounding box of the model and updates near and far clipping plane also)? There is no quick way, you'll need to do this by hand. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Qt4.5 + Textures
On Fri, Apr 24, 2009 at 2:48 PM, Bence Frenyo bence.fre...@gmail.com wrote: please... [Shocked] Shocked by what?? You do a particular combination of stuff and then ask a question about something that few others know anything about. Are you expecting us all to have integrated OSG and QT 4.5 and do texture maipulation exactly how you've done? Are you expecting one the second free support? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi Robert, The frame scheme I'm working on right now only affect Viewer::run(), and you'll be able to switch it on/off as well. So if you don't use Viewer::run() then you won't get this facility, and even if you do use run then you'll be able to control the whether or not it does cap the frame rate. OK, good to know. So it's for convenience but will not impede applications that are already doing something more involved than Viewer::run(). That's great. If vsync is on then the OSG side frame capping won't affect this, it won't cause tearing. The OSG frame rate capping might cause you to loose a frame occasionally though as the microSleep timing code is not perfectly accurate. Great, that's fine. The frame rate capping can be turned off so if you have vysnc on this may well be what you'd want to do. I'm still playing with the implementation + API. More info once I have something concrete to share. OK, looking forward to it. 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] 300 forum members
Hi Art, The osg-users list has 1850 members on it right now. I can only guess that page you've got the members off isn't listing all members (it's possible to declare your account hidden). Still interesting overlap data. Suggests the combined total is around 2040 members. Robert. On Fri, Apr 24, 2009 at 2:59 PM, Art Tevs arti_t...@yahoo.de wrote: Hi folks, if somebody of you is interested in the numbers, I have computed the overlap between mailing list members and the forum users. There are currently: 1825 mailing list users. 300 forum users and 106 users, who are registered on both systems. Of course this is just an overlap by comparing the email adresses. This doesn't mean that the other 200 forum users are do not use the mailing list too. However this can be seen as a simple overlap measure ;) Cheers, art[/b] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10803#10803 ___ 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] Deploying on Vista vs. Deploying on XP
Thomas Hogarth schrieb: Hi I've deployed a few apps across platforms now, and the best advise I can give is to make sure that if you change dev environment (i.e. vs2003 to vs2005) make sure you recompile everything with the new dev env (even stuff like alut :( ) On a worse note. I did once deploy a simple proof of concept app on XP then got asked to quickly ( lol) get it working on vista. It kept on crashing, in the end I never found out the real cause, but building my scene graph in a slightly different way made it work (no idea). So good luck, but vista appears to be a beast in itself (bring on windows 7 :) ) Hi, I agree. I had thought that I could avoid setting up a Vista machine and get on to Windows 7 directly, but I might have to reconsider this. I have now carefully checked again all libs, and I am sure that they all link against the same runtime. I will perhaps ship a mingw-built executable as an alternative. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + Qt4.5 + Textures
robertosfield wrote: Shocked by what?? Note that users in the forum can easily add emoticons through clicking on an image. Mailing list users will not see the emoticons but the BBCode that was used. I don't know if these are replaced by an alternative textual representation. Art will have to answer that. Vice versa users in the forum will see emoticons appear in strange locations if source code is posted on the forum. -- Roland Here are all available emoticons: :D :) :( :o [Shocked] :? 8) [Laughing] :x :P [Embarassed] [Crying or Very sad] [Evil or Very Mad] [Twisted Evil] [Rolling Eyes] [Wink] [Exclamation] [Question] [Idea] [Arrow] :| [Mr. Green] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10811#10811 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hello now ive implemented my own Pick Handler and it runs perfect with the LineSegmentIntersector thanks a lot !! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10812#10812 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] osgParticle ParticleSystemandModularEmitterin different coordinate systems
Hi Robert, I've moved this discussion over to osg-users. Attached are some examples that should show the precision problem I'm running into. There are 4 osg files. The first one, particle.osg, is just a plain particle effect emmitting smoke. The other osg files are based on this model. The second file, particle_move_6M.osg, is the particle.osg with the top group node replaced by a MatrixTransform with it's X translation set to 600. From your previous email I think you didn't expect the particles to stay with the rest of the geometry. With the September change to ModularEmitter.cpp there are three transformations on a particle instead of two. Notice how the particles move with the MatrixTransform instead of the world coordinate system. Some may want this effect while others wouldn't. For smoke like this I think the particles should stay in the world coordinate system once emitted. The third example, particle_move_6M_new_code.osg, is the particle.osg modified as I had described below (in my last email) for the September code change. You will need to press the space bar in osgviewer to see the model. You should notice how the particle effects are not smooth due to precision problems. What isn't observable is the direction particles are emitted also have precision problems. Notice how the particles, once emitted, operate in the world coordinate system. The fourth example, particle_move_6M_old_code.osg, is designed to work with ModularEmitter before the September change. This is also described below. Particle effects are smooth since the precision issues are taken care of by the double precision in MatrixTransform. Also, Particles, once emitted, operate in the world coordinate system. Tom Jolley -Original Message- From: Jolley, Thomas P Sent: Thursday, April 23, 2009 11:17 AM To: OpenSceneGraph Submissions Subject: Re: [osg-submissions] osgParticle ParticleSystemandModularEmitterin different coordinate systems Hi Robert, -Original Message- From: Robert Osfield Hi Tom, I wouldn't expect the cessnafire.osg model to work under a moving MatrixTransform, this is a known attribute of osgParticle - you have to move the ParticleSystem outside of any moving models, you can't leave it from within the moving subgraph otherwise the particles get transformed twice. This is how it worked before the September change. With the change it sort of works under a MatrixTransform. The change seems to undo any MatrixTransforms above the particle system. I don't know enough about what Tim was trying to correct but it looks almost like fixing this attribute of osgParticle. The osgparticleeffects example illustrates how to handling moving models and particle systems. I'll take a closer look at this example. I'll see if I can come up with some examples that demonstrate the problem I'm running into. In your own case I don't know what to make of the issues, could it be that you aren't constructing your particle system appropriately for moving models, or is it that you have a genuine precision issue that is unrelated to the moving model issue? Tim's submission was intended to address some of the precisions issues, so it's disappointing that in some usage case it might have made things worse. Reverting this change would break the problem Tim was trying to solve though, so I'm very reluctant to do this without clear illustration of problems and a solution that addresses both the issues you are seeing and the ones that Tim was seeing. My construction and rearangement of a model like cessnafire.osg worked just fine before the September change. I had no particle placement or precision issues precisely because of how I rearanged the model and added additional MatrixTransforms above the ModularEmitters and Geodes with Particles. I suppose a picture is worth a thousand words. Original graph Group -+ | +--Geode of main Body | +--Modular Emitter | +--Geode for particles | +--ParticleSystemUpdater Modified graph Group--+ | +--MatrixTransform 1--+ | | | +--Geode of main Body | +--MatrixTransform 2--+ | | | +--Modular Emitter | +--MatrixTransform 3--+ | | | +--Geode for particles | +--ParticleSystemUpdater With the modified graph I set the model position and attitude with MT1. I set MT3 to a translation where the model will be used and do not update it. MT2 uses the rotation of MT1 and the translation is set to MT1's translation minus MT3's translation. This keeps everything well withing single precision values and avoids the known
[osg-users] determine record type from OpenFlight files?
I am loading an OpenFlight file using osgDB and I need to do some additional processing based on the specific record types, specifically terrain and roads. From looking at the OpenFlight loader in osg 2.6, it seems that this information is read by OSG (there is a flag indicating terrain and roads have a special record type) but I cannot figure out how to access this information from the scene graph that is actually returned by osgDB::readNodeFile() -- it does not appear that this information is set in the node's UserData. Does anyone have any suggestions on how to get this information? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] determine record type from OpenFlight files?
You're right, the OpenFlight importer doesn't preserve the record type in the UserData. You'll need to modify the OpenFlight importer to store the necessary information. I'd suggest using the Node DescriptionList and storing the record as a simple std::string, much less complicated than trying to use UserData for this task. If you modify the code in such a way that this is done based on a ReaderWriter::Option, you could commit your change back to OSG. 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 Peter Amstutz Sent: Friday, April 24, 2009 10:08 AM To: OpenSceneGraph Users Subject: [osg-users] determine record type from OpenFlight files? I am loading an OpenFlight file using osgDB and I need to do some additional processing based on the specific record types, specifically terrain and roads. From looking at the OpenFlight loader in osg 2.6, it seems that this information is read by OSG (there is a flag indicating terrain and roads have a special record type) but I cannot figure out how to access this information from the scene graph that is actually returned by osgDB::readNodeFile() -- it does not appear that this information is set in the node's UserData. Does anyone have any suggestions on how to get this information? Thanks, Peter ___ 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] Picking Problem PolytopeIntersector
Glad to elaborate. (However, I fear I'm about to earn the nickname of that raving lunatic who insists on using polytopes for picking... :-) When you do a mouse pick, you generally are trying to pick an object that falls into a small screen-space box around the cursor. In a perspective view, the box has smaller world-space extents at the near plane, and larger world-space extents at the far plane. In essence, it looks like a view frustum. PolytopeIntersector is the only intersector that accurately represents this pick volume. A line segment is less accurate because it does a poor job of representing that view volume. And in fact, the line segment becomes less and less accurate when you try to pick objects that are farther and farther away from the viewer. 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 Jason Daly Sent: Thursday, April 23, 2009 5:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Picking Problem PolytopeIntersector Paul Martz wrote: You _can_ use a line segment for mouse click picking, but in a perspective view, polytope is really better suited for this task. Also, polytope will pick point and line primitives, while line segment intersection will miss them. Unless you're dealing with points/lines, I'm failing to see why a polytope is really better suited for this task. I also fail to see why accuracy would be a problem when using line segments (unless you're trying to pick something one or two pixels wide, which doesn't happen often in my experience). Can you elaborate a bit (or point me at something that explains it)? --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] IntersectVisitor vs IntersectionVisitor
Something I just came across, trying to figure out why my line-of-sight tests were not using KdTrees: Would I be correct in thinking that osgUtil::IntersectVisitor is the old and deprecated way of doing intersection tests, and osgUtil::IntersectionVisitor is the new way to do it? Is there a reason (besides backwards compatibility) for IntersectVisitor to even still exist? Also, what's the difference between osgUtil::IntersectionVisitor and osgSim::LineOfSight? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 2 GraphicContexts, 2 viewports, 2 cameras and 1 scene question
Hi, I created 2 cameras each one with their own viewport and GraphicContext. I have one scene. Inside the scene I have a group node that contains 2 children. Each child has a different node mask. I was trying to make one camera showing one child and the other camera showing the other child inside the scene graph by modifying the CullMask of the camera(for the first camera I set the cullMask the same as the node mask of the first child and for the second camera I set the mask the same as the node mask of the second child). Unfortunatelly, something is wrong because both cameras show me the first child. Could you please help me ? What am I doing wrong? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10819#10819 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] line intersection performance
A couple of other questions related to intersection performance: 1) The current KdTree implementation is just for sorting triangle geometry at node leaves. Perhaps it would be useful to to have a KdTree organize the scene graph nodes themselves, based on bounding volumes? Or are bounding volume tests generally good enough (and it's up to the user to be clever about organizing the scene graph?) 2) I need to do line-of-sight tests where I am only interested in whether any intersection exists, and not what those intersections are. This allows for a trap door optimization where the search process terminates on the first positive intersection. Is there a way to do that with the current osgUtil::IntersectionVisitor, or do I need to modify it to serve this purpose? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IntersectVisitor vs IntersectionVisitor
HI Peter, On Fri, Apr 24, 2009 at 6:14 PM, Peter Amstutz peter.amst...@tseboston.com wrote: Would I be correct in thinking that osgUtil::IntersectVisitor is the old and deprecated way of doing intersection tests, and osgUtil::IntersectionVisitor is the new way to do it? Is there a reason (besides backwards compatibility) for IntersectVisitor to even still exist? OsgUtil::IntersectVisitor only exists for backwards compatibility. Reviewing the headers right now reveals that the deprecated status wasn't mention so I've just added this and checked it into svn/trunk and OSG-2.8 branch Also, what's the difference between osgUtil::IntersectionVisitor and osgSim::LineOfSight? osgSim::LineOfSight is a higher level classes that manages line of sight calculations and handling of paged databases automatically. IntersectionVisitor is used within the LineOfSight class. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2 GraphicContexts, 2 viewports, 2 cameras and 1 scene question
Hi Cristina, Have a look at the osgstereoimage example as this does something quite similar. Robert. On Fri, Apr 24, 2009 at 6:18 PM, Cristina cristina.pap...@meggitt.com wrote: Hi, I created 2 cameras each one with their own viewport and GraphicContext. I have one scene. Inside the scene I have a group node that contains 2 children. Each child has a different node mask. I was trying to make one camera showing one child and the other camera showing the other child inside the scene graph by modifying the CullMask of the camera(for the first camera I set the cullMask the same as the node mask of the first child and for the second camera I set the mask the same as the node mask of the second child). Unfortunatelly, something is wrong because both cameras show me the first child. Could you please help me ? What am I doing wrong? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10819#10819 ___ 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] line intersection performance
Hello Peter, Funny that there are so many intersection questions lately. 1) The current KdTree implementation is just for sorting triangle geometry at node leaves. Perhaps it would be useful to to have a KdTree organize the scene graph nodes themselves, based on bounding volumes? Or are bounding volume tests generally good enough (and it's up to the user to be clever about organizing the scene graph?) A bouding volume hierarchy is generally pretty fast. There have been publications lately on how a good BVH can be as fast as a badly balanced kd-tree, and well balancing a kd-tree brings additional performance concerns for dynamic scenes, and so a BVH is generally preferable for dynamic scenes. Of course, this assumes your scene graph is organized spatially, which is not always the case (or even most of the time). Subgraphs may be spatially organized (i.e. a vehicle will be under a group, parts of the vehicle's engine will be under a group that's under the vehicle's group, etc.) but in many cases I've seen, all or most distinct objects will be directly under the scene root (all buildings, all vehicles, all characters, etc.). It would be better to group a few close-by buildings under a group, then a few of those clusters under another group, etc. to get a better hierarchy. But this is the same concern as when you want to optimize frustum culling performance. If the kd-tree or the cull visitor has to test lots and lots of individual objects, it will be slower than testing clusters and discarding the whole cluster if it can. So the answer IMHO would be that in any case, you will want to try and build a good scene graph (both for culling performance and intersection performance). Whether you want to make a global kd-tree for the whole scene will depend on how dynamic your scene is, and if you can take the time to implement it so that only parts that change need updating. 2) I need to do line-of-sight tests where I am only interested in whether any intersection exists, and not what those intersections are. This allows for a trap door optimization where the search process terminates on the first positive intersection. Is there a way to do that with the current osgUtil::IntersectionVisitor, or do I need to modify it to serve this purpose? This is not implemented currently. It's another one of those little projects I'd like to do eventually. It's what some publications call test-intersection vs find-intersection. Test-intersection: If all you want to know is if something intersects (for example, for shadow tests in raytracing) some shortcuts can be taken. Find-intersection: If you really want to find all objects that intersect (and potentially then sort by distance so you can get the closest one) (for example, for the main rays in raytracing) then you'd do it more or less the way it's done right now. If you want to implement test-intersection, you could subclass IntersectionVisitor/LineSegmentIntersector, or you could do it directly in these classes as an option and then submit it to OSG. :-) 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] line intersection performance
Hi Peter, On Fri, Apr 24, 2009 at 6:21 PM, Peter Amstutz peter.amst...@tseboston.com wrote: A couple of other questions related to intersection performance: 1) The current KdTree implementation is just for sorting triangle geometry at node leaves. Perhaps it would be useful to to have a KdTree organize the scene graph nodes themselves, based on bounding volumes? Or are bounding volume tests generally good enough (and it's up to the user to be clever about organizing the scene graph?) A good scene graph will be built up in the same structure as a KdTree, it's just coarse grained .i.e. at whole node/geometry level rather than individual triangles like the KdTree does. Given this there really isn't too much to be gained by trying to graft a KdTree into the scene nodes themselves. 2) I need to do line-of-sight tests where I am only interested in whether any intersection exists, and not what those intersections are. This allows for a trap door optimization where the search process terminates on the first positive intersection. Is there a way to do that with the current osgUtil::IntersectionVisitor, or do I need to modify it to serve this purpose? Not at present. I see that JS expands on this topic so I won't comment further. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi Paul, When you do a mouse pick, you generally are trying to pick an object that falls into a small screen-space box around the cursor. In a perspective view, the box has smaller world-space extents at the near plane, and larger world-space extents at the far plane. In essence, it looks like a view frustum. PolytopeIntersector is the only intersector that accurately represents this pick volume. Yes, but this is only a problem if the user clicks on the pixels at the edge of the object (or the limit case, if the object occupies only one pixel on screen). The chances that the user will click just at the edge of the object and the ray will miss are really small. Generally the object is big enough on screen (even if the object occupies 5x5 pixels I'd be surprised to see a user click on the edge, most of the time they'll click in the middle). Every developer is free to make the choices they want. I consider this case much too infrequent, and it has not been a problem for us. I have not had one user tell me hey, I should have selected the object then but I didn't. 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] On demand and frame rate capping schemes from Viewer::run()
Hi All,
When following up on a bug report about the pager not handling on
demand/lazy frame rendering I resolved the the problems wasn't down to
the pager, just the way the end user viewer code was set up to the the
on demand frame rendering. Rather than leave this type of viewer
usage open to end users come up with lots of different schemes to
attempt to the same thing, and with it the potential fall out in terms
of support of trying to help debug them I've coded up a solution for
osgViewer that can either be used directly or as a template for others
to learn from.
What I have done is to refactor osgViewer::ViewerBase::run() so that
it's frame loop now has two new capabilities:
1) On demand (lazy) frame rendering vs Continuous frame rendering
(the original functionality, and still the default.)
2) Optional frame rate capping to a specified maximum frame rate
(defaults to off.)
Now item 2 isn't a required for on demand frame rendering, but it more
for coping with end user system not having vsync enabled by default.
Since I was working on this piece of code I thought I'd tackle this
item as well. The actual ViewerBase::run() method (use by both Viewer
and CompositeViewer) now looks like:
int ViewerBase::run()
{
if (!isRealized())
{
realize();
}
const char* str = getenv(OSG_RUN_FRAME_COUNT);
int runTillFrameNumber = str==0 ? -1 : atoi(str);
while(!done() || (runTillFrameNumber=0
getViewerFrameStamp()-getFrameNumber()runTillFrameNumber))
{
double minFrameTime = _runMaxFrameRate0.0 ? 1.0/_runMaxFrameRate : 0.0;
osg::Timer_t startFrameTick = osg::Timer::instance()-tick();
if (_runFrameScheme==ON_DEMAND)
{
if (checkNeedToDoFrame()) frame();
}
else
{
frame();
}
// work out if we need to force a sleep to hold back the frame rate
osg::Timer_t endFrameTick = osg::Timer::instance()-tick();
double frameTime =
osg::Timer::instance()-delta_s(startFrameTick, endFrameTick);
if (frameTime minFrameTime)
OpenThreads::Thread::microSleep(100.0*(minFrameTime-frameTime));
}
return 0;
}
The code isn't final yet, but is certainly good enough for us to start
testing. You can test it by setting the env vars:
OSG_RUN_FRAME_SCHEME=ON_DEMAND
or go back to default
OSG_RUN_FRAME_SCHEME=CONTINUOUS
And
OSG_RUN_MAX_FRAME_RATE=60.0
or switch off and the default
OSG_RUN_MAX_FRAME_RATE=0.0
You can also use the following command line options:
osgviewer cow.osg --run-on-demand
osgviewer cow.osg --run-continuous
osgviewer cow.osg --run-continuous --run-max-frame-rate 30.0
The on demand frame rendering does already support paged databases,
and I've updated various event handles to manually do a
requestRedraw() which prompts the viewer::run() to rendering a new
frame. What I have got working yet is handling of the update visitor
doing updates. so on demand rendering just freezes things like
particle systems and animations till you move the eye point, trigger
an event. I'll have a look at support event callbacks next.
Please note this support only affect viewer::run() it doesn't effect
apps that roll their own frame loop.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2 GraphicContexts, 2 viewports, 2 cameras and 1 scene question
Hi Robert, The osgstereoimage example does not create 2 cameras. Also I'm not sure what osg::DisplaySettings::instance()-setStereo(true); does, but I don't think this example helps me. I could have n number of viewports each one with their own camera, and when I traverse the scene graph, based on a certain mask I would like to show different thingsTo be more precise, some cameras will show objects with day texture and some will show objects with thermo texture. Regards, Cristina -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10828#10828 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] line intersection performance
Hi Jean-Sébastien, Jean-Sébastien Guay wrote: So the answer IMHO would be that in any case, you will want to try and build a good scene graph (both for culling performance and intersection performance). Whether you want to make a global kd-tree for the whole scene will depend on how dynamic your scene is, and if you can take the time to implement it so that only parts that change need updating. In my case I am reading OpenFlight files produced by a third party, so I don't have much control over whether it was constructed efficiently or not. Since the terrain will be static, my thought was to build a mostly static KdTree of scene graph nodes separate from the normal rendering state graph and to be used for culling and intersection tests. I believe a number of other 3D engines use this approach. However my question was really whether something like this already existed in OSG, to which the answer is no. This is not implemented currently. It's another one of those little projects I'd like to do eventually. It's what some publications call test-intersection vs find-intersection. Test-intersection: If all you want to know is if something intersects (for example, for shadow tests in raytracing) some shortcuts can be taken. Find-intersection: If you really want to find all objects that intersect (and potentially then sort by distance so you can get the closest one) (for example, for the main rays in raytracing) then you'd do it more or less the way it's done right now. If you want to implement test-intersection, you could subclass IntersectionVisitor/LineSegmentIntersector, or you could do it directly in these classes as an option and then submit it to OSG. :-) I do need this feature, so I will look into implementing it in osgUtil::IntersectionVisitor. This should be as simple as setting a flag, I think, and modifying the traversal to return as soon as an intersection is found. I will let the list know how it goes. Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2 GraphicContexts, 2 viewports, 2 cameras and 1 scene question
Thanks Robert. I was able to figure it out. My culling mask was wrong. Regards, Cristina -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10830#10830 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IntersectVisitor vs IntersectionVisitor
Thanks Robert. For anyone on this list using Delta 3D: I actually ran into this because Delta 3D 2.2 dtCore::Isector wrapper still uses osg::IntersectVisitor instead of osgUtil::InteresctionVisitor. I've informed the Delta 3D team that this is obsolete and should be updated. Peter Robert Osfield wrote: HI Peter, On Fri, Apr 24, 2009 at 6:14 PM, Peter Amstutz peter.amst...@tseboston.com wrote: Would I be correct in thinking that osgUtil::IntersectVisitor is the old and deprecated way of doing intersection tests, and osgUtil::IntersectionVisitor is the new way to do it? Is there a reason (besides backwards compatibility) for IntersectVisitor to even still exist? OsgUtil::IntersectVisitor only exists for backwards compatibility. Reviewing the headers right now reveals that the deprecated status wasn't mention so I've just added this and checked it into svn/trunk and OSG-2.8 branch Also, what's the difference between osgUtil::IntersectionVisitor and osgSim::LineOfSight? osgSim::LineOfSight is a higher level classes that manages line of sight calculations and handling of paged databases automatically. IntersectionVisitor is used within the LineOfSight class. 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] line intersection performance
On Fri, Apr 24, 2009 at 7:45 PM, Peter Amstutz peter.amst...@tseboston.com wrote: Hi Jean-Sébastien, Jean-Sébastien Guay wrote: So the answer IMHO would be that in any case, you will want to try and build a good scene graph (both for culling performance and intersection performance). Whether you want to make a global kd-tree for the whole scene will depend on how dynamic your scene is, and if you can take the time to implement it so that only parts that change need updating. In my case I am reading OpenFlight files produced by a third party, so I don't have much control over whether it was constructed efficiently or not. Since the terrain will be static, my thought was to build a mostly static KdTree of scene graph nodes separate from the normal rendering state graph and to be used for culling and intersection tests. I believe a number of other 3D engines use this approach. However my question was really whether something like this already existed in OSG, to which the answer is no. If your data is stored in a flat group the osgUtil::Optimizer spatialize groups visitor will be able to build a quad tree for you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] On demand and frame rate capping schemes from Viewer::run()
On Fri, Apr 24, 2009 at 8:11 PM, Roland Smeenk roland.sme...@tno.nl wrote: Interesting development. For a current project we need one view that runs at 5 Hz and several other views that run at 15 Hz (all in separate graphicscontexts). No, I am not joking. This is used to simulate real life camera behaviour. We do our own version of the frame method, but that still is too high level for achieving the required timing granularity. How about this? This type of frame rate management is well beyond what I'd expect the viewer convenience methods like run to handle. You should expect to roll your own frame management for this type of app. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] On demand and frame rate capping schemes from Viewer::run()
Interesting development. For a current project we need one view that runs at 5 Hz and several other views that run at 15 Hz (all in separate graphicscontexts). No, I am not joking. This is used to simulate real life camera behaviour. We do our own version of the frame method, but that still is too high level for achieving the required timing granularity. How about this? kind regards, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10832#10832 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
Hi Robert, I have seen this problem (in my case manifested by having the road draw on top of buildings (!) next to the road) in OSG 2.6 so I am glad to know it is a bug in the OpenFlight loader. In my application, I have had success with osg::PolygonOffset(1.0f, 4.0f) to push the terrain below the roads (rather than the roads above the terrain; I thought I read somewhere that negative values in glPolygonOffset are not allowed but I guess I was mistaken). I presume that osg::PolygonOffset(-1.0f, -4.0f) applied to the roads would produce the same effect. I also have the roads in a separate render bin that renders after the terrain and set the depth test function on roads to be LEQUAL instead of LESS to ensure that z buffer ties are broken in the favor of the road surface. - Peter Robert Osfield wrote: Hi OpenFlight users, I had a support email this morning that led me to investigate problems with the way the OSG's present OpenFlight plugin handles subsurfaces. The particular problem observed was that a road that had been modelled in creator was clipping out vehicles on top of the road. I investigated and found out that the OpenFlight loaded was created used code from src/osgPlugins/OpenFlight/GeometryRecords.cpp: 386 static osg::ref_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::LESS, 0.0, 1.0,false); 390 stateset-setAttribute(depth.get()); The use of static vars was a bit dodgy so I replaced these with variables stored in Document, but this is really just an side show to the real problem - the excessive PolygonOffset settings, a factor of -10, and units -40 is very aggressive a setting pushing out the subsurfaces way further than is either necessary or safe. Scaling these values back to -1, -1 resulted in my better results on the models I have without causing problems with the subsurfaces having z fighting. -1, -1 may be too conservative though. I'd like to get feedback from the community on what works for your OpenFlight models. I've checked in my changes into svn/trunk and the OSG-2.8 branch. It'd be useful to import OpenFlight models and convert to .osg or .ive and then update the OSG version + compile it, then redo the conversion, then compare the before and after results. As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. On all these counts I really like feedback. Was sub surfaces working OK for you prior to my changes today, or do todays changes improve things? 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] On demand and frame rate capping schemes from Viewer::run()
This type of frame rate management is well beyond what I'd expect the viewer convenience methods like run to handle. You should expect to roll your own frame management for this type of app. That's what I thought you would answer. Well, didn't hurt to try. Thanks. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10836#10836 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] line intersection performance
Robert Osfield wrote: If your data is stored in a flat group the osgUtil::Optimizer spatialize groups visitor will be able to build a quad tree for you. Oh excellent, just what I had in mind :-) Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] determine record type from OpenFlight files?
I just realized... One issue with DescriptionList is that the OpenFlight plugin uses it for Comment record data. This is really only a problem if you load a FLT file, store the record type in the DescriptionList, and then export it back out. Your record type data would then be exported as comment records, which is probably not what you want. I don't really see this as a showstopper issue though. Go for it. 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 Peter Amstutz Sent: Friday, April 24, 2009 11:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] determine record type from OpenFlight files? Hmm, I never noticed the DescriptionList feature before -- I presume DescriptionList gets saved to and loaded from .osg and .ive files? That would simplify some other work I did to add custom attributes to nodes (which I acomplished using UserData, but it is a bit more complicated). I will take a look at the OpenFlight importer. Thanks, Peter Paul Martz wrote: You're right, the OpenFlight importer doesn't preserve the record type in the UserData. You'll need to modify the OpenFlight importer to store the necessary information. I'd suggest using the Node DescriptionList and storing the record as a simple std::string, much less complicated than trying to use UserData for this task. If you modify the code in such a way that this is done based on a ReaderWriter::Option, you could commit your change back to OSG. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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] line intersection performance
Hello Peter, However my question was really whether something like this already existed in OSG, to which the answer is no. Indeed. And in your use case I agree that a kd-tree would be pretty efficient. Perhaps we could have a scheme where kd-trees can be turned on or off for particular subgraphs, so that static parts of the scene will use them and dynamic parts will use the BVH. I do need this feature, so I will look into implementing it in osgUtil::IntersectionVisitor. This should be as simple as setting a flag, I think, and modifying the traversal to return as soon as an intersection is found. I will let the list know how it goes. Yep, that should do it. 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] OpenSceneGraph-2.9.4 dev release tagged
Hi All, I've just tagged 2.9.4, you cn read about it on my blog: http://blog.openscenegraph.org. Time for me to adjourn for the evening/weekend. Have fun! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3d Triangle mesh generator
First pass at a 2/3D mesh generator to improve on DelayneyTriangulator. It's based on the Poisson surface reconstruction technique here (http://www.cs.jhu.edu/~misha/Code/PoissonRecon/) So far I have done a minimal OSG interface to the existing code (see GridTriangulator/GridTriangulator.cpp) an example usage is in osgtest.cpp See GridTriangulator file for more explanation. Sample 2d data is in sample.osg, for 3d any of the normal models work well. You can download the original source form the above link, the file sample.npts is the same data in the format required. Martin (ps - this was bounced form the list because of the size of the attachment - see the forums for the download file) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10842#10842 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] On demand and frame rate capping schemes fromViewer::run()
Hi Robert -- You said the code isn't final yet, but I wondered if the
osgviewer options and environment variables are final? Or do you intend to
remove them after development?
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: Friday, April 24, 2009 12:13 PM
To: OpenSceneGraph Users
Subject: [osg-users] On demand and frame rate capping schemes
fromViewer::run()
Hi All,
When following up on a bug report about the pager not handling on
demand/lazy frame rendering I resolved the the problems wasn't down to the
pager, just the way the end user viewer code was set up to the the on demand
frame rendering. Rather than leave this type of viewer usage open to end
users come up with lots of different schemes to attempt to the same thing,
and with it the potential fall out in terms of support of trying to help
debug them I've coded up a solution for osgViewer that can either be used
directly or as a template for others to learn from.
What I have done is to refactor osgViewer::ViewerBase::run() so that it's
frame loop now has two new capabilities:
1) On demand (lazy) frame rendering vs Continuous frame rendering (the
original functionality, and still the default.)
2) Optional frame rate capping to a specified maximum frame rate
(defaults to off.)
Now item 2 isn't a required for on demand frame rendering, but it more for
coping with end user system not having vsync enabled by default.
Since I was working on this piece of code I thought I'd tackle this item as
well. The actual ViewerBase::run() method (use by both Viewer and
CompositeViewer) now looks like:
int ViewerBase::run()
{
if (!isRealized())
{
realize();
}
const char* str = getenv(OSG_RUN_FRAME_COUNT);
int runTillFrameNumber = str==0 ? -1 : atoi(str);
while(!done() || (runTillFrameNumber=0
getViewerFrameStamp()-getFrameNumber()runTillFrameNumber))
{
double minFrameTime = _runMaxFrameRate0.0 ? 1.0/_runMaxFrameRate :
0.0;
osg::Timer_t startFrameTick = osg::Timer::instance()-tick();
if (_runFrameScheme==ON_DEMAND)
{
if (checkNeedToDoFrame()) frame();
}
else
{
frame();
}
// work out if we need to force a sleep to hold back the frame rate
osg::Timer_t endFrameTick = osg::Timer::instance()-tick();
double frameTime =
osg::Timer::instance()-delta_s(startFrameTick, endFrameTick);
if (frameTime minFrameTime)
OpenThreads::Thread::microSleep(100.0*(minFrameTime-frameTime));
}
return 0;
}
The code isn't final yet, but is certainly good enough for us to start
testing. You can test it by setting the env vars:
OSG_RUN_FRAME_SCHEME=ON_DEMAND
or go back to default
OSG_RUN_FRAME_SCHEME=CONTINUOUS
And
OSG_RUN_MAX_FRAME_RATE=60.0
or switch off and the default
OSG_RUN_MAX_FRAME_RATE=0.0
You can also use the following command line options:
osgviewer cow.osg --run-on-demand
osgviewer cow.osg --run-continuous
osgviewer cow.osg --run-continuous --run-max-frame-rate 30.0
The on demand frame rendering does already support paged databases, and I've
updated various event handles to manually do a
requestRedraw() which prompts the viewer::run() to rendering a new
frame. What I have got working yet is handling of the update visitor
doing updates. so on demand rendering just freezes things like particle
systems and animations till you move the eye point, trigger an event. I'll
have a look at support event callbacks next.
Please note this support only affect viewer::run() it doesn't effect apps
that roll their own frame loop.
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] 3d Triangle mesh generator
Hi Martin, (ps - this was bounced form the list because of the size of the attachment - see the forums for the download file) Nah, it got to the list just fine, at 11:59PM EST yesterday - see http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/43650 The auto-reply you get saying that the message has to be approved is not true, I get it all the time too, but the message gets there (and too fast for it to be approved by anybody...). I wonder if it could be disabled. However, what was the intent of this message? Do you want this generator to be integrated into OSG? If so, you should send it to osg-submissions. And the example should be set up as other OSG examples, with a meaningful name and associated CMakeLists.txt. 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] 3d Triangle mesh generator
Hello Martin, I think it needs more testing and input from some more knowledgeable users before it's included in the main source. osg-submissions could still be appropriate, Robert will often review work-in-progress and give comments even if the code is not ready to be merged yet. It's just a way to not let it get drowned in the other questions. Since it includes a considerable amount of 3rd party code it might be better as a plugin. Is there an example of writing a none fileIO pugin? Well, plugins that modify the loaded model in some way include the .rot, .trans, .scale pseudo-loaders, also .normals, ... Basically look for anything that doesn't look like a file extension :-) 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
