Re: [osg-users] osgexport for blender?
Damyon Wiese writes: Hi Amigoface, Sorry - I think this commit to blender changed one of the import paths. http://comments.gmane.org/gmane.comp.video.blender.scm/22522 Ie - my blender auto updated and I had to change one of the import paths to make the script work - but obviously that broke the script for blender versions before the above commit. Yes — indeed I had to compile Blender from the latest SVN version in order to be able to use it. If you try to use the precompiled Blender version offered in the official page, you will have the same error. Damyon, do you have some sort of public repository? That way we could try the script at our ends, and integrate the changes easily instead of having to do all the work by yourself. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 cursor setting - Single- vs Multithread
Hi JP, I had similar problem on 2.8.x, your code doesn't compile for me but have your tried wrapping the cursor stuff with viewer.stopThreading(); .. viewer.startThreading(); /Per On 26 May 2011 15:40, J.P. Delport jpdelp...@csir.co.za wrote: Hi all, the attached little app crashes if I don't run it with --SingleThreaded. Can anyone on Linux check if the same happens for them? Also let me know your OSG version. ./test cow.osg thanks jp PS. adding a frame() call before the cursor change also seems to work for the default threading case. Not sure why. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] [osgPlugins] Export Blender to OSG
aaron wetzler writes: Hi, I have the following task to do: 1. Import a mesh of a hand (.obj) into blender. Create an armature in Blender 2. Skin the armature with the hand mesh. 3. Export this armature and mesh into OSG. 4. Alter the armature poses in OSG and output a set of jpgs or bmps of the depth maps of the resulting poses. I have done 1 and 2 but dont know how to do 3 and 4. What format can I output from Blender that OSG will be able to understand? What part of OSG should I be using? OSGAnimation? I imagine step 3 is totally standard so thats the most critical part for me because I have no idea how to go about it. I am a relative newbie to the world of meshes and animation and would really appreciate some help because I have been stuck on this for two weeks and I cant do it by myself. Thanks! Looking forward to hearing from the forum :) I think you are almost finishing step 3 since I saw you in the blender exporter thread. For posing the hand, you have several choices: pose it in blender in a predefined animation and then reproduce it with OSG or just move the model by modifying the bones transformation matrix in OSG. You were right, osgAnimation is the library to use. For the depth map capturing, I would render to texture using a Camera which would store the depth component of the rendered image. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Thank you very much for the updated script, it works great. If I have time I'll test it on anothers models and let you know. Cheers, On Mon, May 30, 2011 at 9:37 AM, Alberto Luaces alua...@udc.es wrote: Damyon Wiese writes: Hi Amigoface, Sorry - I think this commit to blender changed one of the import paths. http://comments.gmane.org/gmane.comp.video.blender.scm/22522 Ie - my blender auto updated and I had to change one of the import paths to make the script work - but obviously that broke the script for blender versions before the above commit. Yes — indeed I had to compile Blender from the latest SVN version in order to be able to use it. If you try to use the precompiled Blender version offered in the official page, you will have the same error. Damyon, do you have some sort of public repository? That way we could try the script at our ends, and integrate the changes easily instead of having to do all the work by yourself. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Hi All, Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QuadBuffer crash?Do you have?
Hi, Robert This morning, i've checked your suggestion: using osgviewer cow.osg --stereo QUAD_BUFFER It was same...the problem is still there...sometimes, I got frozen screen... Then we can say that should be a problem of Drivers or Hardware ? Thanks alot~ Cheers, Nan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39927#39927 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Hi Robert, Am 30.05.11 10:28, schrieb Robert Osfield: Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. compiles fine for OS X 32bit / 64bit and IOS. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] 2.9.14 and trunk problems on lubuntu 11.04+lxde+nvidia
Hi, On 27/05/11 18:10, Robert Osfield wrote: Hi All, On Thu, May 26, 2011 at 2:31 PM, J.P. Delportjpdelp...@csir.co.za wrote: ulimit -c unlimited for ((i=0; i100; i++)) do osgviewer --window 0 100 800 600 cow.osg osgviewer --window 500 0 800 600 cow.osg sleep 0.5; killall osgviewer; done As discussed in the OSG trunk crashing, perhaps an nvidia driver problem? thread, I've reverted the change that caused the X11 threading issues. Before reverting these changes I was reliably getting errors when running the above script, but now I'm getting a clean run of 100 sets of two windows appearing and disappearing without any errors. Yay for a neat little unit test ;-) Could you all do an svn update and let me know how you get on. r12466 now works fine on both machines I had the errors previously. Thanks for your effort. jp Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] Computations outside computation node
Hi, I would like to use osgCompute outside the computation node, similar to your osgEndiannessDemo example. The only difference is that I want to use osgCuda::Texture objects. From the example source: Code: // You can use modules and buffers in the update cycle or everywhere // you want. But please make sure that the context is still active at // computation time if you use osgCuda::Geometry or osgCuda::Texture objects!!! Can you please give an example on how to make sure the context is still active before I perform the computation ? Do I need to perform some operations on the context after the computations ? Thanks, Jaco -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39925#39925 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.5 Call for testing
Hi Paul, It compiles and runs ok in my Ubuntu 10.04 x86_64 box. Cheers. 2011/5/27 Michael Weiblen mike.weib...@gmail.com Excellent work, will get banging on it. -- mew On Fri, May 27, 2011 at 8:47 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- I've just tagged 2.8.5 RC1 and would like to request your help in testing. You can check out the release candidate from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc1 All features are in place at this time, with the one exception of the 3DS plugin backport. Assuming that work is complete soon, and there is sufficient testing, we should be able to release in the very near future. Features in 2.8.5: * Uniform performance enhancement. r11952, Michael Plating's performance enhancement for large numbers of uniforms, which effectively eliminates the std::mapstd::string lookup. r11998, Wojciech Lewandowski's backwards compatibility fix for 11952. r12074, Chris Hanson's backwards compatibility fix for 11952. * Support for Texture2DMultisample r11218, changes to Extensions. r11229, fix warnings. r11365, 2D multisample support. * Added new OutputRelativeTextures dot OSG plugin export option (not on trunk). * Enhancements for OcclusionQueryNode. r11760 (plus r11472 for OQN.cpp only). Support for RTT Camera (not on trunk). * osgconv --use-world-frame option. * NOTIFY_WARN (and friends) macros to ease backporting. OSG_NOTIFY_DISABLED CMake variable. * FLT plugin update. A complete backport of the trunk FLT plugin (as if May 4 2010) to the 2.8 branch. Includes export fixes for multitexture. Includes osgSim MultiSwitch changes in r11971. * PNM plugin enhancements: r12220, adds support for reading and writing images using streams. Bug fixes for reading 8-bit and 16-bit images, including loading the images upside-down. * Fix issue with linking apps to libdl on Linux systems. * osgText fix (r11768) to improve text appearance. * Updated osgWrappers for all API changes. * Bump version# 2.8.5, SO# 74. Thanks for your help! -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Black Hawk, Colorado USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi Torres Fabra gvSIG 3D blog http://gvsig3d.blogspot.com Instituto de Automática e Informática Industrial http://www.ai2.upv.es ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 cursor setting - Single- vs Multithread
Hi Per, On 30/05/11 09:37, Per Nordqvist wrote: Hi JP, I had similar problem on 2.8.x, your code doesn't compile for me but have your tried wrapping the cursor stuff with viewer.stopThreading(); .. viewer.startThreading(); hmm, your suggestion works. I didn't realize that viewer.realize() starts threading... This could explain a lot of things, because some calls are happening prior to the first viewer.frame() call. Thanks for the help. rgds jp PS. working version attached. /Per On 26 May 2011 15:40, J.P. Delportjpdelp...@csir.co.za wrote: Hi all, the attached little app crashes if I don't run it with --SingleThreaded. Can anyone on Linux check if the same happens for them? Also let me know your OSG version. ./test cow.osg thanks jp PS. adding a frame() call before the cursor change also seems to work for the default threading case. Not sure why. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. osgviewer_cursor.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 cursor setting - Single- vs Multithread
Hi J.P, et. al, I have tracked down and fixed the setCursor() crash issue ;-) The problem occurred because of subtle timing issue with the GraphicsContext::_threadOfLastMakeCurrent variable in the GraphicsContext::makeCurrent() and how this variable is used in the GraphicsWindowX11::getDisplayToUse(). What was happening is that viewer.realize() would create the windows and start the graphics thread on each window created and this thread would then do a makeCurrent() which onces complete would set the _threadOfLastMakeCurrent and then any getDisplayToUse() would then select the appropriate GraphicsWindow11::_eventDisplay or GraphicsWindow11::_display connection to the X server. The problem was that while the GrapohicsWindowX11::makeCurrentImplementation() was happening in the graphics thread, the main thread was doing a GraphicsWindow::setCursor() which in turn was calling getDisplayToUse() which returned _display rather than _eventDisplay as the makeCurrent() hadn't yet reset the _threadOfLastMakeCurrent, but using _display while another thread was doing a glxMakeCurrent isn't safe - and the crash occurred. To test it out I added a micro sleep into the main thread before the setCursor and this solved the issue if the sleep was long enough, the sleep didn't have to be too long - just long enough for the first makeCurrent() to do it's stuff, but it was easy to see how this would really timing sensitive. Once I confirmed it was a timing issue on the setting of _threadOfLastMakeCurrent it just became a simply tweak of GraphicsContext::makeCurrent() so it set this member varaible prior to calling makeCurrentImplementation(). With this change I could remove the micro sleep from the main thread and everything runs smoothly with the setCursor. I run 100 iterations of your test app and every time it came up correctly without any warnings :-) An svn update will get you this fix. Please let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QuadBuffer crash?Do you have?
Hi Nan, On Mon, May 30, 2011 at 9:47 AM, Nan WANG nan.c...@gmail.com wrote: This morning, i've checked your suggestion: using osgviewer cow.osg --stereo QUAD_BUFFER It was same...the problem is still there...sometimes, I got frozen screen... As another little test could you try: osgviewer cow.osg --stereo QUAD_BUFFER --SingleThreaded I don't expect this to fix anything but it's worth turning every stone we can to see if we can get a better picture of the problem. Then we can say that should be a problem of Drivers or Hardware ? I think it's most likely a OpenGL driver problem. For the applications that are working it would be worth finding out whether they are Direct3D or OpenGL based. There will be other OSG users using quad buffer stereo under Windows so I'm surprised others haven't chirped up with a report of success or failure, it might be that they haven't spotted this thread, or don't currently have access to hardware to check. In the past users have reported success with quad buffer stereo under Windows so I believe there isn't a deep seated problem - it should work given fully working drivers. Given that a driver problem is the most likely issue I'd suggest looking at availability of new or older drivers for your card, and also check the NVidia forum and support to see if the issue has been seen with other OpenGL applictions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgAudio Sound Position
Hi, Did you make sure your audio source is mono? If the file is in stereo format OpenAL won't use it as a positional sound. Cheers, Sami -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39935#39935 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] X11 cursor setting - Single- vs Multithread
Hi Robert, On 30/05/11 11:36, Robert Osfield wrote: Hi J.P, et. al, I have tracked down and fixed the setCursor() crash issue ;-) The problem occurred because of subtle timing issue with the GraphicsContext::_threadOfLastMakeCurrent variable in the GraphicsContext::makeCurrent() and how this variable is used in the GraphicsWindowX11::getDisplayToUse(). What was happening is that viewer.realize() would create the windows and start the graphics thread on each window created and this thread would then do a makeCurrent() which onces complete would set the _threadOfLastMakeCurrent and then any getDisplayToUse() would then select the appropriate GraphicsWindow11::_eventDisplay or GraphicsWindow11::_display connection to the X server. The problem was that while the GrapohicsWindowX11::makeCurrentImplementation() was happening in the graphics thread, the main thread was doing a GraphicsWindow::setCursor() which in turn was calling getDisplayToUse() which returned _display rather than _eventDisplay as the makeCurrent() hadn't yet reset the _threadOfLastMakeCurrent, but using _display while another thread was doing a glxMakeCurrent isn't safe - and the crash occurred. To test it out I added a micro sleep into the main thread before the setCursor and this solved the issue if the sleep was long enough, the sleep didn't have to be too long - just long enough for the first makeCurrent() to do it's stuff, but it was easy to see how this would really timing sensitive. Once I confirmed it was a timing issue on the setting of _threadOfLastMakeCurrent it just became a simply tweak of GraphicsContext::makeCurrent() so it set this member varaible prior to calling makeCurrentImplementation(). With this change I could remove the micro sleep from the main thread and everything runs smoothly with the setCursor. I run 100 iterations of your test app and every time it came up correctly without any warnings :-) An svn update will get you this fix. Please let me know how you get on. thanks, just updated and the multithreaded version now works without the stop/start threading. Thanks for the detailed story, I love reading bug resolution quests :) Someone should make a book out of a collection of them one day. rgds jp Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Hi, No problem building for me here on Windows 7, VS2010 SP1, 32-bit build, default CMake options + BUILD_OSG_EXAMPLES. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39936#39936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QuadBuffer crash?Do you have?
Yes Robert~ You are completely right~i checked with --SingleThreaded option, but it changes nothing...sometimes, it happened again. With the application that are working are based on OpenGL rendering. Because we are using QuadBuffer projectors and shutter glasses... It was a strange problem...I will post my issue to nVidia forum to have a try. Thanks a lot Robert. ... Thank you! Cheers, Nan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39938#39938 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Linux RHEL4 I get this error message /home/local/VariousProjects/osg-2.915/src/osgPlugins/tiff/ReaderWriterTIFF.cpp:188: error: `streampos' is not a member of `std::ostream' std::ostream::streampos checkEmpty = fout-tellp(); I fixed it just by removing the ostream std::streampos checkEmpty = fout-tellp(); Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Mon, May 30, 2011 11:28:43 AM Subject: [osg-users] Please test svn/trunk before todays 2.9.15 dev release. Hi All, Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. Thanks, 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] [osgPlugins] Export Blender to OSG
Hi Alberto You are right. I found the osgExport and osgAnimation. Im currently really stuck on the osgExport though and would really like to be able to find a version of blender and a version of osgExport that work together. Do you have any experience with this? Do you know which versions of both I could download for windows 7 that will work? Thanks Aaron -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39940#39940 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Export Blender to OSG
aaron wetzler writes: Hi Alberto You are right. I found the osgExport and osgAnimation. Im currently really stuck on the osgExport though and would really like to be able to find a version of blender and a version of osgExport that work together. Do you have any experience with this? Do you know which versions of both I could download for windows 7 that will work? I'm afraid that at the moment you need to compile from the latest source, or find any site where people uploads their personal builds like Graphicall (http://www.graphicall.org/). The last version that Damyon posted to the list was supposed to run on older versions too, but I got the same errors, so for now a really new version of Blender may be needed. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Export Blender to OSG
The current workflow I used to have animation in osg, is using blender 2.49b and the osgexport https://bitbucket.org/cedricpinson/osgexport If you get the repository you will be able to check example. Cedric On Fri, 2011-05-27 at 18:29 +0200, aaron wetzler wrote: Hi, I have the following task to do: 1. Import a mesh of a hand (.obj) into blender. Create an armature in Blender 2. Skin the armature with the hand mesh. 3. Export this armature and mesh into OSG. 4. Alter the armature poses in OSG and output a set of jpgs or bmps of the depth maps of the resulting poses. I have done 1 and 2 but dont know how to do 3 and 4. What format can I output from Blender that OSG will be able to understand? What part of OSG should I be using? OSGAnimation? I imagine step 3 is totally standard so thats the most critical part for me because I have no idea how to go about it. I am a relative newbie to the world of meshes and animation and would really appreciate some help because I have been stuck on this for two weeks and I cant do it by myself. Thanks! Looking forward to hearing from the forum :) Aaron -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39877#39877 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Cedric Pinson Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 - cedric.pin...@plopbyte.com http://plopbyte.com - http://osgjs.org - http://showwebgl.com signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Thansk Dimi, fix applied and checked in to svn/trunk. On Mon, May 30, 2011 at 1:19 PM, dimi christop dimi_chris...@yahoo.com wrote: Linux RHEL4 I get this error message /home/local/VariousProjects/osg-2.915/src/osgPlugins/tiff/ReaderWriterTIFF.cpp:188: error: `streampos' is not a member of `std::ostream' std::ostream::streampos checkEmpty = fout-tellp(); I fixed it just by removing the ostream std::streampos checkEmpty = fout-tellp(); Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Mon, May 30, 2011 11:28:43 AM Subject: [osg-users] Please test svn/trunk before todays 2.9.15 dev release. Hi All, Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. Thanks, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Hi Robert, Build fine on Windows XP (VS2008 SP1), Ubuntu 11.04, and Android NDK r5 (without any dependencies, as I'm still new to NDK). By the way, I noticed that there are no Android examples for showing even a simplest implementation of OSG on Android. Is it possible that we could provide one in the 3.0 release? Cheers, Wang Rui 2011/5/30 Robert Osfield robert.osfi...@gmail.com: Hi All, Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. Thanks, 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] Please test svn/trunk before todays 2.9.15 dev release.
Hi Rui, On Mon, May 30, 2011 at 2:45 PM, Wang Rui wangra...@gmail.com wrote: Build fine on Windows XP (VS2008 SP1), Ubuntu 11.04, and Android NDK r5 (without any dependencies, as I'm still new to NDK). Thanks for the extensive testing. By the way, I noticed that there are no Android examples for showing even a simplest implementation of OSG on Android. Is it possible that we could provide one in the 3.0 release? I'd like an Android example for 3.0. I await an updated example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.5 Call for testing
I've been testing it with my application without problems, on Fedora 14 Linux x64. On Fri, May 27, 2011 at 10:47 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- I've just tagged 2.8.5 RC1 and would like to request your help in testing. You can check out the release candidate from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc1 All features are in place at this time, with the one exception of the 3DS plugin backport. Assuming that work is complete soon, and there is sufficient testing, we should be able to release in the very near future. Features in 2.8.5: * Uniform performance enhancement. r11952, Michael Plating's performance enhancement for large numbers of uniforms, which effectively eliminates the std::mapstd::string lookup. r11998, Wojciech Lewandowski's backwards compatibility fix for 11952. r12074, Chris Hanson's backwards compatibility fix for 11952. * Support for Texture2DMultisample r11218, changes to Extensions. r11229, fix warnings. r11365, 2D multisample support. * Added new OutputRelativeTextures dot OSG plugin export option (not on trunk). * Enhancements for OcclusionQueryNode. r11760 (plus r11472 for OQN.cpp only). Support for RTT Camera (not on trunk). * osgconv --use-world-frame option. * NOTIFY_WARN (and friends) macros to ease backporting. OSG_NOTIFY_DISABLED CMake variable. * FLT plugin update. A complete backport of the trunk FLT plugin (as if May 4 2010) to the 2.8 branch. Includes export fixes for multitexture. Includes osgSim MultiSwitch changes in r11971. * PNM plugin enhancements: r12220, adds support for reading and writing images using streams. Bug fixes for reading 8-bit and 16-bit images, including loading the images upside-down. * Fix issue with linking apps to libdl on Linux systems. * osgText fix (r11768) to improve text appearance. * Updated osgWrappers for all API changes. * Bump version# 2.8.5, SO# 74. Thanks for your help! -- -Paul Martz Skew Matrix Software http://www.skew-matrix.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
[osg-users] about the front clipping plane
Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an empty bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I'm sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn't OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] about the front clipping plane
Hi Gianluca, The OSG by default will use COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES settings for osg::Camera which tells the cull traversal to compute the depth range of scene for each frame based on the extents of the bounding boxes of the drawables in the scene. Often the computed near position will be very close to the eye point or even behind it both of which are not usage values for settings up the projection matrix, so the cull travesal automatically clamps the near distances if it's too low. The minimum near distance the OSG uses as a cut off is computed from NearFarRatio * compute_zfar, you can reset this ratio to a lower value via osg::Camera::setNearFarRatio(double). Robert. On Mon, May 30, 2011 at 3:40 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an “empty” bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I’m sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn’t OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, 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
[osg-users] R: about the front clipping plane
Thank you Robert, you are always clear and precise! That's the info I need. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: lunedì 30 maggio 2011 16:50 A: OpenSceneGraph Users Oggetto: Re: [osg-users] about the front clipping plane Hi Gianluca, The OSG by default will use COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES settings for osg::Camera which tells the cull traversal to compute the depth range of scene for each frame based on the extents of the bounding boxes of the drawables in the scene. Often the computed near position will be very close to the eye point or even behind it both of which are not usage values for settings up the projection matrix, so the cull travesal automatically clamps the near distances if it's too low. The minimum near distance the OSG uses as a cut off is computed from NearFarRatio * compute_zfar, you can reset this ratio to a lower value via osg::Camera::setNearFarRatio(double). Robert. On Mon, May 30, 2011 at 3:40 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an empty bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I'm sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn't OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk before todays 2.9.15 dev release.
Everything OK in Ubuntu 10.04.2 LTS (64-bit). Regards, On Mon, May 30, 2011 at 10:28 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, Could users check out, build and test the svn/trunk version of the OSG and let me know how you get on. I'll be tagging the 2.9.15 release today so would like to make sure it's at least building across platforms before I make the release. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Javier Taibo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.9.15 developer version released
Hi All, OpenSceneGraph-2.9.15, released on 30th May 2011, key deliverables in this dev release are: Fixes to Coverity reported issues. Merged pending submissions that fixed a range of bugs and minor feature additions. source package : OpenSceneGraph-2.9.15.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.15 OpenSceneGraph Thanks to all that have contribed code, testing and bug fixes ;-) Robert. -- ChangeLog since 2.9.14 2011-05-30 13:02 robert * src/osgPlugins/tiff/ReaderWriterTIFF.cpp: From Dimi Christop, build fix for RHEL 4. 2011-05-30 09:26 robert * src/osgViewer/GraphicsWindowX11.cpp: Added closing of the _eventDisplay on failure of initializing the context properly. 2011-05-30 09:25 robert * src/osg/GraphicsContext.cpp: Fixed X11 related crash that occured when GraphicsWindow::setCursor was called right after viewer.realize(); The fix was to simply move the setting of the thread that has done the makeCurrent to right before the makeCurrent() rather than right after. 2011-05-30 08:26 robert * CMakeModules/Find3rdPartyDependencies.cmake: From Wang Rui, The submission fixes the spelling bug we discussed in osg-users. It replaces the variable ACTUAL_3DPARTY_DIR to ACTUAL_3RDPARTY_DIR with back compatibility. Please find it in attachment. 2011-05-30 08:24 robert * src/osgText/TextBase.cpp: From Terry Welsh, I was having a small culling problem with osgText... new TextBase.cpp that fixes it. 2011-05-27 16:04 robert * src/osgViewer/GraphicsWindowX11.cpp: Reverted part of revision r12294 that introduced threading related problems under X11 due to checking the _display Display member variable assigned to the graphics thread from the main thread. 2011-05-27 11:22 robert * applications/osgconv/OrientationConverter.cpp, applications/osgconv/OrientationConverter.h, applications/osgconv/osgconv.cpp: From Ryan Pavlik, Existing osgconv behavior is to transform the model bounding sphere center to the world origin before performing transformations specified on the command line, and translating back after rotation and scaling unless an alternate translation is specified. This patch adds a setting to the OrientationConverter class in osgconv to disable this extra transformation, which has the effect of applying specified transforms with respect to the input world coordinate system, rather than to the center of the bounding sphere. It also adds a command line argument --use-world-frame to enable this behavior. When this command line argument is not passed, behavior is unchanged from before the patch. The usage text has been updated to reflect this additional option, and the comments in OrientationConverter are also updated. Note from Robert Osfield, tweaked the OrientationConverter.cpp a little to improve readability. 2011-05-27 11:18 robert * applications/osgconv/OrientationConverter.h: Fixed indentation 2011-05-27 11:07 robert * examples/osg2cpp/osg2cpp.cpp: Fixed the searchAndReplace function so that it correctly skips over the newly inserted replacement strings. 2011-05-27 09:08 robert * CMakeLists.txt, CMakeModules/OsgCPack.cmake: From Jean-Sebastien Guay, I like the recent addition that adds folders in the solution tree to better organize the numerous examples, libraries, plugins etc. I added two folders that were missing IMHO: packaging and documentation. 2011-05-27 09:05 robert * src/osgPlugins/pnm/ReaderWriterPNM.cpp: From Eric Sokolowsky, Attached is an updated PNM plugin for inclusion in both the trunk and for release version 2.8.5. The attached file fixes numerous bugs in reading 8-bit and 16-bit images, including loading the images upside-down. This file also incorporates trunk patch r12220 which updated the plugin for reading and writing images through streams instead of C-style FILE I/O. Note from Robert Osfield, previous revision was in error due to an incomplete merge, this revision completes the job. 2011-05-27 09:00 robert * src/osgUtil/TriStripVisitor.cpp: From Laurens Voerman, While working on the osg exporter for 3dsmax I found a bug in the TriStripVisitor. I created a small example (attached), and a modified version of src\osgUtil\TriStripVisitor.cpp where the problem is removed. 2011-05-27 08:55 robert *
Re: [osg-users] Meta-data in core OSG - project started
Hi All,
Last Friday I dived in and did my first pass review of Sukender's work
on a meta data system for the OSG. Now that I've got the 2.9.15 dev
release out the door I've returned for a second look. My current
reaction is that it feels rather too complicated and with it a bit
awkward to understand how it works and how to use it. I can work how
it works and I think I understand how to use it, but it does take
several reads so this makes me concerned about the burden of support
that might come with it - i.e. lots of traffic on osg-users.
So I'm now thinking about whether we can come up with a lighter weight
meta data system, and with it try and make it possible to wire up with
osgDB serialization. Serialization in osgDB is based around providing
wrappers per osg::Object subclass, so to leverage serialization we'll
either need to modify osgDB's serialization so it can handle something
even lower level than osg::Object, or for use to have the meta data
system use osg::Object.
Since osg::Object is pretty low level and lightweight - coming in at
only 48 bytes on my 64bit linux system, I'm inclined to say it's small
enough to be be used for meta data objects, and it also comes with an
inbuilt std::string for it's name, so this name could potentially be
used for the indexing of the data if we want to get/set the elements
by name.
In terms of providing convience for setting/getting int, string, float
etc. types I wonder if an series of IntObject, FloatObject,
StringObject etc types my provided that use multiple inheritance (is
a), or agregation have a to store the value. Serializers for these
could be added to osgDB's wrappers so end users wouldn't need to do
anything for basic types like these. We could use a template to
provide this mapping and then a series of typedefs or convinience
methods could provide settings and getters, either via templates or
just parameters i.e.
ValueContainer : public osg::Object
{
void insert(Object*)
Object* getObject(const std::string);
void setValue(const std::string name, int value);
bool getValue(const std::string name, int value);
void setValue(const std::string name, float value);
bool getValue(const std::string name, std::string value);
};
For the existing UserData and DescriptionList I'm currently inclined
to hardwire this into ValueContainer as getUserData() and
getDescitionList(). This is a bit clunky but it'll be less
complicated trying to adapt both of these into osg::Object. So we
might have something like:
ValueContainer : public osg::Object
{
void setUserData(osg::Referenced*)
Referenced* getUserData();
typedef std::vectorstd::string DescriptionList;
void setDecriptionList(DescrtionList dl);
DescriptionList getDescritionList();
void setValue(const std::string name, int value);
bool getValue(const std::string name, int value);
void setValue(const std::string name, float value);
bool getValue(const std::string name, std::string value);
};
The container used within ValueContainer could be an
std::vectorosg::ref_ptrosg::Object to allow indexing via a
conventional array style access, with linear search used to locate the
values in the vector when you want to access via a name. We wouldn't
normally expect to find huge data structues stored in these containers
so I wouldn't expect this to be a performance issue. If one did
require quick access to very large string data then one could just
create a custom class subclassed from osg::Object.
The above scheme would also be able to nest ValueContainers as entries
in the value vector. osg::Object itself will have a a
ref_ptrValueContainer and associated get/set methods for it so I
guess this might be a little confusing if one thought about it too
long. Given this is a free feature gained by using osg::Object as the
base of the storage and most users would never require this nesting I
don't think we'd need worry about it.
For naming I've using ValueContainer here as it's what been used in
Sukender's implememtation. I feel it's a bit too generic though,
perhaps even something like UserDataContainer might convey a bit more
what it's role is.
I'm open to suggestions, please let me know what you think.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph hello
OpenSceneGraph hello i wish someone had let me know about this sooner http://g.msn.com.br/BR9/1369.0?http://cnbc7.com/news ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
