Re: [osg-users] OSG static linking
Setting OSG_MSVC_VERSIONED_DLL to OFF appears to fix this issue, and causes the static .lib names to not contain the SO version. (After I rebuild with this set to OFF, I'm guessing the stock CMake find scripts will find my static-built OSG.) Is that correct? The CMake variable clearly says "DLL", and this is a static build, so no DLLs are being built. Yet disabling it changes the name of the output static .lib name. Just checking. On Wed, Mar 12, 2014 at 3:17 PM, Paul Martz wrote: > Hi all -- Is anyone using CMake to find a static-built OSG? If so, how are > you getting that to work? > > When building static OSG, all the library names are prefixed with > osg. For example, with OSG v3.3.1, the so version is 111, so I > get libs named: osg111-osg.lib, osg111-osgDB.lib, osg111-osgUtil.lib, etc. > And the stock CMake find scripts fail to find those libraries because those > scripts look for osg.lib, osgDB.lib, osgUtil.lib, etc. > > Any info would be appreciated. >-Paul > -- -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG static linking
Hi all -- Is anyone using CMake to find a static-built OSG? If so, how are you getting that to work? When building static OSG, all the library names are prefixed with osg. For example, with OSG v3.3.1, the so version is 111, so I get libs named: osg111-osg.lib, osg111-osgDB.lib, osg111-osgUtil.lib, etc. And the stock CMake find scripts fail to find those libraries because those scripts look for osg.lib, osgDB.lib, osgUtil.lib, etc. Any info would be appreciated. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PolytopeIntersector, LineSegmentIntersector, and PagedLOD
Hi, I'm getting unexpected behavior from PolytopeIntersector and was wondering if it might have something to do with the PagedLODs in my scene graph. I want to find all polygons in a rectilinear volume in my model, in model coordinates (not related to any view on the screen) based on two corner vertices. The weird thing is that if I use the two corner points as the ends of a LineSegmentIntersector, I find intersections, but a PolytopeIntersector with Polytope made from a BoundingBox with those same corner points, over the same graph, finds no intersections. Shouldn't the PolytopeIntersector at least find the geometry that the LineSegmentIntersector does? I thought I might have the direction of the planes backwards for the Polytope, so I tried flip() but either way I get no intersections. I've read through the code and it looks like there might be issues related to the PagedLODs in my scene graph. Any idea if PolytopeIntersector and PagedLOD play together well or not? I've looked for examples and read code for PolytopeIntersector, but there doesn't seem to be much out there, and most of it uses View-based intersection, not model-based. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58575#58575 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vertex attribute divisor support
Hi James, As far as I have seen, GL_ARB_texture_float is about as well-supported as GL_ARB_draw_instanced. The only exception I've been able to find on test hardware has been software Mesa, which supports neither. We make use of multiple floating point textures for encoding per-instance data. One problem is that those textures require normalised values, so you have to supply your own ranges as uniforms for multiplying them back out in the shaders. To be honest, it's far more of a faff than examples I've seen (ahem) using glVertexAttribDivisor, and I'd far rather use that mechanism if it were supported conveniently inside OpenSceneGraph. Alistair Baxter Software Engineer We'll be exhibiting at PDAC 2014 from booth #1607, 2nd - 5th March 2014. For further information please visit http://www.mve.com/calendar Midland Valley Exploration Ltd. 144 West George Street Glasgow G2 2HG United Kingdom Tel: +44 (0) 141 332 2681 Fax:+44 (0) 141 332 6792 The structural geology experts ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] vertex attribute divisor support
Hi, I’ve asked this question in the past, but re-visitng it again: given the lack of core support in Array for glVertexAttribDivisor, does anyone have any recommendations for getting per-instance data working easily? I should state that I’m aware of the ‘use a texture and gl_InstanceID to sample it in the vertex shader' solution to this, but I need to pass somewhat more data than will fit into a standard texture for each instance (3 floats and various 8-bit values I could encode into a 32-bit int). In the refactoring of osg::Geometry, the _DIVISOR_ arguments to Array binding were removed, since there was never any backend support, so the only option I am sure will work is a custom drawable, where I manually setup the arrays / VBOs, call glVertexAttribDivisor myself, and then call glDrawArraysInstanced myself. (I.e, bypass Array / PrimitiveSet / all the ArrayDispatcher machinery / Geometry:draw) That feels like a rather excessive amount of work to solve this. Can anyone suggest anything simpler? I am aware that floating-point-textures might work to store my per-instance data needs, but I don’t have a good feeling for the portability of floating-point textures (on desktop hardware), whereas glVertexAttribDivisor is supported everywhere I care about. Similarly I’d be fine with making a hacked-up subclass of osg::Geometry which lets me bypass the ArrayDispatchers and invoke glVertexAttribDivisor myself, but I don’t know if that has a chance of working. Kind regards, James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory releasing problem by addchild and removechild
robertosfield wrote: > Hi Lv, > > On 10 March 2014 14:40, Lv Qing < ()> wrote: > > > Hi, > > > > ... > > I have read some posts about memory releasing problem by addchild and > > removechild. > > > > > There are no problems with memory management with addChild and removeChild. > It's been working very robustly for many years. > > > There are known bugs with the VS memory tracking tools though > > > > > > Here is my situation ,we developed osg app by qt in win7, we use class > > ViewerWidget to adding our viewer as a qt widget. > > > > We did a test to simply adding 5 osg::Node to a osg::Group then > > removing all nodes and the group.After first adding ,it increase about > > 4000K memory ,I think it is the proper storage of 5 osg::Node,then by > > the first removing,it only decrease 400K。Then by another 5 adding ,it > > only increase 400K instead 4000K,if we removing all nodes again ,it still > > decrease 400K. > > > > No matter how many time we tried to adding or remove nodes ,if we keep > > the max test node to 5,It always hold the 4000K memory even we remove > > all nodes. > > > > It looks like osg still hold the first 5 osg::Node as a Cache ，not > > releasing it immediately。 > > > > But I must admit ,it do releasing the memory properly in osgViewer > > or other osg examples by the same test! > > > > We use win7 ,osg2.9.16 ,osg3.2.0,we observe memory change by windows > > resource management > > > > > Might I suggest you try more reliable tools for tracking memory than provided > by windows? > > > Robert. > > -- > Post generated by Mail2Forum Thx!Mr Robert! what is your recommendation reliable tools for tracking memory by windows? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58572#58572 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View::setCameraManipulator
HI Gianni, On 12 March 2014 09:07, Gianni Ambrosio wrote: > Hi Robert, > I'm simply saying that setCameraManipulator should just set the camera > manipulator into the view and not also set the node implicitly got from the > scene data: it is not his responisibility. And that's not always a > desirable behavior since in other part of the code the node should be > already set to a node different from the root scene data. That means > setCameraManipulator overrides the node I have already set to the > manipulator (and I don't want the home position to be computed again too). > > In my case I'm switching manipulators and I want that each manipulator > maintains its node reference and not been reset by the call > setCameraManipulator. So from my point of view it's up to the programmer to > set the proper node to a manipulator. The CameraManipulator scheme is far from perfect and need a revamp, but currently all the CameraManipulator implementations assume that the Viewer sets the node to use with the CameraManipualtor, rather than assuming that the end user will set it, we can't change that without breaking the existing manipulator or user code that uses them. If the CameraManipulators don't work ideally for you as they are there is nothing stopping you from developing your own Camera management scheme in place of the CameraManipulators - osgViewer has been designed so that the osgGA CameraManipulators are just optionally, and are only used if you they are assigned by the viewer. If you want your own scheme simply set the Camera view matrices/projection matrices as you require on each new frame. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory releasing problem by addchild and removechild
Hi Lv, On 10 March 2014 14:40, Lv Qing wrote: > Hi, > > ... > I have read some posts about memory releasing problem by addchild and > removechild. > There are no problems with memory management with addChild and removeChild. It's been working very robustly for many years. There are known bugs with the VS memory tracking tools though > Here is my situation ,we developed osg app by qt in win7, we use class > ViewerWidget to adding our viewer as a qt widget. > >We did a test to simply adding 5 osg::Node to a osg::Group then > removing all nodes and the group.After first adding ,it increase about > 4000K memory ,I think it is the proper storage of 5 osg::Node,then by > the first removing,it only decrease 400K。Then by another 5 adding ,it > only increase 400K instead 4000K,if we removing all nodes again ,it still > decrease 400K. > > No matter how many time we tried to adding or remove nodes ,if we keep > the max test node to 5,It always hold the 4000K memory even we remove > all nodes. > > It looks like osg still hold the first 5 osg::Node as a Cache > ，not releasing it immediately。 > > But I must admit ,it do releasing the memory properly in osgViewer > or other osg examples by the same test! > > We use win7 ,osg2.9.16 ,osg3.2.0,we observe memory change by windows > resource management > Might I suggest you try more reliable tools for tracking memory than provided by windows? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting flickering
Thanks Kostantin! I will try to do that Nick On Wed, Mar 12, 2014 at 8:24 AM, Konstantin wrote: > Hello Trajce!!! > > LightSource may be traversed after some Drawables. This may be the problem! > Try to move LightSource node upper to be traversed first. > > > KOS > > > > 2014-02-25 0:44 GMT+04:00 Trajce Nikolov NICK < > trajce.nikolov.n...@gmail.com>: > >> Hi Community, >> >> I have a scene where I use light lobes (shader based) which seam to work >> well. The lights are attached through osg::LightSource and are moved by >> osg::MatrixTransforms. All works well. Part of the scene is rendered by a >> third party rendering engine and I see the lights flicker there, this part >> is litten when I zoom in or pan, when the eye is static it does not. The >> software allows me to inject my own shaders for the lighting so I use the >> same shader that is proven to work. It is somewhat as losing or changing >> the gl_LightSource (ehm, I know I could use uniforms for this, but it is >> bit of old code) positions on the fly. >> >> Any clue what this zoom in flicker could be? Any idea is welcome >> >> -- >> trajce nikolov nick >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > > -- > -- > С уважением, > Матвеев Константин > Руководитель проекта > +7 (917) 554 44 64 > konstantin.matve...@eligovision.ru > > EligoVision. Интерактивные Технологии > http://www.eligovision.ru > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View::setCameraManipulator
Hi Robert, I'm simply saying that setCameraManipulator should just set the camera manipulator into the view and not also set the node implicitly got from the scene data: it is not his responisibility. And that's not always a desirable behavior since in other part of the code the node should be already set to a node different from the root scene data. That means setCameraManipulator overrides the node I have already set to the manipulator (and I don't want the home position to be computed again too). In my case I'm switching manipulators and I want that each manipulator maintains its node reference and not been reset by the call setCameraManipulator. So from my point of view it's up to the programmer to set the proper node to a manipulator. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58568#58568 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting flickering
Hello Trajce!!! LightSource may be traversed after some Drawables. This may be the problem! Try to move LightSource node upper to be traversed first. KOS 2014-02-25 0:44 GMT+04:00 Trajce Nikolov NICK : > Hi Community, > > I have a scene where I use light lobes (shader based) which seam to work > well. The lights are attached through osg::LightSource and are moved by > osg::MatrixTransforms. All works well. Part of the scene is rendered by a > third party rendering engine and I see the lights flicker there, this part > is litten when I zoom in or pan, when the eye is static it does not. The > software allows me to inject my own shaders for the lighting so I use the > same shader that is proven to work. It is somewhat as losing or changing > the gl_LightSource (ehm, I know I could use uniforms for this, but it is > bit of old code) positions on the fly. > > Any clue what this zoom in flicker could be? Any idea is welcome > > -- > trajce nikolov nick > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- -- С уважением, Матвеев Константин Руководитель проекта +7 (917) 554 44 64 konstantin.matve...@eligovision.ru EligoVision. Интерактивные Технологии http://www.eligovision.ru ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
