OpenSceneGraph git repository

Build Status Coverity Status Documentation ABI Tracker


Welcome to the OpenSceneGraph (OSG).

For up-to-date information on the project, in-depth details on how to compile and run libraries and examples, see the documentation on the OpenSceneGraph website:

For support subscribe to our public mailing list or forum, details at:

For the impatient, we've included quick build instructions below, these are are broken down is three parts:

  1. General notes on building the OpenSceneGraph
  2. macOS release notes
  3. iOS release notes

If details below are not sufficient then head over to the to the Documentation/GettingStarted and Documentation/PlatformSpecifics sections for more indepth instructions.

Robert Osfield. Project Lead. 26th April 2018.

Section 1. How to build OpenSceneGraph

If you are using the vcpkg dependency manager you can download and install OpenSceneGraph from source with CMake integration using a single command:

vcpkg install osg

The OpenSceneGraph uses the CMake build system to generate a platform-specific build environment. CMake reads the CMakeLists.txt files that you'll find throughout the OpenSceneGraph directories, checks for installed dependencies and then generates files for the selected build system.

If you don't already have CMake installed on your system you can grab it from, use version 2.8.0 or later. Details on the OpenSceneGraph's CMake build can be found at:

Under Unix-like systems (i.e. Linux, IRIX, Solaris, Free-BSD, HP-UX, AIX, macOS) use the cmake or ccmake command-line utils. Note that cmake . defaults to building Release to ensure that you get the best performance from your final libraries/applications.

cd OpenSceneGraph
cmake .
sudo make install

Alternatively, you can create an out-of-source build directory and run cmake or ccmake from there. The advantage to this approach is that the temporary files created by CMake won't clutter the OpenSceneGraph source directory, and also makes it possible to have multiple independent build targets by creating multiple build directories. In a directory alongside the OpenSceneGraph use:

mkdir build
cd build
cmake ../OpenSceneGraph
sudo make install

Under Windows use the GUI tool CMakeSetup to build your VisualStudio files. The following page on our wiki dedicated to the CMake build system should help guide you through the process:

Under macOS you can either use the CMake build system above, or use the Xcode projects that you will find in the OpenSceneGraph/Xcode directory. See release notes on macOS CMake build below.

For further details on compilation, installation and platform-specific information read "Getting Started" guide:

Section 2. Release notes on macOS build, by Eric Sokolowski et al.

There are two ways to compile OpenSceneGraph under macOS. The recommended way is to use CMake to generate Xcode project files and then use Xcode to build the library. The default project will be able to build Debug or Release libraries, examples, and sample applications.

The alternative is to build OpenSceneGraph from the command line using make or ninja using the instructions for Unix-like systems above.

Here are some key settings to consider when using CMake:

  • BUILD_OSG_EXAMPLES - By default this is turned off. Turn this setting on to compile many great example programs.
  • CMAKE_OSX_ARCHITECTURES - Xcode can create applications, executables, libraries, and frameworks that can be run on more than one architecture. Use this setting to indicate the architectures on which to build OSG. x86_64 is the only supported value for OS versions > 10.7.
  • OSG_BUILD_APPLICATION_BUNDLES - Normally only executable binaries are created for the examples and sample applications. Turn this option on if you want to create real macOS .app bundles. There are caveats to creating .app bundles, see below.
  • OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX - By default macOS uses the imageio plugin instead of the plugins for the individual file types (e.g. jpg, gif, etc.) to load image file types. The imageio plugin can handle all popular file formats through the ImageIO framework.
  • OSG_WINDOWING_SYSTEM - You have the choice to use Cocoa, Carbon, or X11 when building applications on macOS. Cocoa is the default for OS versions >= 10.5. Carbon and X11 are no longer actively supported, either by Apple or the OSG community.


The example programs when built as application bundles only contain the executable file. They do not contain the dependent libraries as would a normal bundle, so they are not generally portable to other machines. They also do not know where to find plugins. An environmental variable OSG_LIBRARY_PATH may be set to point to the location where the plugin .so files are located. OSG_FILE_PATH may be set to point to the location where data files are located. Setting OSG_FILE_PATH to the OpenSceneGraph-Data directory is very useful when testing OSG by running the example programs.

Many of the example programs use command-line arguments. When double-clicking on an application (or using the equivalent "open" command on the command line) only those examples and applications that do not require command-line arguments will successfully run. The executable file within the .app bundle can be run from the command-line if command-line arguments are needed.

Section 3. Release notes on iOS build, by Thomas Hogarth

With CMake 3.11, XCode 9.4 and the iOS sdk 11.4 installed you can generate an iOS XCode project using the following command line:

export THIRDPARTY_PATH=/path/to/3rdParty
-DCURL_INCLUDE_DIR:PATH="$THIRDPARTY_PATH/curl-ios-device/include" \
-DCURL_LIBRARY:PATH="$THIRDPARTY_PATH/curl-ios-device/lib/libcurl.a" \
-DFREETYPE_INCLUDE_DIR_freetype2:PATH="$THIRDPARTY_PATH/freetype-ios-universal/include/freetype" \
-DFREETYPE_INCLUDE_DIR_ft2build:PATH="$THIRDPARTY_PATH/freetype-ios-universal/include" \
-DFREETYPE_LIBRARY:PATH="$THIRDPARTY_PATH/freetype-ios-universal/lib/libFreetype2.a" \
-DTIFF_INCLUDE_DIR:PATH="$THIRDPARTY_PATH/tiff-ios-device/include" \
-DTIFF_LIBRARY:PATH="$THIRDPARTY_PATH/tiff-ios-device/lib/libtiff.a" \
-DGDAL_INCLUDE_DIR:PATH="$THIRDPARTY_PATH/gdal-ios-device/include" \

Be sure to set the THIRDPARTY_PATH to the path containing your thirdparty dependencies. Set IPHONE_SDKVER to the version of the iOS sdk you have installed, in this instance 11.4. IPHONE_VERSION_MIN controls the deployment sdk used by xcode, and lastly set OPENGL_PROFILE to the version of GLES you want to use.

Once this completes an XCode project will have been generated in the osg root folder. Open the generated Xcode project, select the example_osgViewerIPhone target. In 'General' tab set a development team.

Once this is done you should be able to build and deploy the example_osgViewerIPhone target on your device.

  • openmw SEGV with OSG 3.6.3

    openmw SEGV with OSG 3.6.3

    openmw issue - >

    openmw engine crash with signal 11 if is used latest stable OSG.

    crashlog :

    openmw community bisected commit which caused this problem to:

  • [Fermi/NV390.87 only?] newly generated VAO having same GL name as a deleted one can lead to crash

    [Fermi/NV390.87 only?] newly generated VAO having same GL name as a deleted one can lead to crash

    When a vao is deleted and a new one is regenerated, they may have the same name and so pass as the same for the active check in State::bindVertexArrayObject and crashes Driver policy dependant: with nv390.87 vao name deleted is reused right away on next glGenVertexArrays _On Ubuntu NVIDIA 390.87/GT440 GT440 apitrace Crash doesn't happens with Mesa 18.0.5/Intel Chipset (trace : names doesnt seems to be reused right away)

    To reproduce use the following code (if you need a sample dataset use my test sample ) and run it with such a command line : OSG_VERTEX_BUFFER_HINT=VAO exename BIGCITY.ive --remove 2 --add 1

    NB: with OSG_VERTEX_BUFFER_HINT=VBO it doesn't lead to crash

    #include <osgUtil/MeshOptimizers>
    #include <osgGA/TrackballManipulator>
    #include <osgGA/FirstPersonManipulator>
    #include <osgViewer/Viewer>
    #include <osgViewer/ViewerEventHandlers>
    #include <osgDB/ReadFile>
    class GeomLoaderCB : public  osg::NodeCallback
        int _thresremoval; int _nbaddedatatime;
        std::list<osg::ref_ptr<osg::Geometry> > _geoms;
        GeomLoaderCB(int thresremoval=1, int nbaddedatatime=1):_nbaddedatatime(nbaddedatatime), _thresremoval(thresremoval) {}
        void setGeometryList(const osgUtil::GeometryCollector::GeometryList& geomlist) {
            for(auto geom : geomlist)  _geoms.push_back(geom);
        virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) {
            osg::Group*  gr = node->asGroup();
            if(!gr || _geoms.empty() ) return;
                osg::Geometry* geom = gr->getChild(0)->asGeometry();
                if(geom) {
                    OSG_WARN<<"removing "<< geom.get()<<std::endl;
            std::list<osg::ref_ptr<osg::Geometry> > ::iterator it= _geoms.begin();
            int cpt=0;
            while(it!=_geoms.end() && cpt++<_nbaddedatatime ) {
                osg::Geometry *newgeom=static_cast<osg::Geometry*>((*it)->clone(osg::CopyOp::DEEP_COPY_ALL));
                OSG_WARN<<"add "<< newgeom<<std::endl;
    /// This examp reproduce a bug with OSG_VERTEX_BUFFER_HINT=VAO:
    /// When a vao is deleted and a new one is regenerate, they may have the same name and so pass as the same for the active check in State::bindVertexArrayObject and crash
    /// it collects geometries given in arg then add and remove them at runtime
    int main(int argc, char **argv)
        osg::ArgumentParser args(&argc,argv);
        unsigned int  geomcountaddedatatime=1,geomcountabovewichweremove=2;
        while("--add",geomcountaddedatatime) ) { }
        while("--remove",geomcountabovewichweremove) ) { }
        osgUtil::GeometryCollector geomcollector(0,osgUtil::Optimizer::ALL_OPTIMIZATIONS);
        osg::ref_ptr<osg::Node > loaded=osgDB::readNodeFiles(args);
            osg::Group * root=new osg::Group;
            GeomLoaderCB * loader=new GeomLoaderCB(geomcountabovewichweremove,geomcountaddedatatime);
            loader->setGeometryList( geomcollector.getGeometryList() );
            osgViewer::Viewer viewer;
            viewer.addEventHandler(new osgViewer::StatsHandler);
            viewer.addEventHandler(new osgViewer::WindowSizeHandler);
            viewer.addEventHandler(new osgViewer::ThreadingHandler);
  • Static intialization order in GraphcsContext

    Static intialization order in GraphcsContext

    When using version 3.6.3 when built using g++ (SUSE Linux) 7.3.1, a segfault occurs when the WindowingSystemInterfaceProxy destructor is called. I tracked it down to the order of initialization of the interfaces between a static proxy object and the local static in getWindowingSystemInterfaces().

    This may not have been seen before without using C++11 rules wrt static object initialization order. Static objects are destroyed in reverse order of creation.

    WindowingSystemInterfaceProxy(const std::string& name) // NOTE: static proxy constructed here { _wsi = new T; _wsi->setName(name);

        // NOTE: this call creates the function-local static interfaces object ** after the proxy ** 

    osg::GraphicsContext::getWindowingSystemInterfaces()->addWindowingSystemInterface(_wsi.get()); }

    ~WindowingSystemInterfaceProxy()   // NOTE: static proxy destroyed
           // NOTE: here the function-local static has been destroyed since it was created after the proxy. 

    osg::GraphicsContext::getWindowingSystemInterfaces()->removeWindowingSystemInterface(_wsi.get()); }

    The temporary solution is to comment-out the removal of interfaces in the destructor. I attempted several other code changes e.g. a sentry object, but none successful as yet.

  • osgAnimation: change animationdata owner from riggeometry to rigtransformimplementations

    osgAnimation: change animationdata owner from riggeometry to rigtransformimplementations

    Refactoring and add a prepareData in RigTransform interface because datapreparation is technic dependant (even if the 2 have few similitude) The original design splitted data preparation in 2 steps:

    • one when the skeleton is not findable (rig->buildinfluenceset)(rig not in a SG callable by use)
    • one when the skeleton is set (rigtrans->init )(rig in a SG not callable by user but fails if no skeleton reachable ) -basically it replace bonename in result buildinfluenceset with actual boneptr

    In the pr i remove the first step and merge it in the second... If it poses problem I can rollback putting tempdata in VertexInfluenceMap or RigGeom and revive RigTansform::init to do the 2nd step

  • StatsHandler crush with multiple windows

    StatsHandler crush with multiple windows

    when I run osgviewer with tow monitors, the osgViewer::Viewer will automaticly call setUpViewAcrossAllScreens(), and I press key 's', it's show debug frame rate, and i press key 's' twice, it will crush at DrawElementsUShort::draw, and error msg is 'vector iterator not dereferencable'.

  • Geometry shader parameter OpenGL error

    Geometry shader parameter OpenGL error

    On some systems (the user who reported this to me is using Mesa with a Radeon Fury), OpenGL errors are being triggered here:

    Investigation has lead me to believe that it's because of the differences between the OpenGL extensions exposing geometry shaders and the core feature of GL 3.2 that does the same thing.

    In the extensions (e.g. GL_EXT_geometry_shader4 and GL_ARB_geometry_shader4) parameters such as input and output type are set as program parameters, just as OSG is doing on the linked lines. However, in the core feature, they're set in the shader source itself. On systems which have the core feature, but not the older extensions, the glProgramParameteri calls are erroneous, and are causing errors to be reported.

    I'm not sure how OSG handles the two different implementations of geometry shaders (if at all), but a short-term fix would be to change the final call on this line from isGLExtensionOrVersionSupported to isGLExtensionSupported. It's definitely not correct to have it as isGLExtensionOrVersionSupported given that the extension and core feature are different, so the presence of the extension isn't implied by the GL version.

  • fails to build without -fpermissive

    fails to build without -fpermissive



    [ 25%] Linking CXX shared library ../../lib/
    cd /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/build/src/osgTerrain && /usr/x86_64-pc-linux-gnu/bin/cmake -E cmake_link_script CMakeFiles/osgTerrain.dir/link.txt --verbose=1
    /usr/bin/x86_64-pc-linux-gnu-c++  -fPIC -pipe -O2 -march=x86-64 -mtune=generic -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused  -Wl,--as-needed -shared -Wl,-soname, -o ../../lib/ CMakeFiles/osgTerrain.dir/DisplacementMappingTechnique.o CMakeFiles/osgTerrain.dir/Layer.o CMakeFiles/osgTerrain.dir/Locator.o CMakeFiles/osgTerrain.dir/TerrainTile.o CMakeFiles/osgTerrain.dir/TerrainTechnique.o CMakeFiles/osgTerrain.dir/Terrain.o CMakeFiles/osgTerrain.dir/GeometryTechnique.o CMakeFiles/osgTerrain.dir/GeometryPool.o CMakeFiles/osgTerrain.dir/Version.o ../../lib/ -lGL ../../lib/ ../../lib/ -lm -lrt ../../lib/ -lpthread -ldl -lz -lGL -Wl,-rpath,/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/build/lib: 
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'void osgDBJPEG::jpeg_istream_src(j_decompress_ptr, std::istream*)':
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:252:32: error: invalid conversion from 'osgDBJPEG::boolean (*)(j_decompress_ptr) {aka int (*)(jpeg_decompress_struct*)}' to 'boolean (*)(j_decompress_ptr) {aka boolean (*)(jpeg_decompress_struct*)}' [-fpermissive]
         src->pub.fill_input_buffer = fill_input_buffer;
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'void osgDBJPEG::jpeg_stream_dest(j_compress_ptr, std::ostream*)':
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:381:35: error: invalid conversion from 'osgDBJPEG::boolean (*)(j_compress_ptr) {aka int (*)(jpeg_compress_struct*)}' to 'boolean (*)(j_compress_ptr) {aka boolean (*)(jpeg_compress_struct*)}' [-fpermissive]
         dest->pub.empty_output_buffer = empty_output_buffer;
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'unsigned char* osgDBJPEG::simage_jpeg_load(std::istream&, int*, int*, int*, unsigned int*)':
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:539:41: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
         (void) jpeg_read_header(&cinfo, TRUE);
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In member function 'osgDB::ReaderWriter::WriteResult::WriteStatus ReaderWriterJPEG::write_JPEG_file(std::ostream&, const osg::Image&, int) const':
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:761:87: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
        jpeg_set_quality(&cinfo, quality, TRUE /* limit to baseline-JPEG values */);
    /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:768:45: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
                 jpeg_start_compress(&cinfo, TRUE);
  • Add option to treat all TGA files as TGA 1.0

    Add option to treat all TGA files as TGA 1.0

    Some files which are malformed TGA 2.0 files are technically valid TGA 1.0 files. For example, an image that just happened to have pixel data matching the TGA 2.0 footer or files created by buggy TGA 2.0 writers and were only ever fed to TGA 1.0 readers.

    One such example from a Morrowind mod is attached:

    This file has a header saying it has eight attribute bits. A TGA 1.0 reader is free to interpret them how it wants (e.g. as alpha or stencil, or just ignoring them). A TGA 2.0 reader is supposed to check for a footer directing it to an extension area, which, if present, will have a field saying what those bits mean. The file's extension area says it doesn't have any such bits (which is different from saying they're present but unused).

    This is against the TGA 2.0 specification published by Truevision, and, in fact, TGADUMP.exe from their TGAUTILS package will complain about Inconsistent Alpha Data Specification. It's a valid TGA 1.0 file, though (albeit one with garbage data at the end), so a conformant TGA 1.0 reader will handle it just fine.

    In TGA 2.0 mode (i.e. the existing code), the extension area will be trusted above the header, and the alpha will be skipped. If the new option string is set, though, only the header will be read, and the alpha will be used.

    OpenMW needs this behaviour as it needs to work with files made for the original Morrowind engine, which only had a TGA 1.0 reader.

    I'm open to suggestions on how to change particular details of this PR as I've not interacted with option strings in OSG before.

  • This stops OpenMW from crashing when using getTextureAttribute

    This stops OpenMW from crashing when using getTextureAttribute

    This stops OpenMW from crashing when creating an object, putting it into a StateSet and then attempting to retrieve it again. OSG master breaks this as a getTextureAttribute wrongly returns 0.

    1040 osg::ref_ptrosg::TexEnvCombine texEnv2 = new osg::TexEnvCombine; ... 1048 stateset->setTextureAttributeAndModes(1, texEnv2, osg::StateAttribute::ON); ... 1058 osg::TexEnvCombine* texEnv2 = static_castosg::TexEnvCombine*(stateset->getTextureAttribute(1, osg::StateAttribute::TEXENV)); 1059 texEnv2->setConstantColor(osg::Vec4f(mAtmosphereColor.x(), mAtmosphereColor.y(), mAtmosphereColor.z(), mTransparency)); // ^^^crash

    For reference:

  • Keyboard in osgviewer.exe has no response

    Keyboard in osgviewer.exe has no response

    1. Build osgviewer and all example application successfully.

    2. Run osgviewe.exe( or any example application) with .osg/.osgt file from "OpenSceneGraph-Data" directory.

    3. GUI could take mouse event like moving, rotation and work normal but not any keyboard event. Once keyboard is pressed, GUI is no reponse. Debugging project find that cull() or draw() is working but main thread fall in OpenThreads::cooperativeWait().

    4. I have download release version from The appreance is same with item3. Any body encounter similar issue? How to fix it?

  • Repair VAS design in 3.6 [please review]

    Repair VAS design in 3.6 [please review]

    fix propal for #674

    Some of the original discussion is on #587 The original discussion on the leak was covered in the thread[email protected]/msg77211.html "VAO Resource Leak in OSG 3.6.2" starting 2 Aug 2018.

    commit engaged eee5d54 @robertosfield edited: problems adressed in this pr are:

    • bufferobject "overfree" bug (releaseGLObject at Drawable destruction cf issue #674) (fix: revert eee5d54 to previous design using dirtyGLObject in ~geometry -vas leak at end of program prevented with following fix-)
    • threading issue with VAO (vao released after context destruction cf issue #674) (fix:record each created vas in VASmanager and delete them on context destruction..vas can be released a second time after context destruction so i added a guard in VASmanager::flushAll)
    • vas life cycle (no way to override vas destruction)(fix add a callback and mod callback interface)
    • and several dirtyGLObject releasGLObject misses in Drawable based (crash at prog end with vao path using geometrypool and particlesystem)
  • Remove stale documentation from the Drawable class

    Remove stale documentation from the Drawable class

    The Drawable class had stale documentation stating that a Drawable is not a node and therefore must be wrapped in a Geode. However, that's no longer true. I dropped the references to Geode from the class description.

  • osg vcpkg

    osg vcpkg

    How right way install osgwith vcpkg for MSbuild (Visual Studio) apps? all osgfiles in "vcpkg\installed\x64-windows\include\osg" has no extension, so simple: #include <osg/AnimationPath> is not work.

  • About Writing OBJ file

    About Writing OBJ file

    Should this line be updating "++iptr" to iterate lines one by one? It seems to be connecting dashed lines, like 1-2, 3-4, 5-6, instead of 1-2-3-4-5-6.

  • Unprotected usage of variable

    Unprotected usage of variable

    file: OpenSceneGraph\src\osg\GraphicsContext.cpp function: GraphicsContext::runOperations '_operations' variable is not protected here by '_operationsMutex'. Leads to potential (real for me actually) crash.

  • Fix RigTransformSoftware copy

    Fix RigTransformSoftware copy

    • Force init for new copy as _uniqVertexGroupList is not copied

    The problem can occur if you deep copy a scene with a RigTransformSoftware in it after it has already been displayed. We were copying a pedestrian model and trying to use a different animation on it, but the second animation fails to apply as the copied RigTransformSoftware never gets inited.

  • Need new tagged release

    Need new tagged release

    When I build OSG via tag OpenSceneGraph-3.6.5, the texture examples do not work. When I build OSG using master branch, the texture examples DO work.

    osgtexture1D.exe built using tag OpenSceneGraph-3.6.5


    In the console, you will see lots of warnings/errors...

    Warning: TexGen::apply(State&) - not supported.
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xc60
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xde0
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
    Warning: Material::apply(State&) - not supported.
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xb50
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xc60
    Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0xc60
    cull()g: detected OpenGL error 'invalid enumerant' after applying GLMode 0xde0
    Warning: Material::apply(State&) - not supported.
    Warning: Material::apply(State&) - not supported.

    osgtexture1D.exe built using master branch (last updated April 7, 2022)


    In the console, there are no warnings/errors...

    end draw() 0000021A36FE49C0
    cull() got SceneView 0000021A37024D20
    end cull() 0000021A36FE49C0
    draw() 0000021A36FE49C0
    draw() got SceneView 0000021A37024D20
    end draw() 0000021A36FE49C0


    vcpkg is using tag OpenSceneGraph-3.6.5 and the examples are broken there, too. I wrote this up as a bug for vcpkg here...

    Proposed Solution

    This repo: A new tag OpenSceneGraph-3.6.6 that covers all updates since 3.6.5

    vcpkg repo: Update vcpkg to use tag OpenSceneGraph-3.6.6

A template C++ repository, using CMake and Catch

C++ Project Template This is a template project for C++. It uses CMake to build and Catch for unit tests. It is integrated with Travis CI, and builds

Sep 5, 2022
Libav github mirror, clone of git://

Libav Libav is a collection of libraries and tools to process multimedia content such as audio, video, subtitles and related metadata. Libraries libav

Sep 21, 2022
A 3D Mapping Engine & SDK for OpenSceneGraph.

osgEarth - 3D Mapping Engine & C++ SDK Welcome to osgEarth! osgEarth gives you the power to add beautiful 2D or 3D maps to your C++ application. Get s

Sep 22, 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

Aug 11, 2022
This is the git repository for the FFTW library for computing Fourier transforms (version 3.x), maintained by the FFTW authors.

This is the git repository for the FFTW library for computing Fourier transforms (version 3.x), maintained by the FFTW authors.

Oct 1, 2022
The official mirror of the V8 Git repository

V8 JavaScript Engine V8 is Google's open source JavaScript engine. V8 implements ECMAScript as specified in ECMA-262. V8 is written in C++ and is used

Oct 1, 2022
Cpp-btree - Git mirror of the official (mercurial) repository of cpp-btree

This library is a C++ template library and, as such, there is no library to build and install. Copy the .h files and use them! See http://code.googl

Sep 4, 2022
The official Allegro 5 git repository. Pull requests welcome!

Welcome to Allegro! Allegro is a cross-platform library mainly aimed at video game and multimedia programming. It handles common, low-level tasks such

Sep 22, 2022
Collection of human friendly terminal interface for git.
Collection of human friendly terminal interface for git.

A collection of human friendly terminal user interface for git.

Sep 24, 2022
A (relatively) small node library to clone and pull git repositories in a standalone manner thanks to libgit2, powered by WebAssembly and Emscripten

simple-git-wasm A (relatively) small node library to clone and pull git repositories in a standalone manner thanks to libgit2, powered by WebAssembly

May 20, 2022
Not a big fan of git. May create a nicer repo in the future.

os My x86-64 hobby operating system. Cooperative multitasking system with no user-mode support, everything runs on ring 0 (for now). Packed with a rea

Sep 9, 2022
A fast Perforce to Git conversion tool written in C++ using Perforce Helix Core C++ API and Libgit2

P4 Fusion A fast Perforce depot to Git repository converter using the Helix Core C/C++ API as an attempt to mitigate the performance bottlenecks in gi

Sep 20, 2022
Transparent file encryption in git

git-crypt - transparent file encryption in git git-crypt enables transparent encryption and decryption of files in a git repository. Files which you c

Sep 27, 2022
A tree-sitter grammar for `git diff` output
A tree-sitter grammar for `git diff` output

tree-sitter-git-diff A tree-sitter grammar for git diffs. Status Working, but needs more testing. Examples Highlighting a .diff file: Injecting this g

Mar 2, 2022
Standardise code formating for cmake projects with git and clang-format

git-cmake-format This project aims to provide a quick and easy way to integrate clang-format into your CMake project hosted in a git repository, it co

Sep 24, 2022
ncurses Git mirror

------------------------------------------------------------------------------- -- Copyright 2020,2021 Thomas E. Dickey

Sep 12, 2022
File path converter for Windows & Git Bash

windows-git-bash-path-converter Motivation Made this because it was so mad to convert path between Windows and Git Bash How to use Windows file path t

Mar 15, 2022
Unofficial git mirror of SQLite sources (see link for build instructions)

SQLite Source Repository This repository contains the complete source code for the SQLite database engine. Some test scripts are also included. Howeve

Sep 27, 2022
Flight rules for git

Flight rules for Git ?? English ∙ Español ∙ Русский ∙ 简体中文∙ 한국어 ∙ Tiếng Việt ∙ Français ∙ 日本語 What are "flight rules"? A guide for astronauts (now, pr

Oct 1, 2022
Open source courseware for Git and GitHub

GitHub Training Kit: Cheatsheets We ❤️ Contributors Like You! We’re eager to work with you, our user community, to improve these materials and develop

Sep 30, 2022