A 3D Mapping Engine & SDK for OpenSceneGraph.

Overview
Comments
  • osgEarth 3.1 and osgearth_conv appear to have trouble processing terrain file

    osgEarth 3.1 and osgearth_conv appear to have trouble processing terrain file

    Using osgEarth 3.1 on Windows 10 64-bit, running the utility osgearth_conv.exe on my terrain tif file yields the following results...

    **osgearth_conv --in driver GDALElevation --in url osgETerrain.tif --out driver MBTilesElevation --out filename osgETerrain.mbtiles --out format tif --threads 12 [osgEarth] [GDAL] Layer "GDALElevation" Resolution= 0.020232x0.00833333 max=0.00833333 [osgEarth] [GDAL] Layer "GDALElevation" osgETerrain.tif max Data Level: 7 [osgEarth] [TileLayer] Layer "GDALElevation" [srs=WGS 84, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [no cache] [osgEarth] [MBTiles] Layer "MBTilesElevation" Database does not exist; attempting to create it. [osgEarth] [osgearth_conv] FROM: { "GDALElevation" : { "driver" : "GDALElevation", "url" : "osgETerrain.tif" } }

    [osgEarth] [osgearth_conv] TO: { "MBTilesElevation" : { "driver" : "MBTilesElevation", "filename" : "osgETerrain.mbtiles", "format" : "tif", "profile" : { "num_tiles_high_at_lod_0" : 1.0, "num_tiles_wide_at_lod_0" : 2.0, "srs" : "+proj=longlat +datum=WGS84 +no_defs", "vdatum" : {}, "xmax" : "180", "xmin" : "-180", "ymax" : "90", "ymin" : "-90" } } }

    [osgEarth] [osgearth_conv] Calculated max level = 7 Working... [osgEarth] Starting 12 threads [osgEarth] 484 tasks in the queue. 487/248 196% complete, 0m10s projected, 0m-10s remaining Complete. Time = 21.2 seconds.**

    When I run the osgearth_conv.exe utility on the same tif file built using osgEarth 3.0, I get the same output except the following is reported...

    42346/42346 100% complete

    which should be the correct output.

    If I use the osgETerrain.mbtiles built with the osgearth_conv.exe from 3.1 in my earth file, I get the following output with osgearth_viewer...

    osgearth_viewer --window 100 100 1280 1024 maps_round_all.earth --sky [osgEarth] [Capabilities] Capabilities: [osgEarth] [Capabilities] osgEarth Version: 3.1.0 build 101 [osgEarth] [Capabilities] OSG Version: 3.6.5 [osgEarth] [Capabilities] GDAL Version: 3.2.2 [osgEarth] [Capabilities] GEOS Version: 3.9.1 [osgEarth] [Capabilities] GPU Vendor: NVIDIA Corporation [osgEarth] [Capabilities] GPU Renderer: GeForce GTX 1660 Ti/PCIe/SSE2 [osgEarth] [Capabilities] GL/Driver Version: 4.6.0 NVIDIA 462.30 [osgEarth] [Capabilities] GL Core Profile: no [osgEarth] [Map] Map profile is: [srs=WGS84, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [osgEarth] [FileSystemCache] Opened a filesystem cache at "C:\ThriveLite\cache" [osgEarth] [Map] [cache=FileSystemCache; policy=read-write; bin=no] [osgEarth] [Layer] Layer "BATHY" Cache bin is [BATHY-6d23530d] [osgEarth] [GDAL] Layer "BATHY" Resolution= 0.0166667x0.0166667 max=0.0166667 [osgEarth] [GDAL] Layer "BATHY" C:\ThriveLiteMaps\earth.tif max Data Level: 6 [osgEarth] [TileLayer] Layer "BATHY" [srs=WGS 84, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [cache=FileSystemCache; policy=read-write; bin=yes] [osgEarth] [MBTiles] Layer "DTED0" Got levels from database 0, 7 [osgEarth] [MBTiles] Layer "DTED0" Profile = [srs=unknown, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [osgEarth] [MBTiles] Layer "DTED0" Min=0, Max=7, format=tif [osgEarth] [MBTiles] Layer "DTED0" Bounds = SW=179.975,-90 NE=-179.977,84.0042, SRS=WGS84 [osgEarth] [TileLayer] Layer "DTED0" [srs=unknown, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [no cache] [osgEarth] [engine_rex] Activated! [osgEarth] [TerrainResources] Texture unit 0 reserved for Terrain Color [osgEarth] [TerrainResources] Texture unit 1 reserved for Terrain Elevation [osgEarth] [TerrainResources] Texture unit 2 reserved for Terrain Normals [osgEarth] [TerrainResources] Texture unit 3 reserved for Terrain Parent Color [osgEarth] [TerrainResources] Texture unit 4 reserved for Terrain Land Cover [osgEarth] [RexTerrainEngineNode] Creating 2 root keys. [osgEarth] [MapNodeHelper] Activating logarithmic depth buffer (vertex-only) on main camera [osgEarth] [SimpleSkyNode] Using O'Neil atmospheric lighting [osgEarth] [MapNode] Added extension "sky_simple" [osgEarth] [JobArena] Arena OE.JobArena[]: thread 912 started. [osgEarth] [JobArena] Arena OE.JobArena[]: thread 19996 started.

    There is no terrain data being displayed in the osgearth_viewer (or it is being displayed at the lowest level of detail). Loading the "osgETerrain.tif" file also shows no terrain using osgEarth 3.1. The same tif file works perfectly fine in osgEarth 3.0 using its osgearth_viewer.

    I wasn't able to attach the tif file here but I do have it if you need it for testing.

    The attached text file shows the dt0 files that comprise the tif elevation file...

    osgETerrain.txt

    support 
    opened by keince 24
  • thread safety: use osgDB::readRef*File() in place of osgDB::read*File

    thread safety: use osgDB::readRef*File() in place of osgDB::read*File

    See https://github.com/openscenegraph/OpenSceneGraph/commit/dd996a328979614d7c6b5778b2e4f9c8af37ecfd

    That fix is in OSG since 3.5.1 and osgEarth was never adapted to do something similar.

    I think it explains why I am seeing bursts of file not found errors when using the mp engine.

    I did a quick grep and found ~70 problematic uses of osgDB::read*File() But only a few are in core osgEarth files. I'll try to submit a PR for those.

    Questions:

    • I guess it is not acceptable to switch to using osgDB::readRef*File as this would make it mandatory to use osg 3.5.1 or up ?
    • What would be an acceptable way to make it conditional ?
    opened by filnet 21
  • (GDAL3/PROJ6) ModelSymbol are not loaded vertically to the terrain (on polygons and lines)!

    (GDAL3/PROJ6) ModelSymbol are not loaded vertically to the terrain (on polygons and lines)!

    Hi, I an running on the lates master osgEarth (26/03/202), and I am facing some troubles in loading trees on polygon shapefile (same with lines, but points are ok). my problem is that the trees are loaded inclined (not vertical to terrain) as in the image.

    Capture

    my code is as follow:

            OGRFeatureSource* data = new OGRFeatureSource();
            data->setURL(path.toStdString());
            data->options().buildSpatialIndex() = true;
            data->open();
            Style style;
            style.setName("parks");
    
            ModelSymbol* model = style.getOrCreate<ModelSymbol>();
            model->url()->setLiteral(modelPath);
            model->placement() = model->PLACEMENT_RANDOM;
            model->density() = densite;
            model->scale() = scale;
    
            AltitudeSymbol* alt = style.getOrCreate<AltitudeSymbol>();
            alt->clamping() = alt->CLAMP_TO_TERRAIN;
            //alt->clampingResolution() = 0;
            RenderSymbol* render = style.getOrCreate<RenderSymbol>();
            render->transparent() = true;
            render->minAlpha() = 0.15f;
            FeatureDisplayLayout layout;
            layout.tileSizeFactor() = tilesize;
            layout.addLevel(FeatureLevel(minRange, maxRange, "parks"));
            FeatureModelLayer* layer = new FeatureModelLayer();
            layer->setFeatureSource(data);
            layer->options().layout() = layout;
            layer->setStyleSheet(new StyleSheet());
            layer->getStyleSheet()->addStyle(style);
            map->addLayer(layer);
    

    Any help please to fix the angle of the trees to be normal to the terrain? Thanks.

    defect build-issue 
    opened by MCA4213 19
  • Screenspace Layout - crash / Windows

    Screenspace Layout - crash / Windows

    osgEarth crash on screenspace layouting. osgEarth master (050b17a6e51f49b13c8c9dcf029677877cd90cfd), osg 3.6.2 GLCore, VS 2017:

     	osg157-osgd.dll!osg::Shader::PerContextShader::compileShader(osg::State & state) Line 729	C++
     	osg157-osgd.dll!osg::Shader::compileShader(osg::State & state) Line 398	C++
     	osg157-osgd.dll!osg::Program::compileGLObjects(osg::State & state) Line 195	C++
     	osgEarthd.dll!osgEarth::VirtualProgram::apply(osg::State & state) Line 1488	C++
     	osg157-osgd.dll!osg::State::applyAttribute(const osg::StateAttribute * attribute, osg::State::AttributeStack & as) Line 1185	C++
    >	osg157-osgd.dll!osg::State::applyAttributeList(std::map<std::pair<enum osg::StateAttribute::Type,unsigned int>,osg::State::AttributeStack,std::less<std::pair<enum osg::StateAttribute::Type,unsigned int> >,std::allocator<std::pair<std::pair<enum osg::StateAttribute::Type,unsigned int> const ,osg::State::AttributeStack> > > & attributeMap, const std::map<std::pair<enum osg::StateAttribute::Type,unsigned int>,std::pair<osg::ref_ptr<osg::StateAttribute>,unsigned int>,std::less<std::pair<enum osg::StateAttribute::Type,unsigned int> >,std::allocator<std::pair<std::pair<enum osg::StateAttribute::Type,unsigned int> const ,std::pair<osg::ref_ptr<osg::StateAttribute>,unsigned int> > > > & attributeList) Line 1911	C++
     	osg157-osgd.dll!osg::State::apply(const osg::StateSet * dstate) Line 704	C++
     	osgEarthd.dll!`anonymous namespace'::DeclutterDraw::renderLeaf(osgUtil::RenderLeaf * leaf, osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 753	C++
     	osgEarthd.dll!`anonymous namespace'::DeclutterDraw::drawImplementation(osgUtil::RenderBin * bin, osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 713	C++
    

    PerContextShader is corrupt:

    
      | Name | Value | Type
    -- | -- | -- | --
    ◢ | pcs | 0x000001a02261c1a0 {_shader=0xdddddddddddddddd {_type=??? _shaderFileName={...} _shaderSource={...} ...} ...} | osg::Shader::PerContextShader *
      | ▶ osg::Referenced | {_observerSet={_ptr=0xdddddddddddddddd } _refCount={_value=-572662307 } } | osg::Referenced
      | ▶ _shader | 0xdddddddddddddddd {_type=??? _shaderFileName={...} _shaderSource={...} ...} | const osg::Shader *
      | ▶ _extensions | {_ptr=0xdddddddddddddddd {contextID=??? glVersion=??? glslLanguageVersion=??? ...} } | osg::ref_ptr<osg::GLExtensions>
      | _glShaderHandle | 3722304989 | unsigned int
      | ▶ _defineStr | <Error reading characters of string.> | std::basic_string<char,std::char_traits<char>,std::allocator<char> >
      | _needsCompile | true (221) | bool
      | _isCompiled | true (221) | bool
      | _contextID | 3722304989 | const unsigned int
    
    

    void Program::compileGLObjects( osg::State& state ) const ... _shaderList[i]:

      | Name | Value | Type
    -- | -- | -- | --
    ▶ | [osg::Shader] | {_type=VERTEX (35633) _shaderFileName="" _shaderSource="#version 330\n#pragma vp_name       ClipPlane.glsl\n#pragma vp_entryPoint oe_ClipPlane_VS\n#pragma vp_location   vertex_view\n#pragma vp_order      last\n#pragma import_defines(OE_CLIPPLANE_NUM)\nuniform ma... ...} | osgEarthd.dll!osg::Shader
    ▶ | osg::Object | {_name="oe_ClipPlane_VS" _dataVariance=UNSPECIFIED (2) _userDataContainer=0x0000000000000000 <NULL> } | osg::Object
      | _type | VERTEX (35633) | osg::Shader::Type
    ▶ | _shaderFileName | "" | std::basic_string<char,std::char_traits<char>,std::allocator<char> >
    ▶ | _shaderSource | "#version 330\n#pragma vp_name       ClipPlane.glsl\n#pragma vp_entryPoint oe_ClipPlane_VS\n#pragma vp_location   vertex_view\n#pragma vp_order      last\n#pragma import_defines(OE_CLIPPLANE_NUM)\nuniform ma... | std::basic_string<char,std::char_traits<char>,std::allocator<char> >
    ▶ | _shaderBinary | {_ptr=0x0000000000000000 <NULL> } | osg::ref_ptr<osg::ShaderBinary>
    ▶ | _codeInjectionMap | { size=0 } | std::multimap<float,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<float>,std::allocator<std::pair<float const ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >
      | _shaderDefinesMode | USE_SHADER_PRAGMA (0) | osg::Shader::ShaderDefinesMode
    ▶ | _shaderDefines | { size=1 } | std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
    ▶ | _shaderRequirements | { size=0 } | std::set<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
    ▶ | _programSet | { size=12 } | std::set<osg::Program *,std::less<osg::Program *>,std::allocator<osg::Program *> >
    ◢ | _pcsList | {_array={ size=2 } } | osg::buffered_value<osg::ref_ptr<osg::Shader::ShaderObjects> >
      | ◢ _array | { size=2 } | std::vector<osg::ref_ptr<osg::Shader::ShaderObjects>,std::allocator<osg::ref_ptr<osg::Shader::ShaderObjects> > >
      | [capacity] | 2 | __int64
      | ▶ [allocator] | allocator | std::_Compressed_pair<std::allocator<osg::ref_ptr<osg::Shader::ShaderObjects> >,std::_Vector_val<std::_Simple_types<osg::ref_ptr<osg::Shader::ShaderObjects> > >,1>
      | ▶ [0] | {_ptr=0x0000000000000000 <NULL> } | osg::ref_ptr<osg::Shader::ShaderObjects>
      | ▶ [1] | {_ptr=0x0000000000000000 <NULL> } | osg::ref_ptr<osg::Shader::ShaderObjects>
      | ▶ [Raw View] | {...} | std::vector<osg::ref_ptr<osg::Shader::ShaderObjects>,std::allocator<osg::ref_ptr<osg::Shader::ShaderObjects> > >
    
    

    _pcsList has entries with NULL!

    I think it's the same issue on MacOSX, but different crash location: https://github.com/gwaldron/osgearth/issues/1160

    opened by remoe 17
  • packager: bad seams when tiling multiple source files

    packager: bad seams when tiling multiple source files

    Reference: http://forum.osgearth.org/problems-of-edges-with-adjacent-terrain-DEM-td7579093.html

    Also may be the same issue: http://forum.osgearth.org/help-about-the-gap-when-zoom-in-td7388499.html#a7579128

    defect 
    opened by gwaldron 17
  • Cannot draw Line in Android/iOS

    Cannot draw Line in Android/iOS

    As the title says. We have successfully build osgEarth on iOS and Android. but still have some problems, such as the line could not be drawn. We used the same code as the visual studio project as below to draw a line from New York to Tokyo.

    `

        Geometry* path = new LineString();
        path->push_back( osg::Vec3d(-74, 40.714, 0) );   // New York
        path->push_back( osg::Vec3d(139.75, 35.68, 0) ); // Tokyo
    
        Feature* pathFeature = new Feature(path, geoSRS);
        pathFeature->geoInterp() = GEOINTERP_GREAT_CIRCLE;
    
        Style pathStyle;
        pathStyle.getOrCreate<LineSymbol>()->stroke()->color() = Color::White;
        pathStyle.getOrCreate<LineSymbol>()->stroke()->width() = 1.0f;
        pathStyle.getOrCreate<LineSymbol>()->stroke()->smooth() = true;
        pathStyle.getOrCreate<LineSymbol>()->tessellationSize() = 75000;
        pathStyle.getOrCreate<PointSymbol>()->size() = 8;
        pathStyle.getOrCreate<PointSymbol>()->fill()->color() = Color::Red;
        pathStyle.getOrCreate<PointSymbol>()->smooth() = true;
        pathStyle.getOrCreate<AltitudeSymbol>()->clamping() = AltitudeSymbol::CLAMP_TO_TERRAIN;
        pathStyle.getOrCreate<AltitudeSymbol>()->technique() = AltitudeSymbol::TECHNIQUE_GPU;
        pathStyle.getOrCreate<RenderSymbol>()->depthOffset()->enabled() = true;
    
        //OE_INFO << "Path extent = " << pathFeature->getExtent().toString() << std::endl;
    
        pathNode = new FeatureNode(pathFeature, pathStyle);
        annoGroup->addChild( pathNode );
    
        LabelNode* label = new LabelNode("Great circle path", labelStyle);
        label->setPosition(GeoPoint(geoSRS,-170, 61.2));
        labelGroup->addChild(label);
    

    `

    It will be very appreciated if anyone could help.

    opened by EdYao 15
  • VirtualProgram - glLinkProgram - crash / MacOSX - only

    VirtualProgram - glLinkProgram - crash / MacOSX - only

    Crashes on MacOSX (Core Profile) latest master with OSG 3.6.2 with osgEarth d55b14d5f1507a93afdda479a6e2de62a1cd77a5 / MP-engine and REX-engine

    0   libGLProgrammability.dylib    	0x00007fff33dd6fe8 BitSetSetRangeEqualsInternal + 184
    1   libGLProgrammability.dylib    	0x00007fff33dd721b BitSetSetSizeEquals + 83
    2   libGLProgrammability.dylib    	0x00007fff33dd71af BitSetSetRangeEquals + 40
    3   libGLProgrammability.dylib    	0x00007fff33da33a2 phase2ProcessLValue + 628
    4   libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    5   libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    6   libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    7   libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    8   libGLProgrammability.dylib    	0x00007fff33da26a7 phase2AddDef + 251
    9   libGLProgrammability.dylib    	0x00007fff33da2e32 phase2ProcessRawCall + 394
    10  libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    11  libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    12  libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    13  libGLProgrammability.dylib    	0x00007fff33da2802 phase2Process + 56
    14  libGLProgrammability.dylib    	0x00007fff33da26a7 phase2AddDef + 251
    15  libGLProgrammability.dylib    	0x00007fff33d2f386 glpASTMergePhase2 + 482
    16  libGLProgrammability.dylib    	0x00007fff33d565cf glpLinkProgram + 267
    17  libGLProgrammability.dylib    	0x00007fff33d7643d ShLink + 202
    18  GLEngine                      	0x00007fff348fe32d gleLinkProgram + 1348
    19  GLEngine                      	0x00007fff34851083 glLinkProgramARB_Exec + 292
    20  libosg.3.6.2.dylib            	0x000000010a83ed9f osg::Program::PerContextProgram::linkProgram(osg::State&) + 2895
    21  libosgEarth.2.9.0.dylib       	0x000000010aeb54ae osgEarth::VirtualProgram::apply(osg::State&) const + 2190
    22  libosg.3.6.2.dylib            	0x000000010a8735c4 osg::State::applyAttribute(osg::StateAttribute const*, osg::State::AttributeStack&) + 52
    23  libosg.3.6.2.dylib            	0x000000010a86c265 osg::State::applyAttributeList(std::__1::map<std::__1::pair<osg::StateAttribute::Type, unsigned int>, osg::State::AttributeStack, std::__1::less<std::__1::pair<osg::StateAttribute::Type, unsigned int> >, std::__1::allocator<std::__1::pair<std::__1::pair<osg::StateAttribute::Type, unsigned int> const, osg::State::AttributeStack> > >&, std::__1::map<std::__1::pair<osg::StateAttribute::Type, unsigned int>, std::__1::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int>, std::__1::less<std::__1::pair<osg::StateAttribute::Type, unsigned int> >, std::__1::allocator<std::__1::pair<std::__1::pair<osg::StateAttribute::Type, unsigned int> const, std::__1::pair<osg::ref_ptr<osg::StateAttribute>, unsigned int> > > > const&) + 853
    24  libosg.3.6.2.dylib            	0x000000010a869a8b osg::State::apply(osg::StateSet const*) + 891
    25  libosgEarth.2.9.0.dylib       	0x000000010ae3a27f (anonymous namespace)::DeclutterDraw::drawImplementation(osgUtil::RenderBin*, osg::RenderInfo&, osgUtil::RenderLeaf*&) + 479
    26  libosgUtil.3.6.2.dylib        	0x000000010a4b77f3 osgUtil::RenderBin::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) + 83
    
    opened by remoe 15
  • V8 Build broken with latest release

    V8 Build broken with latest release

    I used trunk revision 13387 of v8 which builds fine (it is not the latest trunk update). But the latest trunk does not compile, it seems the api of v8 has changed. Also the latest tagged release (3.19) does not compile.

    Which version of v8 should we use? It is not mentioned in the docs (or I missed that point).

    defect 
    opened by beachwalker 15
  • Build issue with VCPKG on Linux (was: 3.3: stack smashing detected)

    Build issue with VCPKG on Linux (was: 3.3: stack smashing detected)

    Hi, I have just upgraded osgearth-3.2 to the 3.3 release. It has been compiled and built using cmake without any issues but when I run any of the utils in build/bin I got the following message (and it crashes):

    ❯ ../build/bin/osgearth_viewer boston.earth ObjectWrapperManager::addWrapper(): 'osg::DummyObject' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::ClampableNode' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::InstallCameraUniform' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::DrapeableNode' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::Util::DrawInstanced::InstanceGeometry' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::StringObject' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::LightGL3' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::MaterialGL3' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::LineGroup' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::LineDrawable' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::PointGroup' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::PointDrawable' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::Text' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::TextureBuffer' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::VirtualProgram' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::FeatureSourceIndexNode' already exists. ObjectWrapperManager::addWrapper(): 'osgEarth::PlaceNode' already exists. *** stack smashing detected ***: terminated zsh: abort ../build/bin/osgearth_viewer boston.earth

    The code that I developed using the libraries crashes as well... Is it already a known issue? Does it have a quick fix?

    I ran "osgearth_version --caps" to provide some helpful (I hope) insights about my setup. Here's the output:

    [osgEarth] [Registry] Note: GDAL_DATA environment variable is not set [osgEarth] [Capabilities] Capabilities: [osgEarth] [Capabilities] osgEarth Version: 3.3.0 build 135 [osgEarth] [Capabilities] OSG Version: 3.6.5 [osgEarth] [Capabilities] GDAL Version: 3.0.4 [osgEarth] [Capabilities] GEOS Version: 3.8.0 [osgEarth] [Capabilities] GPU Vendor: NVIDIA Corporation [osgEarth] [Capabilities] GPU Renderer: NVIDIA GeForce RTX 3070 Laptop GPU/PCIe/SSE2 [osgEarth] [Capabilities] GL/Driver Version: 4.6.0 NVIDIA 515.65.01 (460) [osgEarth] [Capabilities] GL Core Profile: no

    Thank you very much for your help!

    build-issue 
    opened by elbarto1980 14
  • -changes for API changes with regards latest SilverLining

    -changes for API changes with regards latest SilverLining

    Hi Glenn,

    Here's a patch against the latest SilverLining that take into account the API changes mentioned here:

    https://sundog-soft.com/2018/10/important-api-updates-in-silverlining-5-30/

    Its minor, but important

    opened by pprabhu78 13
  • Failed to compile in debug mode

    Failed to compile in debug mode

    The lastest version of the cmake macro "MACRO(LINK_INTERNAL TRGTNAME)" in CMakeModules\OsgEarthMacroUtils.cmake prevents from compiling in debug mode with MSVC.

    cmake.exe -G "Visual Studio 15 2017 Win64"
      -DCMAKE_BUILD_TYPE:STRING=Debug 
      -DOpenSceneGraph_DEBUG:BOOL=ON
      -DWIN32_USE_MP:BOOL=ON
      -DOSGEARTH_EMBED_GIT_SHA:BOOL=ON
      -DCMAKE_INSTALL_PREFIX:PATH="C:\dist"
      -DBUILD_OSGEARTH_EXAMPLES:BOOL=ON
      -DCURL_INCLUDE_DIR:PATH=C:\dist/include
      -DCURL_LIBRARY:FILEPATH=C:\dist/lib/libcurld.lib
      -DDYNAMIC_OSGEARTH:BOOL=ON
      -DGDAL_INCLUDE_DIR:PATH=C:\dist/include
      -DGDAL_LIBRARY:FILEPATH=C:\dist/lib/gdal_i.lib
      -DGEOS_INCLUDE_DIR:PATH=C:\dist/include
      -DGEOS_LIBRARY:FILEPATH=C:\dist/lib/geos.lib
      -DSQLITE3_INCLUDE_DIR:PATH=C:\dist/include
      -DSQLITE3_LIBRARY:FILEPATH=C:\dist/lib/sqlite3.lib
      -DOSG_DIR:PATH=C:\dist
      -DCMAKE_PREFIX_PATH:PATH=%QTDIR%
      -DOSGEARTH_INSTALL_SHADERS:BOOL=ON
      -DTHIRD_PARTY_DIR:PATH=C:\dist
      -DZLIB_INCLUDE_DIR:PATH=C:\dist/include
      -DZLIB_LIBRARY:FILEPATH=C:\dist/lib/zlibd.lib
      ..
    
    CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
    Please set them or make sure they are set and tested correctly in the CMake files:
    OPENTHREADS_LIBRARY
        linked by target "osgEarth" in directory C:/osgearth/osgearth-64165316974f99dbce6addf2f731a52d42df33c9/src/osgEarth
        linked by target "osgEarth" in directory C:/osgearth/osgearth-64165316974f99dbce6addf2f731a52d42df33c9/src/osgEarth
        linked by target "osgEarthAnnotation" in directory C:/osgearth/osgearth-64165316974f99dbce6addf2f731a52d42df33c9/src/osgEarthAnnotation
    ...
    
    opened by moulinfr 13
  • ImGui: Build fixes against gcc 4.8.5

    ImGui: Build fixes against gcc 4.8.5

    We are receiving reports that SIMDIS SDK (building against osgEarth) is failing to build on a C++11 compiler. Though RHEL-7's native gcc 4.8.5 isn't exactly C++11, it is close. After this set of changes in osgEarth and a few other changes in SIMDIS SDK, we can get a successful build.

    opened by emminizer 0
  • Issue with ModelNode

    Issue with ModelNode

    Hi, I want to load a 3d object model with ModelNode. I use this code:

    Style style;
    auto model = style.getOrCreate<ModelSymbol>();
    auto object = osgDB::readNodeFile(filePath.toLatin1().data());
    
    auto matrix = new osg::MatrixTransform();
    osg::Matrixd mat;
    mat.makeScale(10);
    matrix->setMatrix(mat);
    matrix->addChild(object);
    
    model->setModel(matrix);
    
    auto locator = new ModelNode(mapNode, style);
    root->addChild(locator);
    

    The 3d model was loaded successfully but seems some lights are missed. I attached screenshot of the loaded model and what should be: What is the problem?

    Osg Org

    The object(.osg) file: https://drive.google.com/file/d/1627ekOpxbB87A525L24n-mCUFK8KVOY6/view?usp=sharing

    The object(.obj, .mtl) file: Zielanweise.zip

    support 
    opened by drspam1991 2
  • strange behavior using highlight_shader from osgearth_pick app

    strange behavior using highlight_shader from osgearth_pick app

    I'm using osgearh v3.3 build with GL3 profile. Here's the capabilities : oe_cap

    In my app I have several nodes that tag themselves through the Registry like so : osgEarth::Registry::objectIndex()->tagNode

    I have a custom mouse "picker" that interact with the nodes that are tagged, and it got the same shader that is available in osgearth_pick application.

    The problem I have is : when I have all the node in the frustum, it's all OK. But when certain nodes are not visible, then the shader does not hightlight the right node. Even hough the indexes are still correct. I've got the same behavior if I orient the camera certain ways. Sometimes it hightlights multiple nodes.

    I struggle to find explanation for this behavior, maybe you can ?

    Thanks

    opened by quentinBdr 0
  • DrapeableNode bug for transparent geometries

    DrapeableNode bug for transparent geometries

    Hi,

    I need to integrate the byte stream coming from a radar. The flow is mapped on a transparency level, on which I then, through a shader, I go to apply a color.

    After defining the geometry and the coordinates of the texture, I had to read a bytebuffer for which I then create an image:

    osg::Image* RadarVideoSectorObject::getImageObject() {
    	osg::ref_ptr<osg::Image> _image = new osg::Image();
    	_image->allocateImage(getCellsPerSweep(), getSweeps(), 1, GL_ALPHA, GL_UNSIGNED_BYTE);
    	_image->setImage(getCellsPerSweep(), getSweeps(), 1, GL_ALPHA, GL_ALPHA, GL_UNSIGNED_BYTE, getData(), osg::Image::AllocationMode::USE_NEW_DELETE);
    	return _image.release();
    }
    

    So, starting with this alpha-based image, I generated the texture:

    void RadarVideoSectorObject::initTexture() {
    	_texture = new osg::Texture2D(getImageObject());
    	_texture->setDataVariance(osg::Object::DYNAMIC);
    	_texture->setResizeNonPowerOfTwoHint(false);
    	_texture->setUnRefImageDataAfterApply(false);
    	_texture->setFilter(osg::Texture::MIN_FILTER, osg::Texture::NEAREST);
    	_texture->setFilter(osg::Texture::MAG_FILTER, osg::Texture::NEAREST);
    	_texture->setWrap(_texture->WRAP_S, _texture->CLAMP);
    	_texture->setWrap(_texture->WRAP_T, _texture->CLAMP);
    }
    

    Finally, I applied the shaders to the geometry:

    void RadarVideoSectorObject::applyTextureShader() {
    	osg::ref_ptr<VirtualProgram> _program;
    	if (!_program.valid())
    	{
    		static Threading::Mutex mutex;
    		mutex.lock();
    		if (_program.valid() == false)
    		{
    			_program = new VirtualProgram;
    			_program->setInheritShaders(false);
    			_program->setFunction("oe_ImageOverlay_VS", imageVS, ShaderComp::LOCATION_VERTEX_MODEL);
    			_program->setFunction("oe_Output_FS", imageOutFS, ShaderComp::LOCATION_FRAGMENT_OUTPUT);
    		}
    		mutex.unlock();
    	}
    	optional<float> _alpha = 20.0f;
    	_uniformAfterglow = new osg::Uniform("time", _afterglow);
    	_uniformSweepColor = new osg::Uniform("sweepColor", _sweepColor);
    	for (osg::ref_ptr <osg::Geometry> geometry : geometryList) {
    		osg::StateSet *ss = geometry->getOrCreateStateSet();
    		ss->setAttributeAndModes(_program.get(), osg::StateAttribute::ON);
    		ss->addUniform(new osg::Uniform("oe_ImageOverlay_tex", 0));
    		ss->addUniform(new osg::Uniform("oe_ImageOverlay_alpha", *_alpha));
    		ss->addUniform(_uniformAfterglow);
    		ss->addUniform(_uniformSweepColor);
    		ss->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
    		ss->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
    		ss->setMode(GL_BLEND, osg::StateAttribute::ON);
    		ss->setAttributeAndModes(new osg::BlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA));
    		ss->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
    	}
    }
    

    Here are the two shaders:

    const char* imageVS =
    "#version " GLSL_VERSION_STR "\n"
    "out vec2 oe_ImageOverlay_texcoord; \n"
    "void oe_ImageOverlay_VS(inout vec4 vertex) { \n"
    "    oe_ImageOverlay_texcoord = gl_MultiTexCoord0.st; \n"
    "} \n";
    
    const char* imageOutFS =
    "#version " GLSL_VERSION_STR "\n"
    "in vec2 oe_ImageOverlay_texcoord; \n"
    "uniform sampler2D oe_ImageOverlay_tex; \n"
    "uniform float oe_ImageOverlay_alpha; \n"
    "uniform float time; \n"
    "uniform vec3 sweepColor; \n"
    "void oe_Output_FS(inout vec4 color) { \n"
    "vec4 texcolor = texture(oe_ImageOverlay_tex, oe_ImageOverlay_texcoord); \n"
    "    color = texture2D(oe_ImageOverlay_tex, oe_ImageOverlay_texcoord);\n"
    "	 color.a = color.a - clamp(time,0.0,1.0); \n"	
    "	 color.rgb = sweepColor; \n"	
    "	 gl_FragColor = color; \n"
    "} \n";
    

    At the end of it all, I had to insert the geometry into a node that clamped to the ground, so digging through the code, I found the DrapeableNode!

    Everything works as expected, except that the DrapeableNode seems to do a basic interpolation between the color I pass to the shader and a gray.

    In fact, I modified the shader, removing my color, and gray appears inside the texture.

    Looking at the api, I found at this link http://docs.osgearth.org/en/2.10/user/features.html?highlight=drape#draping a possible bug for the Drape: Unexpected blending artifacts may result from draping many transparent geometries atop each other.

    Hope someone can help me ....

    Greetings

    opened by marcoma9023 0
  • about ImageLayer Block!!!

    about ImageLayer Block!!!

    I have two Imagelayers both added to the map and one of them is slow to access which is causing my other layer to block! How can I make them not affect each other

    osgEarth::XYZImageLayer* layer1= new osgEarth::XYZImageLayer(); layer1->setURL("http://c.tile.opencyclemap.org/cycle/{z}/{x}/{y}.png");// layer1->setProfile(osgEarth::Profile::create("spherical-mercator")); m_map->addLayer(layer1)

    osgEarth::XYZImageLayer* layer2= new osgEarth::XYZImageLayer(); layer2->setURL("***************************"); layer2->setProfile(osgEarth::Profile::create("spherical-mercator")); m_map->addLayer(layer2)

    If layer1 access is slow, layer2 access is slow

    support 
    opened by HerryJessica 6
Releases(osgearth-3.3)
Open Source Routing Engine for OpenStreetMap

██▒ █▓ ▄▄▄ ██▓ ██░ ██ ▄▄▄ ██▓ ██▓ ▄▄▄ ▓██░ █▒▒████▄ ▓██▒ ▓██░ ██▒▒████▄ ▓██▒ ▓██▒ ▒████▄ ▓██ █▒░▒██ ▀█▄

valhalla 2.2k Nov 25, 2022
CMake scripts for building OpenSceneGraph third party libraries.

osg-3rdparty-cmake CMake scripts for building OpenSceneGraph third party libraries. These scripts can be used to build third party libraries from sour

Björn Blissing 156 Nov 18, 2022
OpenSceneGraph git repository

ABI Tracker Introduction Welcome to the OpenSceneGraph (OSG). For up-to-date information on the project, in-depth details on how to compile and run li

OpenSceneGraph git repository 2.6k Nov 27, 2022
SSL_SLAM2: Lightweight 3-D Localization and Mapping for Solid-State LiDAR (mapping and localization separated) ICRA 2021

SSL_SLAM2 Lightweight 3-D Localization and Mapping for Solid-State LiDAR (Intel Realsense L515 as an example) This repo is an extension work of SSL_SL

Wang Han 王晗 333 Nov 17, 2022
MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library is a C software library that is widely regarded by developers as the gold standard open source SDK for elliptic curve cryptography (ECC).

MIRACL What is MIRACL? Multiprecision Integer and Rational Arithmetic Cryptographic Library – the MIRACL Crypto SDK – is a C software library that is

MIRACL 517 Nov 22, 2022
MIRACL Cryptographic SDK: Multiprecision Integer and Rational Arithmetic Cryptographic Library is a C software library that is widely regarded by developers as the gold standard open source SDK for elliptic curve cryptography (ECC).

MIRACL What is MIRACL? Multiprecision Integer and Rational Arithmetic Cryptographic Library – the MIRACL Crypto SDK – is a C software library that is

MIRACL 517 Nov 22, 2022
This repo contains Direct3D 9, Direct3D 10, a few Direct3D 11, and DirectSound C++ samples from the legacy DirectX SDK updated to build using the Windows 10 SDK and the Microsoft.DXSDK.D3DX NuGet package

DirectX SDK Legacy Samples This repo contains Direct3D 9, Direct3D 10, a few Direct3D 11, and DirectSound samples that originally shipped in the legac

Chuck Walbourn 44 Nov 21, 2022
Enabling services on your device 79 Nov 13, 2022
The Raspberry Pi Pico SDK (henceforth the SDK) provides the headers, libraries and build system necessary

The Raspberry Pi Pico SDK (henceforth the SDK) provides the headers, libraries and build system necessary to write programs for the RP2040-based devices such as the Raspberry Pi Pico in C, C++ or assembly language.

Raspberry Pi 1.8k Nov 24, 2022
The Gecko SDK (GSDK) combines all Silicon Labs 32-bit IoT product software development kits (SDKs) based on Gecko Platform into a single, integrated SDK.

Silicon Labs Gecko SDK (GSDK) The Gecko SDK (GSDK) combines Silicon Labs wireless software development kits (SDKs) and Gecko Platform into a single, i

Silicon Labs 139 Nov 17, 2022
C++ game engine inspired by quake. Modern rendering and quake mapping tool integration.

Nuake Feel free to join the discord server for updates: What is it Nuake is a game engine written from scratch by myself. It is not meant to be a end-

Antoine Pilote 25 Oct 17, 2022
Unreal Engine Plugin to wrap Nuitrack SDK ( skeleton tracking solution by 3DiVi )

Nuitrack for Unreal Engine Unreal Engine plugin to bridge Nuitrack. Nuitrack is a middleware to provide 3d skeleton tracking solution using a depth se

Ayumu Nagamatsu 11 Nov 10, 2022
An Unreal Engine 4 SDK generator using SdkGenny

UE4Genny UE4Genny is an SDK generator for Unreal Engine 4 games. It aims to provide a functional SDK that requires little to no editing after generati

null 90 Nov 21, 2022
macOS 12.0 Monterey SDK for Mach engine

macOS 12.0 Monterey SDK for Mach Engine This repository contains native system binary files required to build Mach Engine for macOS, from any host OS.

Hexops 5 Sep 8, 2022
ASN intelligence information (IP to ASN mapping) collected and distributed in open source and transparent way

ASN Intelligence The main goal of this project to retrieve information required to map IP address to ASN number in open source and transparent way. Wh

Pavel Odintsov 60 Jun 27, 2021
A WiFi mapping companion app for Valetudo

Valeronoi (Valetudo + Voronoi) is a companion for Valetudo for generating WiFi signal strength maps. It visualizes them using a Voronoi diag

Christian F. Coors 194 Nov 23, 2022
Pole-like Objects Mapping and Long-Term Robot Localization in Dynamic Urban Scenarios

Long Term Localization Pole-like Objects Mapping and Long-Term Robot Localization is an algorithm that makes robot or UAV locate itself in Dynamic Urb

Networked Robotics and Sytems Lab 89 Nov 15, 2022
LIO-SAM: Tightly-coupled Lidar Inertial Odometry via Smoothing and Mapping

A real-time lidar-inertial odometry package. We strongly recommend the users read this document thoroughly and test the package with the provided dataset first.

Tixiao Shan 2.1k Nov 22, 2022
LVI-SAM: Tightly-coupled Lidar-Visual-Inertial Odometry via Smoothing and Mapping

LVI-SAM This repository contains code for a lidar-visual-inertial odometry and mapping system, which combines the advantages of LIO-SAM and Vins-Mono

Tixiao Shan 1.1k Nov 25, 2022