Re: [osg-users] [build] error compiling the stable version
HI Sajjadul, Removing the path pointing to libsvg library and headers in the cmakegui should solve your issue cheers Sebastian Hi, How to disable the plugin from within the cmake ? I did not find any opetion to do it Thank you! Cheers, Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59077#59077 ___ 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] Pop Buffers with OpenSceneGraph
Hi Marcel, Your work sounds really interesting. I don't have time right now to dive in and have a look at the project - I have a backlog of submissions to deal with before I can play. I will try and chip with providing some thoughts on your questions. On 19 April 2014 19:15, Marcel Pursche marcel.purs...@student.hpi.uni-potsdam.de wrote: 1. I'm currently using custom PopDrawElements classes that inherit from DrawElementsUByte, *UShort, or *UInt. The only difference is that they support a start offset and end. So let's say a DrawElements contains 3000 indices I can set the start and end so that only the first 300 are drawn. Because this is only a very small extension to the original DrawElements classes I would put that code directly into these classes. I think that shouldn't break existing apps, because setting these additional parameters is optional. It sounds a bit like you want to have lots of separate DrawElements* that share the same index data buffer, but index it with different offsets, kinda like a proxy method. Sharing the data could actually be down if the DrawElements share the same ElementBufferObject, then the DrawElements* objects would all populate the same data buffer and provide the existing support buffer object support would handle the offsets for you. Are you PopDrawElements computed on the fly? 2. The naming of the classes is a bit odd, because they describe how the functionality was implemented and not what the classes do. Instead of PopGeometry I would rename it to LodGeometry. Any objections or better names? PopGeometry is a bit mis-leading as push/pop have particular means in OpenGL and C++ etc, it would lead one to think you are push and popping Geometry. It's less confusing if you know about the 3DDOM POP Buffers paper, but most won't be. LODGeometry or LevelOfDetailGeometry might be better. 3. I'm not quite sure in which namespace the classes would belong. The PopGeometry/LodGeomtry would probably fit best in the osg namespace and the visitor in osgUtil. Is this a good idea? osgUtil is for utility classes rather than scene graph objects. osgSim or osgTerrain might be appropriate, or in core OSG if it's something that lots of users would utilize. Whether they might I can't say as I'm not familiar with the approach. 4. My conversion visitor currently only supports the BIND_PER_VERTEX option for vertex attributes, so there is still some work to do. What binding options are still relevant? BIND_OVERALL and BIND_PER_PRIMTIVE_SET? Or do I need to integrate BIND_PER_PRIMITIVE support as well for older models and applications? You can safely ignore BIND_PER_PRIMITIVE it's long been deprecated and loaders should no longer create objects with this type, and old files will automatically converted. The other types are all valid thought. 5. Because the technique depends on the usage of a vertex shader I would add two static methods one returns a basic osg::Program with phong shading and another one only returns the shader code with the necessary uniforms and a vertex quantization function that should be used in the shader. I don't know the code so can't comment on the low level specifics of how to manage the shaders for it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLightingMode crash in multithread mode
Hi Sylvain, The threading support in osgViewer doesn't include modifying the viewer and scene graph at the same time as cull. You should modify scene graph objects during update, or event traversals - basically any time outside of when viewer::renderingTraversals() are running. Robert. On 22 November 2013 14:08, Sylvain Comtois sylvain.comt...@gel.ulaval.ca wrote: Hi, First, my program work without any problem when the threading model is configure to single thread and i use one master camera and tree slaves cameras on a multiprocessor computer. When i call the method Viewer::setLightingMode of my viewer, osg crash when the method osgViewer::Renderer::cull is call by the threading engine. The crash occur in the following method sequence: ... osg100-osgd.dll!osg::StateSet::setModeToInherit osg100-osgd.dll!osg::StateSet::removeMode osg100-osgUtild.dll!osgUtil::SceneView::setLightingMode osg100-osgUtild.dll!osgUtil::SceneView::inheritCullSettings osg100-osgUtild.dll!osgUtil::SceneView::inheritCullSettings osg100-osgViewerd.dll!osgViewer::Renderer::cull osg100-osgViewerd.dll!osgViewer::Renderer::operator() osg100-osgd.dll!osg::OperationThread::run()ot13-openThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread Note that i have more then one thread that call the removeMode method in the same time when the error occure. I set the viewer data variance to DYNAMIC but when i debug the program, the SceneView data variance is still unspecified. I also set the data variance of each camera to DYNAMIC. Does i have to set the data variance of something else to DYNAMIC? Thank you! Cheers, Sylvain -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57398#57398 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] osg and Qt5 and debian wheezy
Hi Bernd, If you application is using the osgQt library and this lib is linked to Qt4 then mixing the viability of mixing Qt5 libs in your application will be down to Qt4/5 compatibility, something I can't answer as I'm no Qt expert but I guess it's reasonable to assume that this could cause problems. If you can't mix Qt5 and Qt4 within a single application then you'll either have to rebuild the OSG against Qt5 or avoid using components of the OSG that use Qt - primarily this is osgQt but there a few plugins use it too. Non of the core OSG libraries use Qt so fundamentally the OSG will be Qt agnostic, so I you avoiding osgQt and used your own OSG/WIndow integration or just used the OSG's osgViewer native windowing support you'll be fine. Robert. On 19 April 2014 12:15, Bernd Hahnebach o...@b75.ch wrote: OK delete all links :-( Hi All, I'm new to the forum. I provide a linuxbuild of IfcPlusPlus. It is a viewer to display digital modells of building in file format ifc. The linuxbuild is on github .../berndhahnebach/IFCPlusPlus. Branch linuxbuild-qt4 runs smooth on debian wheezy using the osg of wheezy. See on github .../berndhahnebach/IFCPlusPlus/blob/linuxbuild-qt4/README.Linux The original code I use for my build (master branch) is linked against Qt5. I would like to link against qt5 as well to minimise changes. In branch linuxbuild-qt5 on github .../berndhahnebach/IFCPlusPlus/blob/linuxbuild-qt5/README.Linux . I tried to build IfcPlusPlus agiainst Qt5, it builds but gives Segmentgation Fault at Startup. I found the binary uses libQtGui.so.4 which is of Qt4. My assumtion is this is because libopenscenegraph99 in debian wheezy depends on Qt4libs. That is why I can not link against Qt5. Does this mean if I would like to build IfcPlusPlus against Qt5 I need to build osg against Qt5 myself to use it with IfcPlusPlus? Thank you! Cheers, Bernd If you would like to try IfcPlusPlus: search for IfcOpenHouse.ifc or for digital210king if you would like to treat IfcPlusPlus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59070#59070 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is it possible to render in one RTT two cameras?
For example: I have the first camera - this is the main scene and the second camera - screenspace 2d otho menu. Can I render them consistently in one RTT (for future postprocessing)? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59084#59084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
