Re: [osg-users] OSG 2.0 Singularity in osgSim::OverlayNode

[KSpam]

Robert,

This fix sounds great!  Thanks for the swift reply.

Justin

On Wednesday 04 July 2007 03:45, Robert Osfield wrote:
 Hi Justin,


 I have now checked in a better approach for determining the
 orientation that avoids the singularity whilst provide far better
 continuity in sideVector axis, the sideVector code now checked in to
 SVN is:

 osg::Vec3d sideVectorLV = lookVector ^ cv-getLookVectorLocal();
 osg::Vec3d sideVectorUP = lookVector ^ cv-getUpLocal();

 osg::Vec3d sideVector = sideVectorLV.length() 
 sideVectorUP.length() ? sideVectorLV :
 sideVectorUP;

 sideVector.normalize();

 This code computes the side vector based on the main cameras
 lookvector and the upvector and then chooses the longest of the the
 two.  When the overlay lookvector is closer to the main cameras look
 vector then the sideVectorUP will be chosen safely avoiding any
 singularity.  The cross over between the two happens at about 45
 degrees and is a seamless hand over - the side vector doesn't ping to
 a new orientation.

 Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] OSG 2.0 Singularity in osgSim::OverlayNode

[KSpam]

There is a singularity in OverlayNode.cpp in the 
traverse_VIEW_DEPENDENT_WITH_ORTHOGRAPHIC_OVERLAY method.  This singularity 
is evident when frustum_axis (line 1463) approaches lookVector (line 1465).  
To resolve this, I added the following code following sideVector.normalize() 
(line 1476):

if (sideVector.length()  1.0)
{
sideVector = osg::Vec3d(1.0, 0.0, 0.0);
}

Is this a reasonable fix?

Thanks,
Justin
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] osgSim::OverlayNode : Porting from OSG 1.2 to 2.0

[KSpam]

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_castosgUtil::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
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/