Hi Robert,
Sorry for the long Delay.
On Friday 05 June 2009, Robert Osfield wrote:
I've just review these changes and don't feel they are appropriate as
they rely upon the CullVisitor hanging around for the life of the
RenderStage that is being rendered, which is an implicit coupling,
Hi Mathias,
2009/6/10 Mathias Fröhlich m.froehl...@science-computing.de:
By the way, did you know that the same happens for the Drawables, since the
render leafs are cleared in exactly that code path.
So should they also be cleared just past rendering?
I am aware of the rendering backend
Hi Robert,
On Wednesday 10 June 2009, Robert Osfield wrote:
I am aware of the rendering backend retaining it's references to
StateSet and Drawables after the end of the draw dispatch.
Potentially we could add an explicit renderStage + renderGraph
reset/clean() at the end of the draw dispatch
Hi Mathias,
2009/6/3 Mathias Fröhlich m.froehl...@science-computing.de:
The least intrusive one is the following:
Have a vector of ref_ptr's in the cull visitor where the render stages and
render leaf lists are held. This list is filled by the cull visitor and
relesed in the cull visitors
HI Mathias Guy,
On Fri, Jun 5, 2009 at 2:58 PM, Robert Osfieldrobert.osfi...@gmail.com wrote:
What we need is draw traversal itself to take a reference in some way
that it releases it at the end of the frame.
I have just checked into svn/trunk a solution that is only active when
we use
Hi Robert,
I have played with that thing a bit. But without success so far.
The first thought is:
Should the Render Stage have a reference to the camera instead of just a
pointer? Since the RenderStage relies on the Camera being present, this
appears to be the /right/ way to get that.
...
Hi Mathias,
2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de:
Should the Render Stage have a reference to the camera instead of just a
pointer? Since the RenderStage relies on the Camera being present, this
appears to be the /right/ way to get that.
Um not quite as you
On Friday 29 May 2009, Robert Osfield wrote:
Hi Mathias,
2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de:
Should the Render Stage have a reference to the camera instead of just a
pointer? Since the RenderStage relies on the Camera being present, this
appears to be the /right/
Hi Mathias,
2009/5/29 Mathias Fröhlich m.froehl...@science-computing.de:
There is a race between asking the observer_ptr if it is valid and the object
you have no counted reference on being deleted before accessing it.
And there is no atomic way to get a ref_ptr from an observed_ptr without
Hi Guy,
You don't say where you are adding your HUD camera's - to the graphics
window, to the viewer as a slave/separate view or embedded in the
scene graph. For the first two examples setting the data variance to
dynamic won't be sufficient as it's a high level objects that is being
removed -
Hi,
On Thursday 28 May 2009, Robert Osfield wrote:
You don't say where you are adding your HUD camera's - to the graphics
window, to the viewer as a slave/separate view or embedded in the
scene graph. For the first two examples setting the data variance to
dynamic won't be sufficient as
Hi,
I integrated an overlays system into my code that essentially supports multiple
overlays, each having multiple hud items. Each overlay uses an osg::Camera at
its root. All this works very well, with the exception of the following issue:
when I remove the overlay (i.e the root camera) from
Hi,
Here is the call stack for the crash and the code:
[img]CallStack.bmp[/img]
Code:
void RenderStage::draw(osg::RenderInfo renderInfo,RenderLeaf* previous)
{
if (_stageDrawnThisFrame) return;
// push the stages camera so that drawing code can query it
if (_camera)
13 matches
Mail list logo
