Hi Justim,
The OverlayData exists to enable the OverlayNode to work multi-thread,
multi-graphics context, so you'll end up with one OverlayData and
associated data structures per cull traversal (effectively per
camera).
While working robustly in mult-thread, multi-channel machines is great
feature... as you have found out it does mean that some of the
internal working a more hidden. This moves the question on how do you
expose functionality to the end that user that they might find useful.
OverlayData is created dynamically on demand, so isn't something you
can querry at setup time, so even if you did have public access to
OverlayData they list containing the active ones will be empty until
you start rendering...
So... settings like osg::Texture filtering would need to be read by
OverlayData from setting provided at the parent OverlayNode. Other
parameters would also be desirable to control as well. The shaders in
question would be good one. OverlayNode is pretty bleeding edge so
its design and implementation are both open to evolution in response
to the needs of the community. Be prepared to get under the bonnet to
help out though ;-)
Robert.
On 6/29/07, KSpam <[EMAIL PROTECTED]> wrote:
I use osgSim::OverlayNode extensively in my application; however, I require
that MIN_FILTER and MAG_FILTER are set to NEAREST instead of LINEAR.
With OSG 1.2, I accomplished this by creating a new class "FalseColorOverlay"
that subclasses osgSim::OverlayNode. In the constructor, I could simply call
the following (since the _texture member was protected):
_texture->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::NEAREST);
_texture->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::NEAREST);
The new OverlayNode capability in OSG 2.0 is wonderful; however, it also put a
stop to my workaround. Now, the texture is wrapped in an OverlayData struct
that can only be accessed through a private method "getOverlayData". If
getOverlayData were a protected method, I would be able to accomplish my
porting to OSG 2.0 with the following code snippet:
// Not pretty but functional
void FalseColorOverlay::traverse (osg::NodeVisitor& nv)
{
osgUtil::CullVisitor* cv = dynamic_cast<osgUtil::CullVisitor*>(&nv);
if (cv)
{
// Force the filters to NEAREST
OverlayData& overlayData = getOverlayData(cv);
overlayData._texture->setFilter(osg::Texture2D::MIN_FILTER,
osg::Texture2D::NEAREST);
overlayData._texture->setFilter(osg::Texture2D::MAG_FILTER,
osg::Texture2D::NEAREST);
}
// Traverse as normal now ...
osgSim::OverlayNode::traverse(nv);
}
My solution would require a small patch to the API. Additionally, it does not
look eloquent. Are there any suggestions for alternative solutions?
Thank you for your time.
Respectfully,
Justin
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
