DepthOffsetGroup automatic option affecting GeoTransform SRS

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

DepthOffsetGroup automatic option affecting GeoTransform SRS

This post was updated on .
Hey,

I'm not quite sure what the heck is going on here, but I was previously using osg::Depth for mitigating clipping with the ground on both a WGS-84 and Spherical Mercator MapNode. Now, I had issues where on the 3D map stuff was showing behind when rotated, so I added the osgEarth::HorizonCullCallback to anything on the WGS-84 map.

After awhile I realized that the Z-fighting wasn't being alleviated to my satisfaction as it was with the osgEarth::FeatureNode when I used its RenderOptions and what not. For performance reasons we've subclassed an osg::Switch and essentially I turned it into an osgEarth::DepthOffsetGroup. Most of the source code I had to strip due to diamond inheritance between the parent of the osg::Switch and osgEarth::DepthOffsetGroup both being an osg::Group. I essentially reused all of the previous functions that made an osgEarth::DepthOffsetGroup do its thing with the DepthOffsetOptions.

Then I deprecated the use of any and all of the osg::Depth in my code and the osgEarth::HorizonCullCallback in favor of this custom DepthOffsetGroup.

In our program we can spawn a QOpenGLWidget at runtime start and tell it to either be a WGS-84 or spherical merator map. This has always worked. Then we chose to rewrite the map measure tool to work with a treadmilled spherical mercator implementation map to cross datelines effectively. This too worked.

So, now the actual bug or what I think is a bug...
We add an osg::Text to an osgEarth::GeoTransform and that osgEarth::GeoTransform is either added to our custom DepthOffsetSwitch and each of those belong to a singleton WGS-84 MapNode or a spherical-mercator MapNode. On start up it is fine, but if we were to create a new camera that views the same scene graph, then if we add something to the scene graph that the new camera is looking at, it appears to be in a WGS-84 SRS. The text of our measuring tool follows the cursor for measuring the distance of the line we draw and places the distance as the end of the line. This distance looks like it's following a WGS-84 globe - it can go above and below the spherical-mercator MapNode as if it was going aroung a WGS-84 globe, despite the lines drawing just fine.

How do we get this to happen? Well, every single node under our MapNode is parented by one of these DepthOffsetSwitch Frankensteined objects. So essentially, every node is under a DepthOffsetGroup one way or another. If we turn off the osgEarth::DepthOffsetOptions::automatic boolean then it breaks. If we turn the automatic on, it's fine. How could the rendering of the node switch its underlying SRS? This makes no sense, and so long as automatic is on, it works fine. I was under the impression that automatic just set the minRange dynamically (which we checked and it does do that). Something else has to be going on here as far as I know. If there's an obvious reason for this behavior or if this is a bug, it would be greatly appreciated to know.

I guess to reproduce our scenario (Need to test if this basic example produces the behavior, will go make a test example cpp after writing this and upload it later unless it's obvious what's wrong):

1: Make a spherical-mercator MapNode.
2: Create an osg::Text and add it as a child to an osgEarth::Transform whose SRS is set to the above spherical-mercator's GeographicSRS.
3: Create and osgEarth::DepthOffsetGroup whose options turn off the automatic boolean.
4: Add the osgEarth::GeoTransform to the osgEarth::DepthOffsetGroup.
5: Spawn an osgViewer::Viewer with the spherical-mercator MapNode as the scene data.
6: Spawn a new osgViewer::Viewer and set its scene data to the same pointer address as the previous one.
7: Add a new osgEarth::GeoTransform and osg::Text combination to the MapNode.
8: Observe that the first osgEarth::GeoTransform is still correctly rendering.
9: Oberseve the the new osgEarth::GeoTransform is rendering with respect to a WGS-84 SRS while on a second spherical-mercator map's camera.


P.S. After looking into what's different if the automatic options is turned off, is that the Segment analyzer never activates and UpdateUniforms is called without any changes. I don't know if something is wrong with the osg::Uniforms if the projection is different from a WGS-84 implementation. For now, we'll keep automatic on though.
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: DepthOffsetGroup automatic option affecting GeoTransform SRS

Blanky,

This is a lot to parse :) but it sounds like you are sharing a scene graph between two MapNode's with different profiles - one being a geocentric globe and the other being a projected map. Is that right?

It won't work. Generally speaking you will need separate data (separate GeoTransform in this case) for each MapNode. GeoTransform (along with various other elements in osgEarth) will only work with one MapNode (profile) at a time.
Glenn Waldron / Pelican Mapping
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: DepthOffsetGroup automatic option affecting GeoTransform SRS

Glenn, that's what we did. There's  2 singleton mapnodes for each profile such that you can have x cameras views of the singleton projected spherical-mercator scene and y cameras looking at the singleton WGS-84 scene. We essentially have "hooks" that allow a user to seemlessly add something to the map and it will implicitly create two nodes, one for the 2D and the 3D maps. When the user sets the position on the hook it implicitly updates both states for each map type's nodes, giving the illusion of "one" map with many different perspectives. What we learned was that the DepthOffsetGroup code that with Frankensteined onto our Group parents for different unique  things, like text, icon, models, lines, circles, etc., was somehow causing newly spawned maps the behave strangely after pogram creation. After removing the DepthOffsetGroup (which we deprecated use of because RenderBinNumbers solves our z-Fighting implicitly through renderbin sorting and actually conflicted with some of the behavior)  it's all fine now. I'm confused as to how the Uniforms affects the visual interpretation of a node. Maybe I'll take some screens of the weird behavior, although we just removed the code instead that seemed to cause it.