Strange behavior of osgEarth::DrapeableNode

classic Classic list List threaded Threaded
3 messages Options
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Strange behavior of osgEarth::DrapeableNode

This post was updated on .
Hello,

I'm experiencing a strange effect on an infinitely scrolled Mercator projection. My scene graph is set up as the following:
   osg::Group* root
          |________ osg::MatrixTransform*
          |                          |________________ osgEarth::MapNode*
          |________ osg::MatrixTransform*
          |                          |________________ osgEarth::MapNode*
          |________ osg::MatrixTransform*
                                     |________________ osgEarth::MapNode*

The osgEarth::MapNode* under each osg::MatrixTransform is the same address. The Matrix Transforms are being used similarly as the osgearth / src / applications / osgearth_infinitescroll / osgearth_infinitescroll.cpp example. The extent of the osgEarth::MapNode* is just 180W to 180E.

My colleague and I have been having performance issues regarding using many osgEarth::Annotation::FeatureNodes, however we came up with the idea of stripping the points from the osgEarth::Geometry that gets created from the osgEarth::GeometryFactory that we were using to create the osgEarth::Feature::Features. Then, we also needed the ability to drape the osg::Geometry that we ended up making ourselves from the osgEarth::Geometry's createVec3dArray(). After all of this effort, everything appeared to be working.

The actual main issue: When we add an osg::Geode containing our osg::Geometry as a child to an osgEarth::DrapeableNode everything appears correctly. However, with the infinite scrolling matrix transforms, if zoomed far enough out, we should be able to see 3 copies of the osgEarth::MapNode and everything on them should be 100% identical. However, that is not the case. Either on the left or the right matrix transforms, the custom osg::Geode that we made is not visible, but only on the center matrix transform. We noticed if we called on the osgEarth::DrapeableNode::setDrapingEnabled(false) then we could see it again on all three. Our camera zoom will be in such a way that we should be able to only see one dateline border between matrix transforms at a time, either the leftmost extent of -180W or the rightmost extent of 180W.

When we create an osgEarth::Annotation::FeatureNode with an osgEarth::Features::Feature whose style has draping enabled on the AltitudeSymbol, it is still visible when on the off of the main center matrix transform. We checked the osgEarth::GeometryBuilder and noticed if that symbology is set, an osgEarth::DrapeableNode is created and added to the FeatureNode's _compiled internal representation. Is there something else we need to do to make it work, like it is for the osgEarth::FeatureNode?

Thanks for any help!
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior of osgEarth::DrapeableNode

Images for more context:

Center osg::MatrixTransform looking correct

And once we simulate the node going over -180 degrees and back to 180 degrees we move it all the way back around on the center matrix to make it look as though it "seamlessly" moves across the dateline without weird osgEarth Geometry drawing issues. However, on the left and right matrix transforms it will appear like this (the circular geometry is under the osgEarth::DrapeableNode and disappears unless looking at the right side of the center matrix):

left side osg::MatrixTransform issue with osgEarth::DrapeableNode
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: Strange behavior of osgEarth::DrapeableNode

In reply to this post by Blanky
Not every feature in osgEarth works properly when you put the MapNode under a transform. The "infinitescroll" example is really just an implementation concept.

I have another implementation of the idea that uses multiple cameras and a custom manipulator that you can try -- this approach should look correct since there are no transforms. We'll probably replace the infinitescroll example with this one in version 3.0.

https://gist.github.com/gwaldron/bc7d57cbdd6b93c515aae026ab605384



Glenn Waldron / Pelican Mapping