![]() |
Hello,
I'm using osgEarth 2.9 and fairly new to both it and OSG. I have noticed that the SkyNode's SunLight seems to be lighting the MGRS Graticule. I'm not sure if I'm using it incorrectly or if this is intended. Here is an image of the lighting effects. I've increased the line width on the graticule to make it more obvious. ![]() I have tried disabling lighting on the root node of the graticule, which changes nothing: <code> graticule->getOrCreateNode()->getOrCreateStateSet()->setMode(GL_LIGHTING, osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED|osg::StateAttribute::OVERRIDE); </code> I have also tried adding my own light based on the SkyNode's SunLight parameters, but with full intensity on the ambient color (doing this to the SunLight will making the graticule uniformly lit, but this isn't what I want - I want to be able to control the lighting of the graticule separate from the rest of the Earth): <code> osg::Node* node = graticule->getOrCreateNode(); osg::Group* group = node->asGroup(); if (group) { osg::Light* skyLight = mySkyNode->getSunLight(); osg::Light* light = new osg::Light; light->setPosition(skyLight->getPosition()); light->setAmbient(osg::Vec4(1.0, 0.0, 0.0, 1.0)); light->setDiffuse(osg::Vec4(1.0, 0.0, 0.0, 1.0)); light->setConstantAttenuation(1.0f); light->setLinearAttenuation(0.0f); light->setQuadraticAttenuation(0.0f); light->setDirection(osg::Vec3(0.0, 0.0, -1.0)); light->setSpotCutoff(180.0f); light->setSpotExponent(0.0f); light->setLightNum(0); osg::ref_ptr<osg::LightSource> source(new osg::LightSource); osg::StateSet* ss = node->getOrCreateStateSet(); ss->setAttributeAndModes(light, osg::StateAttribute::PROTECTED|osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON); source->setLight(light); group->addChild(source); } </code> Thank you for any help you can offer. I'm busy learning more about OSG and osgEarth trying to figure out where to go next. -Joel |
![]() |
Joel,
osgEarth does not use the fixed-function OpenGL pipeline, so things like GL_LIGHTING will not work. Instead in 2.9 I believe you can use stateSet->setDefine("OE_LIGHTING", ...); In the most recent version (2.10) you can call the utility method GLUtils::setLighting().
Glenn Waldron / Pelican Mapping
|
![]() |
Thank you, Glen. This gets me closer to the desired result. I suspect I'll be taking another look at this when we update to the latest version.
|
![]() |
Hi Glen,
I got this working as desired in 2.9 and then, as expected, we immediately upgraded to 2.10. We are now building osgearth-2.10 against OpenSceneGraph-3.6.3 (previously osgearth-2.9 and OpenSceneGraph-3.4.0). Now we do not see graticules at all in either our application or in the osgearth_graticule sample application. Additionally after upgrading , in our application we were getting a runtime crash in osgUtil::LineSegmentIntersector::Intersect where it was dereferencing a nullptr osg::Drawable* (and this a a child of a MGRSGraticule). I'm suspicious that perhaps we might have a osgearth/osg version mis-match. Where can I find information on which OpenSceneGraph to use for a particular branch/tag of osgEarth? Thanks for you help. -Joel |
![]() |
It should work, are you sure both builds are complete and/or no old dlls in your path? -- Paul Levy : Pelican Mapping On Mon, Jan 28, 2019 at 11:48 AM jlarsen [via osgEarth] <[hidden email]> wrote: Hi Glen, |
![]() |
I built osgEarth from source using the osgearth-2.10 tag. OpenSceneGraph was built by someone else on the team, but I've pulled down the source and will build it locally to verify that as well.
I've just noticed that there is a 2.10 branch as well as osgearth-2.10 tag. Should I sync to the branch instead or stick with the tag? Thank you, -Joel |
![]() |
The 2.10 branch has additional improvements, so I recommend using that.
Glenn Waldron / Pelican Mapping
|
![]() |
Glen, is the 2.10 branch closed to future changes or does it still have active work happening?
Ok, so I've found the issue and a repro. Open any earth file with the sample osgearth_graticule and none of the graticules will render. However, I noticed that they work just fine in the tool osgearth_toc. A little code reading and I was able to see that the issue is that GLUtils::setGlobalDefaults( ... ) was not being called in osgearth_graticule.cpp. Adding that to the sample and our application fixed things right up. I had logged all the osgEarth::notify stuff to a file and don't recall seeing any warnings about that. It might be helpful if there are big warnings if there are defaults that are not set or perhaps they should default to useful values. Thank you, -Joel |
![]() |
Good find!
Do you mind submitting a PR with the fix? Thank you. master: active development within the 2.x framework. 2.10 branch: bug fixes and other compatible upgrades to 2.10 3.0: next generation API, hoping for this to become master later this year.
Glenn Waldron / Pelican Mapping
|
![]() |
Yeah, I'll try to make a PR for that.
Also, in my excitement to see the graticule lines rendering in our application after the first fix, I failed to notice that the labels weren't rendering. Can you think of any changes between 2.9 and 2.10 that might relevant? These are the only kinds of things I'm seeing in the osgEarth::notify logs: [osgEarth] [MGRSGraticule] Empty SQID geom at 55W EV [osgEarth] [Duktape] Loaded duktape JavaScript engine [osgEarth] Loaded ScriptEngine driver "javascript" OK [osgEarth] [StateSetCache] Pruned 0 attributes, 0 statesets [osgEarth] [MapNode] Adding node from layer "" to the scene graph Thanks again, Joel |
![]() |
I've found some information about graticule labels not rendering in our application. UTMLabelEngine::updateLabels returns (false) without calculating any label positions because utmDiff is always failing this test at line 125:
if (utmDiff > 150000) return false; So, I changed that code to an arbitrary higher number that allowed the rest of the updateLabels code to run, yet I still don't see them. I believe I'm on the right track, but would appreciate any insight someone might have familiar with this code. Thank you, Joel |
![]() |
After commenting out #define USE_SCREEN_COORDS in MGRSGraticule.cpp, the labels began rendering again in our application. Does anyone have an idea of why that might be? We are using Qt and have our gl context in a dock widget.
Additionally, there is a problem with using a osgEarth::LineGroup for the group container of lines in MGRS. (origin/2.10 src/osgEarthUtil/MGRSGraticule.cpp:1064). You can see that osg::Group is commented out, was it really ready for this change? This causes a crash when applying an intersection visitor to the earth graph. |
Free forum by Nabble | Edit this page |