subject:"\[osg\-users\] FrameBufferObject problems on OSG 2.9.11"

Hi Fred,

On Fri, May 27, 2011 at 1:12 PM, Fred Smith osgfo...@tevs.eu wrote:
 Will this issue likely be addressed in the near future? I guess only somebody 
 relatively experienced with the OSG code base can dig into this.

 I can test the code quite extensively as I have routines that process a lot 
 of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there 
 is no minor leak with that release either.

I really don't know what is amiss and your modified version
osggeometry.cpp I find just plain confusing.  I can't start testing
something that I don't under is supposed to do in the first and why.
What you've provide as a test case just doens't make sense to me, I
can't work why you'd do what you are trying to do in this way.  I
can't dive in on topic that I have no grasp of.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-27 Thread Fred Smith


robertosfield wrote:
 Hi Fred,
 
 Please try the latest updates to svn/trunk, it may or may not address
 the issues you have seen.  If it doesn't please put together a small
 example that reproduces the problem.
 
 Robert.


robertosfield wrote:
 Hi Fred,
 
 On Fri, May 27, 2011 at 1:12 PM, Fred Smith  wrote:
 
  Will this issue likely be addressed in the near future? I guess only 
  somebody relatively experienced with the OSG code base can dig into this.
  
  I can test the code quite extensively as I have routines that process a lot 
  of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there 
  is no minor leak with that release either.
  
 
 I really don't know what is amiss and your modified version
 osggeometry.cpp I find just plain confusing.  I can't start testing
 something that I don't under is supposed to do in the first and why.
 What you've provide as a test case just doens't make sense to me, I
 can't work why you'd do what you are trying to do in this way.  I
 can't dive in on topic that I have no grasp of.

Run the modified osggeometry.cpp sample and look at the memory usage. There is, 
apparently, a big memory leak. Increase the number of times testRTTCamera() is 
called and you should see the leak even better.
As to why I'm doing what I'm doing, this is to do RTT. I need to do offscreen 
rendering at some point in my application, and for this purpose I'm adding a 
slave camera to my existing viewer, then do my RTT rendering, then dispose of 
the aforementionned camera. It's either that, or I use a separate viewer and do 
the RTT rendering from there.
In both cases I have a memory leak.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39848#39848





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Fred,

On Fri, May 27, 2011 at 2:22 PM, Fred Smith osgfo...@tevs.eu wrote:
 Run the modified osggeometry.cpp sample and look at the memory usage. There 
 is, apparently, a big memory leak. Increase the number of times 
 testRTTCamera() is called and you should see the leak even better.

The modified example is *mess*.  I wouldn't know if it was a memory
leak due to the messy code or an actual bug in the OSG.

 As to why I'm doing what I'm doing, this is to do RTT. I need to do offscreen 
 rendering at some point in my application, and for this purpose I'm adding a 
 slave camera to my existing viewer, then do my RTT rendering, then dispose of 
 the aforementionned camera. It's either that, or I use a separate viewer and 
 do the RTT rendering from there.
 In both cases I have a memory leak.

Off screen rendering is nothing unusual, but convoluteed means of
doing it aren't.

Please think about isolating one problem at a time and providing a
clean code example, telling me just to run an example that I have
already reviewed and decided it's too convulteed to know what going is
of no help to me.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-27 Thread Fred Smith

Attached is a cleaned up, less messy version of the repro.

testRTTCamera() shows off the leak with offscreen rendering using a slave camera

testLeak() shows off the GraphicsContext leak.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39855#39855



/* OpenSceneGraph example, osggeometry.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the Software), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils

#include osgDB/ReadFile
#include osgDB/WriteFile

#include osgGA/TrackballManipulator

#include osgViewer/Viewer

#include osg/Math

#include iostream

// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent.  This demo uses the OpenGL red book diagram of different 
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives.  The OpenSceneGraph 
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also 
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls.  Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!

// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene.  osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen. 
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().


struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const 
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout  \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};

// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;

osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
 
std::coutstd::endl;
}

osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();

// following are separate blocks for creating POINTS, LINES, LINE_STRIP, LINE_LOOP, POLYGON, QUADS,
// QUAD_STRIP, TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitives. An image of these primitives
// is provided in the distribution: OpenSceneGraph-Data/Images/primitives.gif.


// create POINTS
{
// create Geometry object to store all the vertices and points primitive.
osg::Geometry* pointsGeom = new osg::Geometry();

// create a Vec3Array and add to it all my coordinates.
// Like all the *Array variants (see include/osg/Array) , Vec3Array is derived from both osg::Array 
// and std::vector.  osg::Array's are reference counted and hence sharable,
// which std::vector provides all the convenience, flexibility and robustness
// of the most popular of all STL containers.
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-1.02168, -2.15188e-09, 0.885735));
vertices-push_back(osg::Vec3(-0.976368, -2.15188e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.873376, 9.18133e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.836299, -2.15188e-09, 0.885735));

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-27 Thread Nan WANG

this FBO issue will influence on QuadBuffer rendering?I got some quad buffer 
problem...

... 

Thank you!

Cheers,
Nan

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39857#39857





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Nan,

On Fri, May 27, 2011 at 3:09 PM, Nan WANG nan.c...@gmail.com wrote:
 this FBO issue will influence on QuadBuffer rendering?I got some quad buffer 
 problem...

QuadBuffer stereo is totally unrelated to FBO's.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Fred,

On Fri, May 27, 2011 at 2:57 PM, Fred Smith osgfo...@tevs.eu wrote:
 Attached is a cleaned up, less messy version of the repro.

 testRTTCamera() shows off the leak with offscreen rendering using a slave 
 camera

 testLeak() shows off the GraphicsContext leak.

The test code is still rather a mess, especially the testRTTCamera() -
this *really* isn't how you should do RTT.  To test the two code paths
I had to introduce use of osg::ArgumentParser and make it an option to
run either testRTTCamera or testLeak.  I renamed the file fbotest and
a CmakeLists.txt both of which are attached,

I run both tests :

  fbotest --testRTT

And

  fbotest

And both run without problems and without memory growth, there both
seem fine, despite be pretty dire ways to drive the OSG, both seem to
not cause any problems.

I can't really say whether you have ever seen an actual OSG bug, given
the code you have provided I'd suspect that the convolted way of doing
RTT would easily have problems that would lead bugs in your own code.
Feel free to use tools to debug your application.

Robert.
cmake_minimum_required(VERSION 2.6)

PROJECT(fbotest)

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgViewer)

SET(SOURCES
fbotest.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(fbotest ${SOURCES})

TARGET_LINK_LIBRARIES(fbotest ${OSG_LIBRARY} ${OSGVIEWER_LIBRARY} 
${OPENTHREADS_LIBRARY})
/* OpenSceneGraph example, osggeometry.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the Software), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils

#include osgDB/ReadFile
#include osgDB/WriteFile

#include osgGA/TrackballManipulator

#include osgViewer/Viewer

#include osg/Math

#include iostream

// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent.  This demo uses the OpenGL red book diagram of different 
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives.  The OpenSceneGraph 
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also 
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls.  Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!

// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene.  osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen. 
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().


struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const 
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout  \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};

// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;

osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
 
std::coutstd::endl;
}

osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();

// following are separate blocks for

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-19 Thread J.P. Delport

Hi Fred,

sorry, I don't have time at the moment to check your code. I just
remember from past experience and bug reports to NVidia that OSG does
not reuse FBOs for new cameras, so it's quite possible one can run out
with the video driver complaining/crashing. The limits were also
different for Windows vs Linux.

At the time Robert created osgmemorytest app to show the problem to NVidia.

What does this do on your machine?

osgmemorytest --fbo 1024x768

cheers
jp

On 18/05/11 09:59, Fred Smith wrote:

Hi,

Here is a repro of the slave camera problem (the original problem, not the
bounding box stuff).

Increase the number of testRTTCamera() iterations to see the problem better.

It seems there is something wrong with respects to how GL objects are released,
as the program is stuck after a large number of iterations.

Cheers,
Fred

Attached file: modified osggeometry.cpp source code.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39493#39493

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-19 Thread Fred Smith

Hi J.P.,

I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39526#39526





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-19 Thread J.P. Delport


OK, missed that it's a recent regression.

jp

On 19/05/11 09:26, Fred Smith wrote:

Hi J.P.,

I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39526#39526





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-18 Thread Fred Smith

Hi,

Here is a repro of the slave camera problem (the original problem, not the 
bounding box stuff).

Increase the number of testRTTCamera() iterations to see the problem better.

It seems there is something wrong with respects to how GL objects are released, 
as the program is stuck after a large number of iterations.

Cheers,
Fred

Attached file: modified osggeometry.cpp source code.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39493#39493



/* OpenSceneGraph example, osggeometry.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the Software), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils

#include osgDB/ReadFile
#include osgDB/WriteFile

#include osgGA/TrackballManipulator

#include osgViewer/Viewer

#include osg/Math

#include iostream

// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent.  This demo uses the OpenGL red book diagram of different 
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives.  The OpenSceneGraph 
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also 
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls.  Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!

// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene.  osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen. 
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().


struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const 
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout  \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};

// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;

osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
 
std::coutstd::endl;
}

class CBCallback : public osg::Drawable::ComputeBoundingBoxCallback
{
public:
CBCallback()
	{
	}

virtual osg::BoundingBox computeBound(const osg::Drawable drawable) const
{
return _boundingBox;
}
protected:
/*mutable*/ osg::BoundingBox _boundingBox;
};


osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();

// following are separate blocks for creating POINTS, LINES, LINE_STRIP, LINE_LOOP, POLYGON, QUADS,
// QUAD_STRIP, TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitives. An image of these primitives
// is provided in the distribution: OpenSceneGraph-Data/Images/primitives.gif.


// create POINTS
{
// create Geometry object to store all the vertices and points primitive.
osg::Geometry* pointsGeom = new osg::Geometry();

// create a Vec3Array and add to it all my coordinates.
// Like all the *Array variants (see include/osg/Array) , Vec3Array is derived from both osg::Array 
// and std::vector.  osg::Array's are reference counted and hence sharable,
// which std::vector

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Robert,

I have a serious, massive memory leak in the trunk (updated this morning at 
around 10am UK time). I haven't tried with previous releases yet.

The following code leaks memory in a very important manner. Put this code 
within a while (true) { testLeak(); } block and you should see memory usage 
climbing fast. I'm testing on a Windows XP 32-bit system. I tried multiple 
Nvidia driver versions, just to be sure I had the same results.


Code:
void testLeak()
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();

osg::ref_ptrosg::DisplaySettings ds = new osg::DisplaySettings();

osg::ref_ptrosg::GraphicsContext::Traits traits = new 
osg::GraphicsContext::Traits(ds.get());

traits-width = 64;
traits-height = 64;
traits-pbuffer = true;

// This probably is the offending line
osg::ref_ptrosg::GraphicsContext gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());
}



This problem is making my life difficult at the moment as I do not have a 
reliable way of doing a large amount of RTT.

This method for doing RTT using a separate pbuffer context is subject to a 
memory leak. The other method using an ASBOLUTE_RF slave camera is also causing 
some troubles. I am working on a repro to illustrate the latter. I would 
appreciate any feedback on the above mentioned issue.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39457#39457





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Robert,

I am a bit puzzled as the second problem I am having at the moment yields a 
very different behavior when isolated out in a small repro.

This time I get an assertion.

Attached is a modified osggeometry.cpp file that triggers the assertion I'm 
talking about. The assertion is raised when addSlave() is called.

This issue might be by design, though. Not sure.


Code:
osg::Camera *createRTTCamera(osgViewer::Viewer viewer)
{
osg::ref_ptrosg::Camera slaveCamera = new osg::Camera();

slaveCamera-setClearColor(osg::Vec4(0, 0, 0, 1)); // initialize alpha 
to 1
slaveCamera-setClearMask(GL_COLOR_BUFFER_BIT);

osg::Matrixd projMatrix;
projMatrix.makeOrtho(0.0, (double)1, 0.0, (double)1, -1.0, 1.0);
slaveCamera-setProjectionMatrix(projMatrix);

slaveCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);

osg::ref_ptrosg::Viewport viewport = new osg::Viewport(0, 0, 64, 64);
slaveCamera-setViewport(viewport.get());

osg::Matrixd viewMatrix;
slaveCamera-setViewMatrix(viewMatrix);

slaveCamera-setRenderOrder(osg::Camera::PRE_RENDER);
slaveCamera-setAllowEventFocus(false);

slaveCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
slaveCamera-setCullingMode(osg::CullSettings::NO_CULLING);

osg::ref_ptrosg::Camera masterCamera = viewer.getCamera();
slaveCamera-setGraphicsContext(masterCamera-getGraphicsContext());

return slaveCamera;
}

void testRTTCamera(osgViewer::Viewer viewer)
{
int oldNodeMask = viewer.getCamera()-getNodeMask();

viewer.getCamera()-setNodeMask(0);

osg::ref_ptrosg::Camera camera = createRTTCamera(viewer);
viewer.addSlave(camera.get(), false);
viewer.frame();

viewer.removeSlave(0);

viewer.getCamera()-setNodeMask(oldNodeMask);
}

void main(void)
{
osgViewer::Viewer viewer;

viewer.setUpViewInWindow(10, 10, 640, 480);
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);

// add model to viewer.
viewer.setSceneData( root );

viewer.realize();

// Call this method to test the problem mentioned in the current message, 
i.e. the slave camera issue. An assertion is raised when addSlave() is called. 
Why?
testRTTCamera(viewer);

// Use this code to test the problem mentioned in my previous thread, eg. 
the pbuffer leak issue. Memory usage will skyrocket
//while (true)
//  testLeak();

viewer.run();
}



Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39460#39460



/* OpenSceneGraph example, osggeometry.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the Software), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils

#include osgDB/ReadFile
#include osgDB/WriteFile

#include osgGA/TrackballManipulator

#include osgViewer/Viewer

#include osg/Math

#include iostream

// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent.  This demo uses the OpenGL red book diagram of different 
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives.  The OpenSceneGraph 
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also 
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls.  Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!

// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Same issues with OSG 2.9.10.

Any idea about what's going on?

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39466#39466





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-05-17 Thread Stephan Maximilian Huber

Am 17.05.11 14:44, schrieb Fred Smith:
 Hi Robert,
 
 I am a bit puzzled as the second problem I am having at the moment yields a 
 very different behavior when isolated out in a small repro.
 
 This time I get an assertion.
 
 Attached is a modified osggeometry.cpp file that triggers the assertion I'm 
 talking about. The assertion is raised when addSlave() is called.
 
 This issue might be by design, though. Not sure.
 
 
 Code:
 osg::Camera *createRTTCamera(osgViewer::Viewer viewer)
 {
   osg::ref_ptrosg::Camera slaveCamera = new osg::Camera();
 
   slaveCamera-setClearColor(osg::Vec4(0, 0, 0, 1)); // initialize alpha 
 to 1
   slaveCamera-setClearMask(GL_COLOR_BUFFER_BIT);
 
   osg::Matrixd projMatrix;
   projMatrix.makeOrtho(0.0, (double)1, 0.0, (double)1, -1.0, 1.0);
   slaveCamera-setProjectionMatrix(projMatrix);
   
   slaveCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
   
   osg::ref_ptrosg::Viewport viewport = new osg::Viewport(0, 0, 64, 64);
   slaveCamera-setViewport(viewport.get());
 
   osg::Matrixd viewMatrix;
   slaveCamera-setViewMatrix(viewMatrix);
   
   slaveCamera-setRenderOrder(osg::Camera::PRE_RENDER);
   slaveCamera-setAllowEventFocus(false);
   
 slaveCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
   slaveCamera-setCullingMode(osg::CullSettings::NO_CULLING);
   
   osg::ref_ptrosg::Camera masterCamera = viewer.getCamera();
   slaveCamera-setGraphicsContext(masterCamera-getGraphicsContext());
   
   return slaveCamera;

This will certainly lead to a crash, as slaveCamera gets deconstructed,
as the correpsonding ref_ptr goes out of scope. Try

return slaveCamera.release()

or change the signature of the function to

osg::ref_ptrosg::Camera createRTTCamera(osgViewer::Viewer viewer)

instead.

Can't comment much on the memory-leak issue, though.

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi,

Thanks Stephan, you actually replied to my original message. I have since 
edited it and suggested to concentrate on the leak issue. The other issue I 
have is still under investigation and yes, the code I had originally posted 
(too fast) to illustrate the second issue was incorrect ;)

Thank you!

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39469#39469





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi,

The second issue I had was that by design OSG doesn't assume the bounding box 
of a drawable should be recalculated when setting a computeBoundingBoxCallback 
up on the object.

In other words I was expecting Drawable::_boundingBoxComputed to be set back to 
false when setting the callback. Shouldn't this be done?

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39472#39472





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-04-22 Thread Fred Smith


robertosfield wrote:
 Please try the latest updates to svn/trunk, it may or may not address
 the issues you have seen.  If it doesn't please put together a small
 example that reproduces the problem.
 

I tried the trunk updated about an hour ago and I am still having problems. I 
see the memory usage climbing up, whereas with 2.9.10 things remain stable 
overall. I'll try to come up with a repro unfortunately right now I'm a bit 
swamped.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38727#38727





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Paul,

I have step my step revert files from svn/trunk to the previous
versions in 2.9.10 and finally isolated the changes to
osgViewer/Renderer as being the causes of this regression.

There are number of changes that address different issues in
osgViewer::Renderer so I'll will need carefully revert the changes to
pick out the cause of the problem.  The difficulty in tracking down
this problem is due to the symptoms of the problem being quite removed
from the cause.   Right now I think the most likely cause of the
problem is the changes to how the ICO and the DatabasePager are
managed in the recent version of Renderer.cpp.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Paul,

On Wed, Apr 20, 2011 at 10:48 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
 There are number of changes that address different issues in
 osgViewer::Renderer so I'll will need carefully revert the changes to
 pick out the cause of the problem.  The difficulty in tracking down
 this problem is due to the symptoms of the problem being quite removed
 from the cause.   Right now I think the most likely cause of the
 problem is the changes to how the ICO and the DatabasePager are
 managed in the recent version of Renderer.cpp.

It turns out that the problem wasn't even the changes to Renderer.cpp,
rather improvements to the Renderer reveal a deeper problem with
release of GL objects in the cached rendering backend.  This problem
will have
been lurking for a long time, so I'm a bit suprised we haven't traked
it down before, it's possible the usage combination of using the
render to texture cameras + fbo's in an application that creates and
destroys a series of contexts hasn't been stressed too much in the
past.  It might also be that problems have happened, just we didn't
correctly pick up on the cause.  Either way, the problem is now solved
;-)

What I have done is added releaseGLObjects(State*) implementations in
the FrameBufferObject, RenderBuffer, RenderStageCache, RenderStage and
RenderBin.  This should have been there in the first
place but we clearly overlooked these when the
osg::Object::releaseGLObjects(State*) functionality was introduced a
few years back.

An svn update will fix the problem with the incorrect rendering and
warnings to the console for the example provided, and I suspect a few
other apps out in the wild that have seen problems like this but never
nailed what was the cause.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-04-20 Thread Sergey Polischuk

Hi, Robert

I'm just curious, if this fix will resolve problems with freeing unused gl 
texture objects (f.e. if you call dirtyTextureObject on texture attached to 
camera and resize texture after that texture will create new gl texture object, 
but old is still valid, and it not released on its own with or with 
Texture::flushAllDeletedTextureObjects(...) call, at least on 2.9.9)?

Cheers,
Sergey.

20.04.2011, 15:52, Robert Osfield robert.osfi...@gmail.com:
 Hi Paul,

 On Wed, Apr 20, 2011 at 10:48 AM, Robert Osfield
 robert.osfi...@gmail.com; wrote:

  There are number of changes that address different issues in
  osgViewer::Renderer so I'll will need carefully revert the changes to
  pick out the cause of the problem.  The difficulty in tracking down
  this problem is due to the symptoms of the problem being quite removed
  from the cause.   Right now I think the most likely cause of the
  problem is the changes to how the ICO and the DatabasePager are
  managed in the recent version of Renderer.cpp.

 It turns out that the problem wasn't even the changes to Renderer.cpp,
 rather improvements to the Renderer reveal a deeper problem with
 release of GL objects in the cached rendering backend.  This problem
 will have
 been lurking for a long time, so I'm a bit suprised we haven't traked
 it down before, it's possible the usage combination of using the
 render to texture cameras + fbo's in an application that creates and
 destroys a series of contexts hasn't been stressed too much in the
 past.  It might also be that problems have happened, just we didn't
 correctly pick up on the cause.  Either way, the problem is now solved
 ;-)

 What I have done is added releaseGLObjects(State*) implementations in
 the FrameBufferObject, RenderBuffer, RenderStageCache, RenderStage and
 RenderBin.  This should have been there in the first
 place but we clearly overlooked these when the
 osg::Object::releaseGLObjects(State*) functionality was introduced a
 few years back.

 An svn update will fix the problem with the incorrect rendering and
 warnings to the console for the example provided, and I suspect a few
 other apps out in the wild that have seen problems like this but never
 nailed what was the cause.

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

2011-04-20 Thread Fred Smith

Hi,

I have an application using a single, unique viewer doing occasional RTT by the 
means of an ABSOLUTE_RF slave camera with a distinct scene graph. I had chosen 
a while ago to do my RTT this way and not use a separate context.

I have a tool that pregenerates lots of textures, each texture generation going 
through a cycle of addSlave/removeSlave and distinct scene graoh disposal etc. 
Then, once all textures are generated, I get back to my main loop where 
viewer.frame() is called again. At this very moment, with release 2.9.12 - or 
actually a trunk snapshot somewhere inbetween releases 2.9.12 and 2.9.13 - I 
experience very weird issues where my application stalls quite badly for some 
unexplained reason. Again, this is once it gets past the texture generation and 
back into the main loop with viewer.frame().

I tried a release/debug build (VS2010) and noticed a couple of weird assertions 
with the debug build but only once or twice. Sometimes the computer freezes for 
a little while.

When I saw these messages I decided to try with release 2.9.10. I don't seem to 
have the same problem with this release.
These investigations are not exhaustive yet but I wanted to let you know.

Cheers,
Fred

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=38636#38636





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11

Hi Sergey,

2011/4/20 Sergey Polischuk pol...@yandex.ru:
 I'm just curious, if this fix will resolve problems with freeing unused gl 
 texture objects (f.e. if you call dirtyTextureObject on texture attached to 
 camera and resize texture after that texture will create new gl texture 
 object, but old is still valid, and it not released on its own with or with 
 Texture::flushAllDeletedTextureObjects(...) call, at least on 2.9.9)?

I cannot comment either way as I don't know enough about your specific
usage case.  svn/trunk has a number of fixes of GL object management
that have been made since 2.9.9, the fix I have just checked in
doesn't specically address issues with texture objects, but others
did.

Best I can recommend is try svn/trunk and see if it helps, if it
doesn't put together a small example that reproduces the problem so
that others can look at reproducing the problem.  Most problems of
this nature can only be resolved by having a test cases that fails,
Paul's modified of osgrender was a good example of how to go about
this.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FrameBufferObject problems on OSG 2.9.11