Erwan Daniel
Erwan Daniel

Reputation: 1537

OpenSceneGraph plugin not included in Conan?

I'm trying to do simple mesh viewer using OpenSceneGraph and I want to use Conan for dependencies. The compilation is working well in both debug and release mode (I'm compiling on Windows for now with msvc toolchain).

As soon as I try to load any kind of mesh, the osgDB::readNodeFiles just fail. Looks like the plugin are not linked to the final binary. I checked in the Conan's package, the plugin list of .lib exists and are supposed to be linked I guess. What could I miss ?

There is my conanfile.txt :

[requires]
    openscenegraph/3.6.5
[generators]
cmake

The CMakeLists.txt is also straightforward :

cmake_minimum_required(VERSION 3.17)

# Set a default build type if none was specified
set(default_build_type "Release")
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    message(STATUS "Setting build type to '${default_build_type}' as none was specified.")
    set(CMAKE_BUILD_TYPE "${default_build_type}" CACHE
            STRING "Choose the type of build." FORCE)
    # Set the possible values of build type for cmake-gui
    set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
            "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

set(PROJECT_NAME 3D_radio)

project(${PROJECT_NAME})

if(EXISTS ${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
    include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
    conan_basic_setup()
    set(CMAKE_CONFIGURATION_TYPES ${CONAN_CONFIGURATION_TYPES})
else()
    message(WARNING "The file conanbuildinfo.cmake doesn't exist, you have to run conan install first")
endif()

# get all source files
file(GLOB all_SRCS
        "include/*.h"
        "source/*.cpp"
        )

# add executable and addShader libraries
add_executable(${PROJECT_NAME} ${all_SRCS} source/main.cpp include/main.h)

target_include_directories(${PROJECT_NAME} PRIVATE
        include
        ${CONAN_INCLUDE_DIRS}
        )

target_link_libraries(${PROJECT_NAME} ${CONAN_LIBS})

And the code is also very simple :

int main(int argc, char **argv) {
    // use an ArgumentParser object to manage the program arguments.
    osg::ArgumentParser arguments(&argc,argv);

    // read the scene from the list of file specified commandline args.
    osg::ref_ptr<osg::Node> loadedModel = osgDB::readNodeFiles(arguments);

    // if not loaded assume no arguments passed in, try use default mode instead.
    if (!loadedModel) loadedModel = osgDB::readNodeFile("cow.osgt");

    // if no model has been successfully loaded report failure.
    if (!loadedModel)
    {
        std::cout << arguments.getApplicationName() <<": No data loaded" << std::endl;
        return 1;
    }
}

The console output :

C:\...\cmake-build-release\bin\program.exe C:\...\first.obj
C:\...\cmake-build-release\bin\program.exe: No data loaded
Error reading file C:\...\first.obj: read error (Could not find plugin to read objects from file "C:\...\first.obj".)
Error reading file cow.osgt: read error (Could not find plugin to read objects from file "cow.osgt".)

I have no problem to open those files in Paint 3D for example. So I know they are correct. The problem looks to come from linking. Any idea ?

Upvotes: 0

Views: 422

Answers (2)

Neelabh Mam
Neelabh Mam

Reputation: 310

The "plugin list of .lib" which you highlighted are, unlike static libs, import libraries which will introduce a dynamic DLL dependency in the final link. The plugin DLLs still have to be present somewhere from where the linker can then load them off, at runtime. OSG plugins are typically loaded relative to the value of OSG_LIBRARY_PATH env variable. Setting this to the folder holding the, say "osgPlugins-3.6.5" directory, should successfully load the plugins.

SET OSG_LIBRARY_PATH=C:\TOOLS\vcpkg\installed\x64-windows\debug\plugins\

Few things which could still break this are: Debug/Release plugins mismatch and some spurious space in the OSG_LIBRARY_PATH env variable, like this one (logged via SET OSG_NOTIFY_LEVEL=DEBUG)

FindFileInPath() : trying C:\TOOLS\vcpkg\installed\x64-windows\debug\plugins\  \osgPlugins-3.6.5\osgdb_osgd.dll

The space above was present in the OSG_LIBRARY_PATH env

Upvotes: 0

Erwan Daniel
Erwan Daniel

Reputation: 1537

I found the solution. I'm compiling statically the program, the plugins are linked to the final binary but the plugin registry look for a dynamic library (osgdb_obj.dll for example).

If you have the same problem, you have to register manually the plugin :

USE_OSGPLUGIN(obj)
USE_GRAPHICSWINDOW() // and you may want this to get a window

Upvotes: 0

Related Questions