Is this a known problem? Does anyone know of a workaround? Does anyone
have experience using FrameBufferObjects with multi-thread'ing?
Thanks in advance,
There are limits with the time of threading you can do with cameras
that share the same graphics context - the draw traversals has to be
single threaded for each camera's rendering, this applies to FBO's as
well as normal rendering to a graphics window.
You should be able to still run multi-threaded if you have multiple
graphics contexts, but the osgdistortion example just uses on graphics
context, and multiple FBOs. The example should be able to run
DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext, if it
can't perhaps there is something about the example that isn't thread
safe, I am the author so "should" know, but alas don't recall the
details off the top of my head.
When I get some time I'll change the osgdistortion example to allow
other threading models and see what happens.
> osg-users mailing list
osg-users mailing list
This sounds like the problem I'm having with osgdistortion - on SMP
kernels I'm getting very bad performance. The performance improves if
you accidentally install a non-SMP kernel. Robert suggested a workaround
using FBOs - this seems to work for models up to a certain complexity only.
I don't know a lot about the internals of OSG or 3D - I come at it from
an application point of view, so it might be a red herring. The fact the
we're both working in domes seems too coincidental...
The two problems aren't related, one is a crash in the OSG, the other
(the one you've observed) is poor performance of FBO Cube maps in the