Re: [osg-users] BoundingBox
Hi Nilton,
Neither osg::BoundingBox or osg::BoundingSphere will be sufficient for
the purpose of collision detection against polygon wall geometries,
these bounding volumes are just suitable for very coarse grained
intersections tests like required for culling.
The osgUtil::IntersectionVisitor/*Intersector classes will be more
suitable, but even these do not provide general purpose
collision detection. There are dedicated collision detection
libraries, as well as collision detection provided as part of some of
physics engines so perhaps these would be more suitable.
Robert.
On Tue, Jun 21, 2011 at 2:42 AM, Nilton Paulo npraimu...@yahoo.com.br wrote:
Hi, everybody!
I am looking to use BoudingBox into my application.
I want to avoid collison or transverse the walls of the buildings, when
navigating with the camera.
Here are my test using BoundingSphere:
const osg::BoundingSphere bs1 = viewer.getCamera()-getBound();
const osg::BoundingSphere bs2 = nodePath[c]-getBound();
if(bs1.intersects(bs2))
{
// Do something
}
This test does not work properly and IF always return TRUE.
Does anybody know how to verify the collision into the walls? (I want that
the camera does not transpass the walls).
Thank you!
Cheers,
Nilton
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40700#40700
___
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] TRAVERSE features.
HI Nilton,
I think you might be misunderstanding the use of the word traverse in
the context of scene graph traversal. When the NodeVisitor traverse
the scene graph they are consider the internal data structure links
between parent nodes and their children. In the case of the cull
traversal a subgraph will be not traversed if the bounding volume of
that subgraph is outside the view frustum or an LOD child is out of
range, but in all cases there isn't collision detection like you are
thinking of.
The closest example of collision detection that controls the control
can be found in the osgGA::DriveManipulator which is a
CameraManipulator that controls the movement of the camera in response
to keyboard/mouse actions. The DriveManipualtor uses
a ray based intersection method to determine it position above terrain.
Robert.
On Tue, Jun 21, 2011 at 2:58 AM, Nilton Paulo npraimu...@yahoo.com.br wrote:
Hi everybody,
I am not sure that the class TRAVERSE could control the transpass of the
building walls.
I would like not to pass by the walls while navigating with the camera.
My source code is:
nodePath[c]-setUpdateCallback( new SetTransverse() );
...
class SetTransverse : public osg::NodeCallback
{
public:
SetTransverse() { }
virtual void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::MatrixTransform* mt = dynamic_castosg::MatrixTransform*( node );
nv-setTraversalMode(osg::NodeVisitor::TRAVERSE_NONE);
}
};
Does anybody could help me how to use traverse properlly?
Thank you!
Cheers,
Nilton
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40701#40701
___
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] Navigation - Walk at 6 feets.
On Tuesday 21 June 2011 04:36:05 Nilton Paulo wrote: Hi, everybody: I am writing a software to walk into a 3D image from a 3DS file. [...] The issue is that I need to walk thru the scene always at 6 feets, for exemple. Does anybody know how to do so? Hi Nilton, Have a look at how osgGA::DriveManipulator works. It keeps the viewpoint at a fixed distance above the local terrain. Hope this helps, Magnus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp specular
Hi all. osgExp expects specular in range 0...1000, that is range you can set in 3ds max for specular intensity. It's looks different in 3ds max then in osg though. Sergey. 17.06.2011, 18:53, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com: Hi Farshid, I'm not sure who the original author of that code is, so I don't know the reason for that division. You're probably correct about removing it. I'll take a closer look at it and get back to you. OK, at least for me removing the 9.99 divisor makes the result in OSG look almost exactly like what's in 3DSMax. Let me know if you want more info. Thanks, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Passing multiple textures in glsl
Hi, Linda ss-setTextureAttribute(1, tileImgLay); This line is actually does not do anything because default value for 3rd parameter is osg::StateAttribute::OFF You should use either ss-setTextureAttributeAndModes(1, tileImgLay); or ss-setTextureAttribute(1, tileImgLay, osg::StateAttribute::ON); ss-setTextureMode(1, GL_TEXTURE2D_ARRAY, osg::StateAttribute::ON); Also define version (in first line of your fragment shader) as someone suggested before, because on nvidia hardware it can compile without version sometimes but does not work as expected and shader compiler does not complain about anything. Make sure that images that you loading have same size (128x128) and pixel format. Regarding textures count limitations - this is implementation dependent as stated in gl specification. You can query maximum textures count with glGet(GL_MAX_TEXTURE_UNITS) - maximum textures count for fixed pipeline multitexturing (about 4 on modern hardware) glGet(GL_MAX_TEXTURE_IMAGE_UNITS) - maximum textures count accessible in fragment shader program (texture2DArray counts as one texture), 16-32 on modern hardware If you cant get up to GL_MAX_TEXTURE_IMAGE_UNITS textures working check for bad_allock exceptions, and check opengl errors. Cheers, Sergey. 11.06.2011, 12:47, Linda Lee zenith...@hotmail.com: Hi, I tried add these lines into my code: osg::Texture2DArray* tileImgLay; tileImgLay = new osg::Texture2DArray; tileImgLay-setTextureSize(128, 128, 2); tileImgLay-setUseHardwareMipMapGeneration(false); tileImgLay-setImage(0, osgDB::readImageFile(test1.bmp)); tileImgLay-setImage(1, osgDB::readImageFile(est1.bmp)); ss-setTextureAttribute(1, tileImgLay); tileImgLay-setFilter( osg::Texture2DArray::MIN_FILTER, osg::Texture2DArray::NEAREST); tileImgLay-setFilter( osg::Texture2DArray::MAG_FILTER, osg::Texture2DArray::NEAREST); ss-addUniform( new osg::Uniform(test, 1) ); and in the fragment shader: uniform sampler2DArray test; and access it using: gl_FragColor = texture2DArray(test, vec3(0, 0, 0)); However, it fail to work. Any ideal why? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40370#40370 ___ 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] Extending CURL plugin to implement write functions.
Hi, I have just been pondering the idea of extending the curl plugin so that it can perform http upload for write operations. In principle at least, it seems like this might be relatively easy to implement using existing functionality within the curl library. So, my questions are: 1. Has anyone already looked into this? 2. Does anyone except me think it's a good idea? 3. Any alternative suggestions for programatically uploading OSG objects? Thanks. Chris D. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40707#40707 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extending CURL plugin to implement write functions.
Hi, maybe writing to disk or to ramfile and then uploading it via CPP Code? Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40708#40708 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes FBX plugin warnings
Hi Robert, thanks for the warning list. I believe I've now fixed them but please let me know if any remain. On 16 June 2011 19:48, Robert Osfield robert.osfi...@gmail.com wrote: Hi FBX users/developers, I have been doing a warnings purge of the OSG in prep for the OSG-3.0 branch to be made tomorrow, and one area that is generating the bulk of the remaining warnings is the FBX plugin. These warnings might not be appearing on all platforms so I've included them below for others to review. I've fixed the warnings that I can do without knowing anything about the spefics of the FBX SDK, to fix the remaining warnings I really need those with some expertise in the FBX SDK to work out how best to resolve these warnings - some of the warnings look like they may well be highlighting potential bugs so I believe it'd be valuable to clean up before 3.0. Warnigns are: [ 95%] Building CXX object src/osgPlugins/fbx/CMakeFiles/osgdb_fbx.dir/fbxRAnimation.o [ 95%] Building CXX object src/osgPlugins/fbx/CMakeFiles/osgdb_fbx.dir/fbxRCamera.o [ 95%] Building CXX object src/osgPlugins/fbx/CMakeFiles/osgdb_fbx.dir/fbxRLight.o /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRLight.cpp: In member function ‘osgDB::ReaderWriter::ReadResult OsgFbxReader::readFbxLight(fbxsdk_2012_1::KFbxNode*, int)’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRLight.cpp:57:16: warning: enumeration value ‘eNONE’ not handled in switch [100%] Building CXX object src/osgPlugins/fbx/CMakeFiles/osgdb_fbx.dir/fbxRMesh.o /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘int getVertexIndex(const fbxsdk_2012_1::KFbxLayerElementTemplateT*, const fbxsdk_2012_1::KFbxMesh*, int, int, int) [with T = fbxsdk_2012_1::KFbxVector4]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:556:81: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eNONE’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eBY_EDGE’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eALL_SAME’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘bool layerElementValid(const fbxsdk_2012_1::KFbxLayerElementTemplateT*) [with T = fbxsdk_2012_1::KFbxVector4]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:701:39: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:60:5: warning: enumeration value ‘eINDEX’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘bool layerElementValid(const fbxsdk_2012_1::KFbxLayerElementTemplateT*) [with T = fbxsdk_2012_1::KFbxColor]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:702:38: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:60:5: warning: enumeration value ‘eINDEX’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘bool layerElementValid(const fbxsdk_2012_1::KFbxLayerElementTemplateT*) [with T = fbxsdk_2012_1::KFbxVector2]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:704:43: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:60:5: warning: enumeration value ‘eINDEX’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘int getPolygonIndex(const fbxsdk_2012_1::KFbxLayerElementTemplateT*, int) [with T = fbxsdk_2012_1::KFbxSurfaceMaterial*]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:739:61: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:104:9: warning: enumeration value ‘eINDEX’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘int getVertexIndex(const fbxsdk_2012_1::KFbxLayerElementTemplateT*, const fbxsdk_2012_1::KFbxMesh*, int, int, int) [with T = fbxsdk_2012_1::KFbxVector2]’: /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:122:68: instantiated from ‘FbxT getElement(const fbxsdk_2012_1::KFbxLayerElementTemplateT*, const fbxsdk_2012_1::KFbxMesh*, int, int, int) [with FbxT = fbxsdk_2012_1::KFbxVector2]’ /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:572:113: instantiated from here /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eNONE’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eBY_EDGE’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp:77:5: warning: enumeration value ‘eALL_SAME’ not handled in switch /home/robert/OpenSceneGraph/src/osgPlugins/fbx/fbxRMesh.cpp: In function ‘int getVertexIndex(const fbxsdk_2012_1::KFbxLayerElementTemplateT*, const
Re: [osg-users] Extending CURL plugin to implement write functions.
Hi Torben, Well, I'd like to avoid writing files on the local system (as I'm running inside a multi platform web browser plugin), but I suppose it would be possible to get the object format's plugin to write the object to a memory based std::ostream, then use curl library to upload the content. But once I've done that, it feels like the result would fit oh so neatly into the curl reader writer plugin for all the happy osg'ers to use. :-) Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40709#40709 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamically changing render targets
Hi, thanks for your reply! The attach-call with the new Texture has to be placed inside this callback as well, right? Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40710#40710 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extending CURL plugin to implement write functions.
Hi chris, If you have a use case: Feel free to implement it, I'm sure others could use it too. Just take care to make interface definition changes as small als possible.. ;) Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40711#40711 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi All, I have just tagged the second 3.0.0 release candidate, you can get the source from: source package : OpenSceneGraph-3.0.0-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc2 OpenSceneGraph Feedback from the community on the state of the 3.0 branch and rc1 has been pretty positive so it does look like we are in a pretty good state for the final 3.0.0 stable release. While feedback has been positive it does concern me is that volume of feedback from the community is still rather low, suggesting that the release candidate 1 and the OSG-3.0 branch haven't recieved a lot of widespread testing yet, so perhaps we might be lulling ourselves into a false sense of security. What we really need now is more widespread testing so we can catch any problems that might be present on more niche usage cases or the less comonly used build platforms.Almost always right away a stable release we get feedback from the community that there is a build issue or a feature regression that could have easily been resolved prior to the release, but the problems slipped through because those users who come across the issues didn't actually test the software prior to release. I would encourage everyone in the community not to assume just because others are doing testing and providing positive feedback that things will also work fine for you, assume that there will be problems and to make sure that problems these problems get resolved come come forward and test the software and tells us about the problems. Right now is great opportunity to get those bugs resolved, I and others are primed to investigate and resolved them. After the stable release you'll have missed the boat - we'll be on holiday or focussing on other work. So please test, it's your own as much as everyone elses good. Thanks in advance, Robert. -- Changes checked in since 3.0.0-rc1 are: 2011-06-21 10:07 robert * src/osg/glu/libtess/tess.h: Merged changeset 12581 from svn/trunk to address VisualStudio warning 2011-06-21 09:58 robert * src/osgPlugins/fbx/WriterCompareTriangle.cpp, src/osgPlugins/fbx/WriterCompareTriangle.h, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.cpp, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.h, src/osgPlugins/fbx/fbxRLight.cpp, src/osgPlugins/fbx/fbxRMesh.cpp, src/osgPlugins/fbx/fbxRNode.cpp: Merged from svn/trunk warnings fixes provided by Changeset 12582 from Michael Platings, along with addition of returns at ends of files and changes to tabs to four spaces. 2011-06-20 19:41 robert * CMakeLists.txt: Updated release candidate number 2011-06-20 19:37 robert * src/osgPlugins/bmp/ReaderWriterBMP.cpp, src/osgPlugins/png/ReaderWriterPNG.cpp, src/osgPlugins/tga/ReaderWriterTGA.cpp: Merged from svn/trunk, r12574. From Farshid Lashkari, BGR write support for BMP, PNG and TGA 2011-06-20 19:33 robert * examples/osgphotoalbum/PhotoArchive.cpp, src/osg/ImageUtils.cpp, src/osg/OcclusionQueryNode.cpp, src/osgDB/ExternalFileWriter.cpp, src/osgDB/InputStream.cpp, src/osgDB/OutputStream.cpp, src/osgPlugins/Inventor/ConvertToInventor.cpp, src/osgPlugins/Inventor/ReaderWriterIV.cpp, src/osgPlugins/OpenFlight/expGeometryRecords.cpp, src/osgPlugins/cfg/CameraConfig.cpp, src/osgPlugins/freetype/FreeTypeLibrary.cpp, src/osgPlugins/geo/ReaderWriterGEO.cpp, src/osgPlugins/geo/osgGeoNodes.h, src/osgPlugins/md2/ReaderWriterMD2.cpp, src/osgPlugins/pic/ReaderWriterPIC.cpp, src/osgPlugins/ply/plyfile.cpp, src/osgPlugins/pvr/ReaderWriterPVR.cpp, src/osgPlugins/shp/ESRIShapeParser.cpp, src/osgPlugins/shp/XBaseParser.cpp, src/osgPlugins/zip/unzip.cpp, src/osgShadow/MinimalCullBoundsShadowMap.cpp, src/osgViewer/ScreenCaptureHandler.cpp, src/osgVolume/Locator.cpp, src/osgVolume/RayTracedTechnique.cpp, src/osgWrappers/serializers/osg/ShaderBinary.cpp: Merged changes to svn/trunk that address cppcheck reported issues: [examples/osgphotoalbum/PhotoArchive.cpp:56]: (error) Memory leak: fileIndentifier [examples/osgphotoalbum/PhotoArchive.cpp:257]: (error) Deallocating a deallocated pointer: newData [examples/osgphotoalbum/PhotoArchive.cpp:318]: (error) Deallocating a deallocated pointer: newData [src/osg/ImageUtils.cpp:116]: (portability) Extra qualification 'osg::' unnecessary and considered an error by many compilers. [src/osg/ImageUtils.cpp:307]: (portability) Extra qualification 'osg::' unnecessary and considered an error by many compilers. [src/osg/ImageUtils.cpp:312]: (portability) Extra
[osg-users] troubles with osgDB::readImageFile
Tell me please, why doesn't work function readImageFile? In OpenSceneGraph examples it is called like osg::Image * img = osgDB::readImageFile (filename); I get exception - heap allocation error. The size that function tries to allocate is ~ 3458768586 bytes (picture size is 4 KB). Pre-complilated examples work well. Compilator VC++ 2010 Express. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40712#40712 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dynamically changing render targets
Hi, Daniel Either inside this callback or before callback called (in update\event traversal or between frames). Camera must have new texture attached before camera setup in renderstage. Cheers, Sergey. 21.06.2011, 14:07, Daniel Melzer osgfo...@tevs.eu: Hi, thanks for your reply! The attach-call with the new Texture has to be placed inside this callback as well, right? Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40710#40710 ___ 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] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Robert, On Monday 20 June 2011, Robert Osfield wrote: It's over a decade since I used an IRIX system so apart from fond memories of a bigone era I don't think we need to worry about IRIX. I do suspect if one did resurrect an IRIX it wouldn't too difficult to get the OSG working on it. So, may be we should discuss this in an other thread with a more apropriate subject ... So recent compile tests were only run on HP and Sun. I have compile tested these two remaining machines today. But I expect this to be the last time I will care for these machines... Solaris works more or less. Even if the fullscreen stuff does no longer remove the window borders on CDE. I do not know if this worked before. But to say that, I don't care for the osgViewer fullscreen feature. HPUX still compiles. But I expect CDE on HPUX to have the same problems like solaris for the fullscreen stuff. Does CDE not respond to the _MOTIF_WM_HINTS traditionally used for window decoration under X11? This window decoration code I've changed a little to fix a bug in it, but it's basically still the same. The _NET_WM_STATE functionality used for telling the window manager that a window is full screen is a recent development so I wouldn't know if this has an support under CDE, if this functionality isn't there then these calls will just be ignored so, but the OSG's window size and window decoration code should still be able to toggle fullscreen on/off by itself. I do not know the exact atoms that play a role here. So, I cant' comment on that. But anyway, don't spend too much time on that. When you say the fullscreen stuff doesn't work under HPUX and Solaris could you explain what happens when you run osgviewer cow.osg and then press 'f' and couple of times to toggle the full scrren on/off. Initially I get a full screen window *with* decorations. Pressing f gives a small window as expected. Press f again gives the previous huge window including decorations as before. Could you aslso try running osgviewer cow.osg --window 100 100 640 480 and trying the 'f' toggling. The same as above with the exception that the given initial size is the initial size of the small window. Toggling full screen behaves as above. But as I told, I have kept that compiling and running osg in its major functionality. This detail of the viewer is not really used and not worth a huge effort. If the full screen toggling behaviour under Solaris and HPUX hasn't changed between 3.0.0-rc1 and the changes I checked in this morning then I'd be happy to leave this as is, and merge the changes with the OSG-3.0 in knowledge that it does improve things under the main X11 platform use. This morning I've tested Gnome, KDE and a failsafe xterm with no window manager and with a small fix for the later everything works OK. FYI, The failsafe xterm (Provided by Gnome under Ubuntu) doesn't have an window decoration, but I guess this is to be expected so I don't see this issue. From my point of view, this is fine. The only WM I can think of behaving different is may be twm or fvwm which both should be easy to test with. I can test fvwm at home easily since the primary flightgear machine runs fvwm. On a slightly different note, this afternoon I've been addressing some warnings generated by cppcheck and there is a chance that these might introduce some portability issues if the namespace support is a bit incosinstitent on Solaris and HPUX. Could you please update to svn/trunk and let me know if things still compile fine. From today morning, it compiled on HP and solaris. Does FlightGear not use the OSG's full screen? Yes it does. But not on HP :) Currently flightgear does not render well on current osg trunk. Over the time we gained a highly adapted cull stage with even an own cull visitor and a home grown depth partitioning scheme. I am not yet sure, but I expect that there might be some interference with changes that have broken flightgear. Thanks and greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
Hi Robert, I tested yesterday with my worst test machine Ubuntu 10.04 with mesa drivers and toggling fullscreen was working well. I think my X11 version it's not affected by the workaround. I am compiling now on MacOS for i386 and x86_64. By now it gives me some warnings in OpenSceneGraph-3.0/src/osg/glu/libutil/mipmap.cpp: In function ‘GLdouble osg::extractUbyte(int, const void*)’: OpenSceneGraph-3.0/src/osg/glu/libutil/mipmap.cpp:8566: warning: comparison is always true due to limited range of data type And the same in lines 8582 8603 8626. I have not seen the code, I will try to look deeper this evening. Cheers. 2011/6/21 Robert Osfield robert.osfi...@gmail.com Hi All, I have just tagged the second 3.0.0 release candidate, you can get the source from: source package : OpenSceneGraph-3.0.0-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc2 OpenSceneGraph Feedback from the community on the state of the 3.0 branch and rc1 has been pretty positive so it does look like we are in a pretty good state for the final 3.0.0 stable release. While feedback has been positive it does concern me is that volume of feedback from the community is still rather low, suggesting that the release candidate 1 and the OSG-3.0 branch haven't recieved a lot of widespread testing yet, so perhaps we might be lulling ourselves into a false sense of security. What we really need now is more widespread testing so we can catch any problems that might be present on more niche usage cases or the less comonly used build platforms.Almost always right away a stable release we get feedback from the community that there is a build issue or a feature regression that could have easily been resolved prior to the release, but the problems slipped through because those users who come across the issues didn't actually test the software prior to release. I would encourage everyone in the community not to assume just because others are doing testing and providing positive feedback that things will also work fine for you, assume that there will be problems and to make sure that problems these problems get resolved come come forward and test the software and tells us about the problems. Right now is great opportunity to get those bugs resolved, I and others are primed to investigate and resolved them. After the stable release you'll have missed the boat - we'll be on holiday or focussing on other work. So please test, it's your own as much as everyone elses good. Thanks in advance, Robert. -- Changes checked in since 3.0.0-rc1 are: 2011-06-21 10:07 robert * src/osg/glu/libtess/tess.h: Merged changeset 12581 from svn/trunk to address VisualStudio warning 2011-06-21 09:58 robert * src/osgPlugins/fbx/WriterCompareTriangle.cpp, src/osgPlugins/fbx/WriterCompareTriangle.h, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.cpp, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.h, src/osgPlugins/fbx/fbxRLight.cpp, src/osgPlugins/fbx/fbxRMesh.cpp, src/osgPlugins/fbx/fbxRNode.cpp: Merged from svn/trunk warnings fixes provided by Changeset 12582 from Michael Platings, along with addition of returns at ends of files and changes to tabs to four spaces. 2011-06-20 19:41 robert * CMakeLists.txt: Updated release candidate number 2011-06-20 19:37 robert * src/osgPlugins/bmp/ReaderWriterBMP.cpp, src/osgPlugins/png/ReaderWriterPNG.cpp, src/osgPlugins/tga/ReaderWriterTGA.cpp: Merged from svn/trunk, r12574. From Farshid Lashkari, BGR write support for BMP, PNG and TGA 2011-06-20 19:33 robert * examples/osgphotoalbum/PhotoArchive.cpp, src/osg/ImageUtils.cpp, src/osg/OcclusionQueryNode.cpp, src/osgDB/ExternalFileWriter.cpp, src/osgDB/InputStream.cpp, src/osgDB/OutputStream.cpp, src/osgPlugins/Inventor/ConvertToInventor.cpp, src/osgPlugins/Inventor/ReaderWriterIV.cpp, src/osgPlugins/OpenFlight/expGeometryRecords.cpp, src/osgPlugins/cfg/CameraConfig.cpp, src/osgPlugins/freetype/FreeTypeLibrary.cpp, src/osgPlugins/geo/ReaderWriterGEO.cpp, src/osgPlugins/geo/osgGeoNodes.h, src/osgPlugins/md2/ReaderWriterMD2.cpp, src/osgPlugins/pic/ReaderWriterPIC.cpp, src/osgPlugins/ply/plyfile.cpp, src/osgPlugins/pvr/ReaderWriterPVR.cpp, src/osgPlugins/shp/ESRIShapeParser.cpp, src/osgPlugins/shp/XBaseParser.cpp, src/osgPlugins/zip/unzip.cpp, src/osgShadow/MinimalCullBoundsShadowMap.cpp, src/osgViewer/ScreenCaptureHandler.cpp, src/osgVolume/Locator.cpp, src/osgVolume/RayTracedTechnique.cpp, src/osgWrappers/serializers/osg/ShaderBinary.cpp: Merged changes to svn/trunk that address cppcheck reported issues:
[osg-users] Good new for IOS developers
Hi All, This might have been discussed in the past but it's the first confirmation I have personally had. My first IOS app using OpenSceneGraph was approved for the app store today. I was using 2.9.15, so a pretty recent version (not recent enough to be a test of the 3.0 rc1). OpenSceneGraph was also built statically and was using the depreciated osg and imageio plugins. Thought other would be interested. Tom PS If other have submitted apps, please let me know your experience ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg on UNIX Dinosaurs
Hi Robert, I wanted to have a brief feedback on osg for the UNIX dinosaurs. The beginnings of this thoughts were triggered by the 'Testing a workaround for fullscreen toggling issues under modern X11 window managers' thread. On Monday 20 June 2011, Robert Osfield wrote: 2011/6/20 Mathias Fröhlich m.froehl...@science-computing.de: Ok, our last IRIX machine is dead since one or two years. It's over a decade since I used an IRIX system so apart from fond memories of a bigone era I don't think we need to worry about IRIX. I do suspect if one did resurrect an IRIX it wouldn't too difficult to get the OSG working on it. Well, I had thought of even removing the leftovers from irix. Especially sprocs is probably untested since some years. Anyway, IRIX *is* dead. And the next one to die is HP-UX. Solaris and AIX will stay out there for some time - even if they both do not sell graphics machines anymore - at least none I know of. Appart from that I had the impression that we (s+c) are the last ones who made use of osg on the dinosaurs. Our last UNIX version was shipped for solaris at least one year ago. Keeping osg alive on those machines is getting more and more pointless. So, I thought that we will have a 3.0 release that still builds and runs on my HP and Solaris machine. And may be I will care for the 3.0 maintanance series as well. At least as long as I have access to any dinosaur that is still running. But starting with that next development phase, I will stop HP-UX support also. For solaris this is an open question. My expectations are that solaris will not die as a platform for a long time. But its importance for 3D Graphics is very little today. Also the sun studio compiler does not support all of the stl methods. We have so many more compile problems with solaris due to missing member template functions in the stl implementation than we had with HP. So given that, I am very tempted to just drop solaris too. What do your think? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - 石兴 石兴 杨 Engineer at Huawei China Confirm that you know 石兴 杨 https://www.linkedin.com/e/-qywqtf-gp6seg18-17/isd/3286485044/tMhTS6_g/ -- (c) 2011, LinkedIn Corporation___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] troubles with osgDB::readImageFile
HI Sergey, There isn't anyway anyone in the community can answer your question as there just isn't a fraction of the required information for us to guess. Details that would be useful are: file type you are trying to load An example of the image that causes the failure. What version of the OSG you are using A full strack trace of the error. Robert. On Tue, Jun 21, 2011 at 12:22 PM, Sergey Alekseev sergej.alexe...@gmail.com wrote: Tell me please, why doesn't work function readImageFile? In OpenSceneGraph examples it is called like osg::Image * img = osgDB::readImageFile (filename); I get exception - heap allocation error. The size that function tries to allocate is ~ 3458768586 bytes (picture size is 4 KB). Pre-complilated examples work well. Compilator VC++ 2010 Express. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40712#40712 ___ 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] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Mathias, 2011/6/21 Mathias Fröhlich m.froehl...@science-computing.de: Initially I get a full screen window *with* decorations. Pressing f gives a small window as expected. Press f again gives the previous huge window including decorations as before Thanks for the explanation. It sounds like the _MOTIF_WM_HINTS hasn't been implemented with CDE. But as I told, I have kept that compiling and running osg in its major functionality. This detail of the viewer is not really used and not worth a huge effort. I'll just let this issue pass for 3.0 then, I suspect the of window decoration not toggling off has been with all the way through the 2.x series and probably back to the 1.x days as well as they all rely upon _MOTIF_WM_HINTS for controlling the window decoation. From my point of view, this is fine. The only WM I can think of behaving different is may be twm or fvwm which both should be easy to test with. I can test fvwm at home easily since the primary flightgear machine runs fvwm. Thanks. From today morning, it compiled on HP and solaris. Excellent news. I did make quite a few changes yesterday to address the cppheck reported issues so was a bit concerned but the older compilers used on these platforms. I'm not expecting any further widespread code changes so we should be in a good place for 3.0. Currently flightgear does not render well on current osg trunk. Over the time we gained a highly adapted cull stage with even an own cull visitor and a home grown depth partitioning scheme. I am not yet sure, but I expect that there might be some interference with changes that have broken flightgear. Ouch, sorry to hear that things aren't working well for FlightGear. The basics of the scene graphi and viewer are the same between 2.8.x and 3.0 so I'm surprised to hear of problems. Is there an online record of these problems and what might be the root cause of them? I do wonder if the custom cull faciltiies might be solvable in other ways - for instance osgViewer::View now has some support for depth partitioning. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Navigation - Walk at 6 feets.
Hi, Magnus Kessler: Thanks a lot for your help. I will try it. Best Regards: Nilton -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40714#40714 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg on UNIX Dinosaurs
Hi Robert, On Tuesday 21 June 2011, Robert Osfield wrote: [...] Ok! Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtialPlanetBuilder-0.9.12 dev release tagged, and plans for VPB-1.0
Hi, Wikipage is updated already. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40721#40721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How does accept(simplifier) works?
On 6/20/2011 8:44 PM, Nilton Paulo wrote: Hi, everybody: Into my code, I am trying to set sample ratio as half, for example, same as written bellow: osg::ref_ptrosg::Node model3ds = osgDB::readNodeFile(C:\\OpenSceneGraph-2.8.0\\Z_File_To_Test\\Casa_Pronta.3DS); osgUtil::Simplifier simplifier; simplifier.setSampleRatio(0.5); model3ds-accept(simplifier); viewer.setSceneData(model3ds); But it stays in loop into the line model3ds-accept(simplifier); and does not return... Does anybody have used accept(simplifier) and could help me undertanding what is happening? http://www.rozengain.com/blog/2011/02/16/openscenegraph-level-of-detail-management/ Have you tried it on a known-good model like cow.osg? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. 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
Re: [osg-users] BoundingBox
Hi Nilton, This test does not work properly and IF always return TRUE. In addition to what Robert said, I'll add that the reason your test returns true is that you're using the camera's bounding sphere. Since the camera is the root of the scene graph, its bounding sphere contains the bounding spheres of the whole scene. So of course any wall's bounding sphere intersects with the scene's bounding sphere (it's included). Your camera bounding sphere could be created like this: osg::Vec3 eye, center, up; viewer.getCamera()-getViewMatrixAsLookAt(eye, center, up); osg::BoundingSphere bs1(eye, 0.5); // small radius Then if I were you I'd intersect this with the bounding box of the wall, not its bounding sphere, because the bounding sphere will not be close-fitting. Plus, this is not even good enough if your walls are not axis-aligned... So I would consider either Robert's advice, or use a dedicated collision detection library. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing a workaround for fullscreen toggling issues under modern X11 window managers
Hi Mathias, 2011/6/21 Mathias Fröhlich m.froehl...@science-computing.de: Yes, I was erasing my initial comment on that some minutes ago :). From my personal point of view, I think that our code touches too much internals of osg. So, I think we need to change that in some way to make that more robust. For the CullVisitor that is subclassed - which is one of the potential problems I fear for compatibility - there might be room for improovements in osg. When users attempt to do things is awkward ways, especially when grampling with lower level facilities, it's a warning sign to me that the OSG is make the problem more difficult and probably needs refactoring. Sometimes it's just the users overcomplicating things for little reason, but often there will be an underlying design issue that they are trying to workaround. It's doesn't always mean I can see a straight forward solution... but occassionally a small tweak to the OSG can make a big diffrence. The problem is with the cull callback in a Geode during the cull stage. The cull callback in a geode cannot do much. It just calls an empty traverse method in a geode. Then past that all drawables are *unconditionally* - from the point of the geodes cull visitor - put into the render graph. This lies with Geode's having Drawable children that aren't Nodes so the usual traversal rules don't apply. One modification to the OSG that I have considered for a while is to make a Drawable a Node. This has a number of knock on effects though so something I'll need to consider rather carefully. Anyway, now this is too late for 3.0. But may be we could think about that past 3.0. Too later for 3.0 for sure. 3.2 a possibility though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] troubles with osgDB::readImageFile
Hello Sergey, I get exception - heap allocation error. The size that function tries to allocate is ~ 3458768586 bytes (picture size is 4 KB). Pre-complilated examples work well. Compilator VC++ 2010 Express. It sounds like you're mixing debug/release libraries / executable. You need to compile your executable in release linking only to OSG release libs, and in debug linking only to OSG debug libs. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes FBX plugin warnings
Did the warnings highlight any bugs? The warnings about unhandled enumerators weren't bugs so I just put in some empty default: statements, but the warning about comparing different types of enums looked like a genuine bug. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp specular
Hi Sergey, osgExp expects specular in range 0...1000, that is range you can set in 3ds max for specular intensity. It's looks different in 3ds max then in osg though. OK, that explains it, I thought the max was 100. I'll adjust my shaders so the result looks the same in Max and in OSG. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osg rendering in QGraphicsObjects
Hi everybody
¨
I'm using a Qt framework and i have to integrate an OSG widget to render a 3D
scene, in a QGraphicsScene, but my code doesn't work.
(I'm using OQG 3.0 and i'm working on Windows XP)
I have seen on the forum that the example osgViewerQt can help to integrate OSG
in a QWidget. I used it and it works when i just tried to render a QWidget (i
modified it a little bit to display the cow only, not the pop-up window and the
other .osg objets)
Then i used a QGraphicsProxyWidget to render my QWidget in the QGraphicsScene.
This time, i just obtain a white rect in the window.
Here is my main: (ViewerWidget is the example class wich is also a QWidget)
Code:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QGraphicsView *view = new QGraphicsView(new QGraphicsScene());
QGraphicsProxyWidget* proxywidget = new QGraphicsProxyWidget();
proxywidget-setGeometry(QRect(0, 0, 800, 600));
QWidget *widget = new
ViewerWidget(osgViewer::ViewerBase::CullDrawThreadPerContext);
widget-setGeometry(0, 0, 800, 600);
proxywidget-setWidget(widget);
view-scene()-addItem(proxywidget);
view-show();
return app.exec();
}
Did i do something wrong?
I'm not sure the example is adapted to use QGraphicsProxyWidget. In this case,
is there any alternative solution to get a QGrapgicsObjet?
Thank you in advance
Cheers,
Benoit
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40722#40722
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.0.0 release candidate 2 tagged
I've started a continuous Jenkins build on the 3.0 branch, so you should be seeing those build results hitting CDash soon. I think I even got it to pass along build warnings, etc. now, which should be helpful. I'm blowing away the build directory every midnight my timezone, so that should also make sure we're getting full builds regularily. Ryan On Tue, Jun 21, 2011 at 5:58 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi All, I have just tagged the second 3.0.0 release candidate, you can get the source from: source package : OpenSceneGraph-3.0.0-rc2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0-rc2 OpenSceneGraph Feedback from the community on the state of the 3.0 branch and rc1 has been pretty positive so it does look like we are in a pretty good state for the final 3.0.0 stable release. While feedback has been positive it does concern me is that volume of feedback from the community is still rather low, suggesting that the release candidate 1 and the OSG-3.0 branch haven't recieved a lot of widespread testing yet, so perhaps we might be lulling ourselves into a false sense of security. What we really need now is more widespread testing so we can catch any problems that might be present on more niche usage cases or the less comonly used build platforms.Almost always right away a stable release we get feedback from the community that there is a build issue or a feature regression that could have easily been resolved prior to the release, but the problems slipped through because those users who come across the issues didn't actually test the software prior to release. I would encourage everyone in the community not to assume just because others are doing testing and providing positive feedback that things will also work fine for you, assume that there will be problems and to make sure that problems these problems get resolved come come forward and test the software and tells us about the problems. Right now is great opportunity to get those bugs resolved, I and others are primed to investigate and resolved them. After the stable release you'll have missed the boat - we'll be on holiday or focussing on other work. So please test, it's your own as much as everyone elses good. Thanks in advance, Robert. -- Changes checked in since 3.0.0-rc1 are: 2011-06-21 10:07 robert * src/osg/glu/libtess/tess.h: Merged changeset 12581 from svn/trunk to address VisualStudio warning 2011-06-21 09:58 robert * src/osgPlugins/fbx/WriterCompareTriangle.cpp, src/osgPlugins/fbx/WriterCompareTriangle.h, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.cpp, src/osgPlugins/fbx/fbxMaterialToOsgStateSet.h, src/osgPlugins/fbx/fbxRLight.cpp, src/osgPlugins/fbx/fbxRMesh.cpp, src/osgPlugins/fbx/fbxRNode.cpp: Merged from svn/trunk warnings fixes provided by Changeset 12582 from Michael Platings, along with addition of returns at ends of files and changes to tabs to four spaces. 2011-06-20 19:41 robert * CMakeLists.txt: Updated release candidate number 2011-06-20 19:37 robert * src/osgPlugins/bmp/ReaderWriterBMP.cpp, src/osgPlugins/png/ReaderWriterPNG.cpp, src/osgPlugins/tga/ReaderWriterTGA.cpp: Merged from svn/trunk, r12574. From Farshid Lashkari, BGR write support for BMP, PNG and TGA 2011-06-20 19:33 robert * examples/osgphotoalbum/PhotoArchive.cpp, src/osg/ImageUtils.cpp, src/osg/OcclusionQueryNode.cpp, src/osgDB/ExternalFileWriter.cpp, src/osgDB/InputStream.cpp, src/osgDB/OutputStream.cpp, src/osgPlugins/Inventor/ConvertToInventor.cpp, src/osgPlugins/Inventor/ReaderWriterIV.cpp, src/osgPlugins/OpenFlight/expGeometryRecords.cpp, src/osgPlugins/cfg/CameraConfig.cpp, src/osgPlugins/freetype/FreeTypeLibrary.cpp, src/osgPlugins/geo/ReaderWriterGEO.cpp, src/osgPlugins/geo/osgGeoNodes.h, src/osgPlugins/md2/ReaderWriterMD2.cpp, src/osgPlugins/pic/ReaderWriterPIC.cpp, src/osgPlugins/ply/plyfile.cpp, src/osgPlugins/pvr/ReaderWriterPVR.cpp, src/osgPlugins/shp/ESRIShapeParser.cpp, src/osgPlugins/shp/XBaseParser.cpp, src/osgPlugins/zip/unzip.cpp, src/osgShadow/MinimalCullBoundsShadowMap.cpp, src/osgViewer/ScreenCaptureHandler.cpp, src/osgVolume/Locator.cpp, src/osgVolume/RayTracedTechnique.cpp, src/osgWrappers/serializers/osg/ShaderBinary.cpp: Merged changes to svn/trunk that address cppcheck reported issues: [examples/osgphotoalbum/PhotoArchive.cpp:56]: (error) Memory leak: fileIndentifier [examples/osgphotoalbum/PhotoArchive.cpp:257]: (error) Deallocating a deallocated pointer: newData
[osg-users] Potential OSG 3.0 --run-on-demand regression
Hi all, tested OpenSceneGraph 3.0-rc2 on Ubuntu 10.10 with NVidia 270.41.19, which builds and runs just fine. However, I noticed that (at least on my system) trying to run e.g. 'osgviewer --run-on-demand cessna.osg' renders the first frame just fine, but then apparently frame updates aren't triggered by any further input events. Reverting the changes of src/osgViewer/Viewer.cpp and src/osgViewer/CompositeViewer.cpp from r12523 to the previous r12294 makes it work again. Anyone else able to reproduce that behavior, too? Thanks for all the great work on OpenSceneGraph and good luck with the upcoming release, tamer. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential OSG 3.0 --run-on-demand regression
On 6/21/2011 9:44 AM, Tamer Fahmy wrote: Anyone else able to reproduce that behavior, too? This appears to have similar issues on Windows 7. No response from mouse interaction, and also the 'esc' key doesn't cause the app to exit. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Potential OSG 3.0 --run-on-demand regression
Hi Paul, This appears to have similar issues on Windows 7. No response from mouse interaction, and also the 'esc' key doesn't cause the app to exit. Same here on trunk, so it's not limited to the 3.0 branch. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osg rendering in QGraphicsObjects
Hello Benoit,
The only way i got QGraphicsView worked with OSG and still have the full
functionality of both was:
1. make an offscreen graphic context for OSG
2. create a QGLWidget
3. share textures between those 2 contexts
4. set the viewport of QGraphicsView to the QGLWidget
5. find a way to sync both context so one does not access a texture that
is the process of beeing rendered
6. Reuse shared texture in some way in QGraphicsScene
So far, i always had some problem with translucency and Qt whenever i
tried to mix OSG somewhere. I suspect the backingstore of Qt but have
not verified anything. Someone out there has
a deeper knowledge of Qt and might offer a solution/clue?
On 21/06/2011 10:03 AM, Benoit Morel wrote:
Hi everybody
¨
I'm using a Qt framework and i have to integrate an OSG widget to render a 3D
scene, in a QGraphicsScene, but my code doesn't work.
(I'm using OQG 3.0 and i'm working on Windows XP)
I have seen on the forum that the example osgViewerQt can help to integrate OSG
in a QWidget. I used it and it works when i just tried to render a QWidget (i
modified it a little bit to display the cow only, not the pop-up window and the
other .osg objets)
Then i used a QGraphicsProxyWidget to render my QWidget in the QGraphicsScene.
This time, i just obtain a white rect in the window.
Here is my main: (ViewerWidget is the example class wich is also a QWidget)
Code:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QGraphicsView *view = new QGraphicsView(new QGraphicsScene());
QGraphicsProxyWidget* proxywidget = new QGraphicsProxyWidget();
proxywidget-setGeometry(QRect(0, 0, 800, 600));
QWidget *widget = new
ViewerWidget(osgViewer::ViewerBase::CullDrawThreadPerContext);
widget-setGeometry(0, 0, 800, 600);
proxywidget-setWidget(widget);
view-scene()-addItem(proxywidget);
view-show();
return app.exec();
}
Did i do something wrong?
I'm not sure the example is adapted to use QGraphicsProxyWidget. In this case,
is there any alternative solution to get a QGrapgicsObjet?
Thank you in advance
Cheers,
Benoit
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40722#40722
___
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] VirtialPlanetBuilder-0.9.12 dev release tagged, and plans for VPB-1.0
Robert, Builds fine with OSG 3.0rc2 on Mac OSX 10.6.7 64 bit. Martins On 6/21/11 9:13 AM, Robert Osfield wrote: Hi All, OpenSceneGraph-3.0.0 release seems to be going smoothly so it looks like I might have a little time this week to squeeze in getting VirtualPlanetBuilder to 1.0 as well. This morning I merged a couple of changes to VPB from the community and made a a little cleanup myself so it reminded me that VPB-1.0 is as long overdue as OSG-3.0 so why not go with the flow and get VPB-1.0 out the door. It's basically feature complete for it's 1.0 and has been so for quite so time now - it's just I've been so busy with the OSG and client work that it's sat a little neglected in the corner. The first step was to tag a dev release which you can now grab from: svn co http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.12 VirtualPlanetBuilder Could members of the community update to svn/trunk of VPB or the 0.9.12 dev release above and let me know how well things are building working on your system. If things look solid I'll just go right ahead and make the 1.0 later this week. Cheers, 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] Mac OS X windowing system related issue (maybe)
Hi, it is not easy to explain the nature of the issue I'm experiencing anyway I'll try. I have an OSG application (on Mac OS X) that, on startup (no viewer realized and not in the application loop yet), opens a video device in order to display a webcam stream inside the application itself (the interface to the video device is provided by a 3rd party lib)...everything is fine unless I ask to display the camera settings window before actually starting the video stream: in that case the correct behavior is that the OSG application waits until the user makes his choices and close the settings window, when the window is closed the OSG application continues setting up the scene and finally enters the application loop and shows the viewer window. When I used OSG 2.9.6 everything worked as described in both cases (with and without showing the settings window), but when I switched to OSG 2.9.14, 2.9.16 or 3.0.0 if I choose to show the camera settings window then I cannot move or grab focus on that window in any way (even though I still can click its controls/buttons - for instance if I move another window on top of that settings window, then I cannot bring to the foreground it anymore). Unfortunately I cannot have too much control and information about that camera settings window, I can just choose to show it or not when I open the video stream..that window is not managed by my code and, as far as I know, it is related to QUICKTIME in some way, I do not know much more and cannot provide further details about this. Since my OSG application code didn't change in any way and since it worked with OSG 2.9.6, I wonder if something changed from the windowing system point of view on Mac OS X (I have no problems on Windows by the way). By the way in the console I also get this message: GraphicsWindowCarbon::grabFocusIfPointerInWindow: not implemented Don't know if this may be related to my issue... If this can help, when I built OSG I chose 'Carbon' as windowing system, I built OSG as frameworks and I'm building my OSG application as a console application. If I build my application as an app bundle (instead of as a console application) then it works even if I choose to show the settings window. I know that there is very little information about this issue, but I wonder if any Mac OS X expert has a suggestion or can tell me what I should look for in order to overcome this problem? Thanks. Alessandro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] dgn2osg
On 6/21/2011 11:55 AM, abhishek agarwal wrote: Hi, I want to extract information from .dgn files and i cannot find dgn2osg plugin. Is there anyway i can use dgn files with osg. Can you help me? http://www.lamce.coppe.ufrj.br/grva/data/labcogsdk/download/extras/dgn2osg/ http://www.bentley.com/en-US/Products/MicroStation/OpenDGN/ Thank you! Cheers, abhishek -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. 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] Collada importer
I think there may be a bug in the collada importer, or at least it doesn't behave the way I expect. I'm importing a cube from blender through collada. The definition in the file comes out with a point list of 24 items (which makes sense, 8 points of 3 elements each). After import, I wind up with a Geode consisting of 24 points, with each point repeated 3 times. I'm trying to use this with osgbBullet. The collada imported cube behaves weird, if I replace the collada cube with an osgbox everything works fine. Can someone verify that this import behavior is incorrect ? Mark ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac OS X windowing system related issue (maybe)
Hi, first of all I apologize if this is a duplicate post, I first tried to send a mail to the mailing list, but then I could not find it in this forum, so I'm trying again here by creating a new topic. It is not easy to explain the nature of the issue I'm experiencing anyway I'll try. I have an OSG application (on Mac OS X) that, on startup (no viewer realized and not in the application loop yet), opens a video device in order to display a webcam stream inside the application itself (the interface to the video device is provided by a 3rd party lib)...everything is fine unless I ask to display the camera settings window before actually starting the video stream: in that case the correct behavior is that the OSG application waits until the user makes his choices and close the settings window, when the window is closed the OSG application continues setting up the scene and finally enters the application loop and shows the viewer window. When I used OSG 2.9.6 everything worked as described in both cases (with and without showing the settings window), but when I switched to OSG 2.9.14, 2.9.16 or 3.0.0 if I choose to show the camera settings window then I cannot move or grab focus on that window in any way (even though I still can click its controls/buttons - for instance if I move another window on top of that settings window, then I cannot bring to the foreground it anymore). Unfortunately I cannot have too much control and information about that camera settings window, I can just choose to show it or not when I open the video stream..that window is not managed by my code and, as far as I know, it is related to QUICKTIME in some way, I do not know much more and cannot provide further details about this. Since my OSG application code didn't change in any way and since it worked with OSG 2.9.6, I wonder if something changed from the windowing system point of view on Mac OS X (I have no problems on Windows by the way). By the way in the console I also get this message: GraphicsWindowCarbon::grabFocusIfPointerInWindow: not implemented Don't know if this may be related to my issue... If this can help, when I built OSG I chose 'Carbon' as windowing system, I built OSG as frameworks and I'm building my OSG application as a console application. If I build my application as an app bundle (instead of as a console application) then it works even if I choose to show the settings window. I know that there is very little information about this issue, but I wonder if any Mac OS X expert has a suggestion or can tell me what I should look for in order to overcome this problem? Thanks. Alessandro -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40725#40725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question on optimizer flatten static transforms and line intersections
Hello OSG users, I extract geometries from the scene graph and perform some line intersections directly on them. If there are some transformations above in the tree then the intersections will not take them into account. I'd like to use osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS so that the geometries are flattened and the intersections work on the transformed/flattened geometries. So I do: // Create a node visitor to set all transforms to static in scene. // Optimize osgUtil::Optimizer optimzer; optimzer.optimize(pScene.get(), osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS | osgUtil::Optimizer::MERGE_GEOMETRY | osgUtil::Optimizer::CHECK_GEOMETRY | osgUtil::Optimizer::MAKE_FAST_GEOMETRY); // Gather geometries. // Do intersections. When I do this the geometries look transformed/flattened but the line intersections do not. However, if I write / read the scene to disk before I gather geometries then the intersections are good (transformation/flattened): // Optimize // ... osgDB::writeNodeFile(*pScene.get(), tmp.osg); pScene = osgDB::readNodeFile(tmp.osg); // ... I'd rather not do that ! What am I missing here ??! cheers, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X windowing system related issue (maybe)
Hi Alessandro, Am 21.06.11 22:35, schrieb Alessandro Terenzi: If this can help, when I built OSG I chose 'Carbon' as windowing system, I built OSG as frameworks and I'm building my OSG application as a console application. If I build my application as an app bundle (instead of a try creating the WindowSystemInterface via osg::GraphicsContext::getWindowingSystemInterface() before opening the settings-dialog. the WindowingSystemInterface does some fancy things, so that windows opened by a console-app work correctly. Perhaps that helps. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtialPlanetBuilder-0.9.12 dev release tagged, and plans for VPB-1.0
Hi Robert, builds fine in Release mode against OSG 3.0 RC2, using Debian Testing x86_64 and g++ 4.6. Best wishes Stephan On 21.06.2011 15:13, Robert Osfield wrote: Hi All, OpenSceneGraph-3.0.0 release seems to be going smoothly so it looks like I might have a little time this week to squeeze in getting VirtualPlanetBuilder to 1.0 as well. This morning I merged a couple of changes to VPB from the community and made a a little cleanup myself so it reminded me that VPB-1.0 is as long overdue as OSG-3.0 so why not go with the flow and get VPB-1.0 out the door. It's basically feature complete for it's 1.0 and has been so for quite so time now - it's just I've been so busy with the OSG and client work that it's sat a little neglected in the corner. The first step was to tag a dev release which you can now grab from: svn co http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.12 VirtualPlanetBuilder Could members of the community update to svn/trunk of VPB or the 0.9.12 dev release above and let me know how well things are building working on your system. If things look solid I'll just go right ahead and make the 1.0 later this week. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
