Lightweight and modular C++11 graphics middleware for games and data visualization

Magnum — Lightweight and modular C++11/C++14 graphics middleware for games and data visualization

Looking for an open-source library that gives you graphics abstraction and platform independence on major desktop, mobile and web platforms? Do you want it to have all the convenience utilities around yet stay small, powerful and not give up on flexibility? Here it is. And it's free to use, even for commercial purposes.

Join the chat at https://gitter.im/mosra/magnum Build Status Build Status Build Status Coverage Status Hunter Package MIT License

Beauty of simplicity

Among Magnum essentials is a UTF-8-aware OS, filesystem and console abstraction, a feature-packed vector math library and a slim C++11 wrapper of OpenGL / WebGL family of APIs. Build on top of that or opt-in for more.

See all core features

With batteries included

Shaders and primitives for fast prototyping, algorithms, debugging and automatic testing, asset management, integration with popular windowing toolkits and a UI library. Everything fits together but you still have a choice.

List the extra features

Screws are not glued in

There's always more than one way to do things. Enjoy the freedom of choice and integrate your own asset loader, texture compressor, font format or math library, if you feel the need. Or use any of the various plugins.

View extension points


Wondering if Magnum is a good fit for your project? We prepared a few case studies to help you decide.

SUPPORTED PLATFORMS

  • Linux and embedded Linux
  • Windows with MSVC, clang-cl and MinGW, Windows RT (Store/Phone)
  • macOS, iOS
  • Android
  • Web (asm.js or WebAssembly), through Emscripten

Graphics APIs:

  • OpenGL 2.1 through 4.6, core profile functionality and modern extensions
  • OpenGL ES 2.0, 3.0–3.2 and extensions to match desktop OpenGL functionality
  • WebGL 1.0, 2.0 and extensions to match desktop OpenGL functionality

See the Build Status page for detailed per-platform build status.

WHAT'S NEW?

Curious about what was added or improved recently? Check out the Changelog page in the documentation.

GETTING STARTED

The best way to get started is to read the thorough download, build, install and start using Magnum in your project. There is also a complete building documentation — we provide packages for many platforms, including Windows, Linux and macOS. After that, there are various tutorials and examples and a complete feature guide explaining all aspects of the library.

Apart from that, various Magnum functionality is available through single-header libraries. Just download a file, #include it in your project and you're ready to go! No buildsystem wrangling needed.

RELATED PROJECTS

The engine itself is kept as small as possible with only a few dependencies. Additional functionality, often depending on external libraries, is provided in separate repositories.

Outside of the project itself, there's also a lot of community contributions — check them out on the website.

CONTACT & SUPPORT

If you want to contribute to Magnum, if you spotted a bug, need a feature or have an awesome idea, you can get a copy of the sources from GitHub and start right away! There is the already mentioned guide about how to download and build Magnum and also a guide about coding style and best practices which you should follow to keep the library as consistent and maintainable as possible.

See also the Magnum Project Contact & Support page for further information.

CREDITS

See the CREDITS.md file for details. Big thanks to everyone involved!

LICENSE

Magnum is licensed under the MIT/Expat license, see the COPYING file for details.

Owner
Vladimír Vondruš
Trying to make the world a better place.
Vladimír Vondruš
Comments
  • Conan package

    Conan package

    I'm writing a conan recipe for Magnum (already got one for Corrade successfully building). I've wrestled a few days now with these issues (each try takes a lot of time) so I'd thought I'd look for some help/ideas here!

    Issue

    I'm building conan packages for GCC, Clang (etc.) inside docker containers. In the conan recipe, prior to building magnum, it installs libgl1-mesa-dev (or libgl1-mesa-dev:i386 respectively) on the host. But when later building, it either:

    1. Fails to find OpenGL libs when targeting x86 (for all builds on Ubuntu) if only installing libgl1-mesa-dev:i386:
      CMake Error at /usr/share/cmake-3.12/Modules/FindPackageHandleStandardArgs.cmake:137 
      (message):
          Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY)
      

      Above can be fixed* (for all but Ubuntu Trusty) by installing both libgl1-mesa-dev & libgl1-mesa-dev:i386 (in that order, else 1. happens again), but then it:

    2. fails to link OpenGL (error adding symbols: File in wrong format) on Ubuntu Bionic & Cosmic when targeting x86 (it appears link the 64bit lib).

    *There are a lot of issues with multiple mesa-dev packages on the same host.

    Details:

    • CMake 3.12
    • Ubuntu x64: Trusty (GCC 4.9), Xenial (GCC 5), Artful (GCC 6 & 7, Clang 3.9. 4, 5), Bionic (GCC 8, Clang 6), Cosmic (Clang 7) (using the conan docker images)

    So, any ideas? Anyone seen similar issues? Am I missing something obvious?

  • Problem with configuring CMake

    Problem with configuring CMake

    I`m just getting "Configuring incomplete, errors occurred!". No concrete errors, just nope. I'm trying to configure it for MinGW and I'm receiving this CMakeErrorLog file:

    Determining if the system is big endian passed with the following output:
    Change Dir: C:/Users/Crisser/Desktop/magnum-build/CMakeFiles/CMakeTmp
    
    Run Build Command:"C:/PROGRA~2/CODEBL~1/MinGW/bin/mingw32-make.exe" "cmTC_08a55/fast"
    C:/PROGRA~2/CODEBL~1/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_08a55.dir\build.make CMakeFiles/cmTC_08a55.dir/build
    
    mingw32-make.exe[1]: Entering directory 'C:/Users/Crisser/Desktop/magnum-build/CMakeFiles/CMakeTmp'
    
    Building C object CMakeFiles/cmTC_08a55.dir/TestEndianess.c.obj
    
    C:\PROGRA~2\CODEBL~1\MinGW\bin\gcc.exe     -o CMakeFiles\cmTC_08a55.dir\TestEndianess.c.obj   -c C:\Users\Crisser\Desktop\magnum-build\CMakeFiles\CMakeTmp\TestEndianess.c
    
    Linking C executable cmTC_08a55.exe
    
    "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\cmTC_08a55.dir\link.txt --verbose=1
    
    "C:\Program Files (x86)\CMake\bin\cmake.exe" -E remove -f CMakeFiles\cmTC_08a55.dir/objects.a
    
    C:\PROGRA~2\CODEBL~1\MinGW\bin\ar.exe cr CMakeFiles\cmTC_08a55.dir/objects.a @CMakeFiles\cmTC_08a55.dir\objects1.rsp
    
    C:\PROGRA~2\CODEBL~1\MinGW\bin\gcc.exe       -Wl,--whole-archive CMakeFiles\cmTC_08a55.dir/objects.a -Wl,--no-whole-archive  -o cmTC_08a55.exe -Wl,--out-implib,libcmTC_08a55.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\cmTC_08a55.dir\linklibs.rsp
    
    mingw32-make.exe[1]: Leaving directory 'C:/Users/Crisser/Desktop/magnum-build/CMakeFiles/CMakeTmp'
    
    
    TestEndianess.c:
    /* A 16 bit integer is required. */
    typedef unsigned short cmakeint16;
    
    /* On a little endian machine, these 16bit ints will give "THIS IS LITTLE ENDIAN."
       On a big endian machine the characters will be exchanged pairwise. */
    const cmakeint16 info_little[] =  {0x4854, 0x5349, 0x4920, 0x2053, 0x494c, 0x5454, 0x454c, 0x4520, 0x444e, 0x4149, 0x2e4e, 0x0000};
    
    /* on a big endian machine, these 16bit ints will give "THIS IS BIG ENDIAN."
       On a little endian machine the characters will be exchanged pairwise. */
    const cmakeint16 info_big[] =     {0x5448, 0x4953, 0x2049, 0x5320, 0x4249, 0x4720, 0x454e, 0x4449, 0x414e, 0x2e2e, 0x0000};
    
    #ifdef __CLASSIC_C__
    int main(argc, argv) int argc; char *argv[];
    #else
    int main(int argc, char *argv[])
    #endif
    {
      int require = 0;
      require += info_little[argc];
      require += info_big[argc];
      (void)argv;
      return require;
    }
    

    Is it part of CMake code? What's happening? I've done everything how explained in your getting started tutorial.

  • MSVC 2017 ICE in PackingBatch.cpp

    MSVC 2017 ICE in PackingBatch.cpp

    Hello, this might be kind of nitpicking but wanted to know if there is a solution.

    I redirected Corrade::Utility::Debug into an std::stringstream as described in the docs and it works as expected. But the engine startup information is logged before I can initialize anything in my application class (which the mentioned stringstream is a field of). I wonder if there is a way to "salvage" that information.

    I mean I can redirect stdout into a txt file and read the contents into my stringstream. Currently that's what I am doing. It feels kind of hacky, and I don't use the stdout.txt anymore after the initial statup logs are written into it. So it just sits there with the executable. Tried to delete it but since the executable is holding onto it, removing operation fails.

  • Multi-context/window rendering.

    Multi-context/window rendering.

    Is it possible to use magnum to render to different contexts ?

    I'm using multiple-windows, doing the all the complex rendering from the main context through render to texture. I'm wondering if I can do the quad rendering for the other windows through Magnum or if I should do direct openGL calls.

  • OpenAL extension support

    OpenAL extension support

    Hi @mosra, Hi everybody!

    here is a work-in-progress pullrequest for anything related to Audio and OpenAL extension support.

    TODOs:

    • [x] Add support for OpenAL extensions
      • [x] Finish doc
      • [x] Ensure Format Type parameter is a useful config setting. (format type and channels are for the loopback extension, will will not be supported for now.)
      • [x] Tests
    • [x] Implement AL_EXT_float32 and AL_EXT_double
      • Not really anything to test.
    • [x] Add support for the OpenAL soft hrtfs
      • [x] Tests

    Greetings, Squareys

  • Plaftorm: Add cursor management support

    Plaftorm: Add cursor management support

    Platform support:

    • [x] ~AndroidApplication~ It's rarely used
    • [x] GlfwApplication
    • [x] Sdl2Application
    • [x] ~GlxApplication~
    • [ ] ~EmscriptenApplication~ It'll be made by mosra
    • [x] ~XEglApplication~

    The main usage for this (that is the main reason on why I implemented this) is for the ImGuiIntegration, because right now when hovering the edges of the windows/other draggable elements the cursor doesn't change due to the lack of this feature.

    I'm not entirely sure about how good it's implemented, e.g. the way I constructed the array using the last enum element to get the size, and the whole switch-case that I needed to make (yeah, basically everything).

    Also, I was thinking about adding the cursor creation in the Application constructor as well, using the Configuration class, but even there I was unsure if it was a good idea or not.

  • 2018.10 release

    2018.10 release

    After releasing 2018.04 I decided to have a bit more time to pull bigger features in and so 2018.06 was skipped. I don't want to take the release too long, ~~so I'd like to have 2018.08 as the next release -- i.e., before the end of August.~~ ha no chance.

    What needs to be done:

    • [x] Everything that's in the 2018.0c milestones and hasn't been postponed (this issue + the stuff below)
      • [x] Provide some basic format / ... enum translation? (#234)
      • [x] Look into the "corrade module dir not found" fiasco with emscripten and try to find a proper solution (https://github.com/mosra/magnum/issues/283)
      • [x] Cubic Hermite Splines (#267)
    • [x] Spline import in glTF -- mosra/[email protected]
    • [x] quaternion normalization in glTF -- mosra/[email protected]
    • [x] AnimationData should have trackTarget() and trackTargetType() because everything else in Trade is like that (instance() and instanceType()). Changing this later would be bad. -- e43d5790f606c8b13f29fde4a53a6a48361dd937
    • [x] File callbacks for Trade::AbstractImporter (mosra/[email protected])
    • [x] Finish initial animation support and merge it to master (#191)
    • [x] glTF animation import (mosra/magnum-plugins#46)
    • [x] Improve default visuals of Emscripten apps (mainly: make them responsive and in-line with website design) -- mosra/[email protected], mosra/[email protected]
    • [x] Create some advanced viewer/player app in the extras repository that's able to load models and play back their animations -- very important to actually verify both the usability of the API and correctness of its behavior (mosra/magnum-extras#6)
    • [x] Inline math rendering is broken on the website (what the heck did I break this time?!) -- stale cache file, is okay now
    • [x] Make the initial Vulkan lib properly compiling on Windows (together with CI setup) -- done in d578d4d89e5f5b9ab0c73d1567bfafa19f530093 and 6f2b11595393542957ddb20ff3606a13fb9c0266
    • [x] ~~Finish~~ Initial HiDPI support (#243)
      • [x] Make Ui DPI-aware -- mosra/[email protected]
      • [x] GLFW support -- dba35bac7a9c170931c476719e4781e501c92a65
      • [x] Re-upload webgl showcase to be DPI-aware
      • [x] ~~Windows support~~ postponed, nobody complained yet :trollface:
    • [x] AssimpImporter "no root node" updates broke DART -- import the root node if there is just the root node -- mosra/[email protected]
    • [x] Alpha masking in Phong is broken, color intensity should not be affecting alpha channels -- mosra/[email protected]
    • [x] Clarify difference between rotationScaling() and rotation() (and uniformScaling()) in the docs (with math eqs) (086ed8a278df652b8d72e513bbce8dce6d3eea5e)
    • [x] Use T instead of Vector<1, T> in Range1D -- Animation depends on that heavily and [0] is very ugly ... does that break anything? -- https://github.com/mosra/magnum/commit/0226ab26c498bc863b75f7217cebdebece6caa1e
    • [x] ~~Move enums inside plugin interface classes outside so they are easier to type (and add deprecated aliases)~~ postponed
    • [x] ~~CMake 3.12 doesn't seem to play well with Emscripten (on Windows the platform file is ignored, resulting in wrong file suffixes)~~ can't reproduce
    • [x] Oculus SDK 1.4 download fails with 404 now (in case it's not cached by appveyor: https://ci.appveyor.com/project/mosra/magnum-examples/build/master-506/job/63sk22bxtu60c5ot), need to fetch a copy of the latest and store it somewhere privately because the upstream downloaded is behind a wall with barbed wire ughhh (mosra/magnum-integration#26)
    • [x] Updates in Find modules so they can find DebugTools and BulletIntegration even without Shapes or other dependencies, even on non-deprecated builds -- 2c56d1600a1fceea9eb8d4518d4b6b3f20769835
    • [x] Visibly deprecate old unmaintained functionality, remove it from packages and schedule it for complete removal in ~6 months (#148)
      • [x] the Shapes library (and related stuff in DebugTools and BulletIntegration) -- 8efc6b39e902d01dfac904163ad90385d3007013, mosra/[email protected]85f91e47d0992589d9
      • [x] the ColladaImporter plugin -- mosra/[email protected]
      • [x] the Platform::GlutApplication lib -- mosra/[email protected]
    • [x] Fix important reports from https://gist.github.com/alexesDev/8b177d3ec33784cc1b26222e9b4daa09 -- e7954783530a0fac7f24f81241a3d0e609468638, 471a6d0c28bccaa327d75d30b789f26df62ebdec, c0affdae3ba3c13535617e182fe7074b8f3b3d0f, 7356a1b788579ee4495f0d97da42557cb5478e90, 87a951fc5d3bd5e0672c31a02102bf0b45d08faf and mosra/[email protected]
    • [x] Fix build failure of extras on 32-bit windows (the Interconnect library has wrong assumptions about member function pointer sizes with classes using multiple inheritance) (mosra/magnum-extras#7) -- mosra/[email protected]
    • [x] ~~Do the ugly windows-specific Interconnect/Ui virtual base workaround for mingw as well (seems to be the same ABI, duh)~~ didn't help, postponed (mosra/corrade#51)
    • [x] ~~What about Interconnect and ICF on MSVC?~~ postponed, mosra/corrade#51
    • [x] Make the corrade-rc utility not depend on the Utility library to avoid the most common build issues -- mosra/[email protected]
    • [x] Provide clearer documentation for using custom buildsystems (#268)
    • [x] Mention potential pitfalls and differences among various primitives (mosra/magnum-examples#48)
    • [x] Update the magnum-bootstrap repository with fresh CMake modules once also GLFW HiDPI support is done
    • [x] Support for multiple primitives per object in the glTF importer (https://github.com/mosra/magnum-plugins/issues/48)
    • [x] Disabled-by-default workaround to allow cinematic animations in the glTF importer -- mosra/[email protected]
    • [x] Linear gradient primitive
    • [x] Investigate and work around MSVC 2017 ICE with Color.h -- fixed in b44166b23818bba62e6a0e4e7bcc4e6cd95c81ca
    • [x] ~~Fix license detection on GitHub~~ don't know, don't care
    • [x] https my shit

    What should be done (very good for marketing, but it's not extremely critical if this misses the milestone):

    • [x] Integrating the mouse controls example (mosra/magnum-examples#46)
    • [x] Integrating the Box2D example that I have in my e-mail inbox since March and didn't get to it yet (sorry) -- mosra/[email protected]
    • [x] ~~Integrate minimp3 for MP3 audio import~~ postponed, #146
    • [x] ~~Investigate OpenAL support on Android (#149)~~ postponed, needed in October earliest
    • [x] Merge JpegImageConverter to support more screenshot options (mosra/magnum-plugins#26)
    • [x] ~~Simple animated example showing difference between quaternion slerp/lerp~~ postponed, #102
    • [x] ~~Simple animated example showing floating point drift (angle, matrices, quats, renormalized quats)~~ postponed, #102
    • [x] Example gallery with images instead of a boring list (should be possible thanks to latest updates to m.css doxygen theme) -- (http://doc.magnum.graphics/magnum/example-index.html
      • [x] The same for utilities

    ~~These lists might grow later.~~ ugh NO, ENUFF

    Apart from that there's a lot of other not-as-important things to add, but since I won't have time to anything extra, I won't list them here. As always, help is greatly appreciated -- and if anybody is willing to contribute, their name will be prominently mentioned in the release notes :)

  • Next release

    Next release

    There's a lot of new stuff which should be made into official release as soon as possible in order to keep the changelog in sane size.

    A (hopefully not very growing) list of things to do:

    General:

    • [x] At least somewhat usable MSVC 2015 support (#96)
    • [x] ~~Update~~ Get rid of compatibility branch
    • [x] ~~Revive (P)NaCl support as GCC 4.4 support was dropped~~ later
    • [x] Publicly available and green CI for all platforms (#99)
    • [x] Code coverage on coveralls.io?
    • ~~Put documentation on readthedocs.org~~ (fixed some other way, see #113)
    • [x] Fix currently pending issues and TODOs
    • [x] Stabilize new APIs
    • [x] ~~Drop stuff that's long deprecated~~ after the release
    • [x] Update copyright year to 2017
    • [x] Make changelogs part of Doxygen docs

    Corrade:

    • [x] Add planned --skip-tests, --skip-benchmarks and --no-xfail options to TestSuite tester executables (mosra/[email protected], mosra/[email protected])
    • [x] Something's wrong with recent Emscripten builds (Utility::Resource) (mosra/[email protected])
    • [x] Update TestSuite documentation to mention colored output, instanced tests, repeating and benchmarks (mosra/[email protected])
    • [x] ~~Plugin initialization/finalization is broken by design (e.g. unloading HarfBuzzFont finalizes FreeType library)~~ postponed

    Core lib:

    • [x] ~~Finish~~ Fix pixel storage support so it passes the tests at least on one platform (#104)
    • [x] magnum-imageconverter utility
    • [x] ~~"OpenGL 2015" and OpenGL ES 3.2 support (just a few new function aliases)~~ postponed, see #231
    • [x] Finish Windows Store/Phone support (a4d3beb0c3c718ce7cd38a537fc9be7d27235215)
    • [x] ~~WindowlessXEglApplication to be able to run utilities on embedded Linux devices~~ we have WindowlessEglApplication and that should be enough I think
    • [x] Compute shader tests fail on NV (ad962415a211307f1292f2f02f8739dfa4ae4370)
    • [x] Container::Array instances returned from plugin crash on dangling deleter pointer after a plugin is unloaded (mosra/[email protected])
    • [x] ~~Finish unhandled cases in DebugTools::textureImage()~~ postponed
    • [x] Implement compressed subimage queries to finally have complete textures (affected by a bug on NVidia) (645edecbcdc76902e80634bcc54782544512cf0a)
      • [x] which means adding a clean way for driver workarounds and ability to selectively disable them from command-line (356491e1dfb74df635fe607fc2f75a6989278e1c)
      • [x] and from environment to have all cases conveniently batch-testable (707d1d084d20c5c98814873e7b1dc24cc29623f9)

    Plugins:

    • [x] Merge DDS importer (mosra/magnum-plugins#7)
    • [x] Add AnyImageConverter and AnyAudioImporter
    • [x] Make StbImageConverter produce also other image formats (mosra/[email protected])
    • [x] ~~Implement StbDxtImageConverter using stb_dxt and (dynamically) use it in DdsImageConverter (should be easy as the other way around is already done)~~ postponed

    Examples:

    • [x] Port Audio example to Emscripten (should be fun)
    • [x] Check what's new in WebGL 2 land (mosra/magnum-examples#12)
    • [x] Picking example broken on Mesa (04983da23a503d68bddcc0ab416c81bf22a9f910 and mosra/[email protected])

    Integration:

    • [x] Stabilize OvrIntegration API and ~~update to 0.7 (mosra/magnum-integration#7)~~ ~~0.8 (mosra/magnum-integration#10, mosra/magnum-examples#19)~~ 1.3 (mosra/magnum-integration#12, mosra/magnum-examples#22), hopefully they will finally stop completely breaking the API with each new release
  • [MSYS2/Mingw-w64/Clang] duplicate section has different size

    [MSYS2/Mingw-w64/Clang] duplicate section has different size

    I'm trying to compile the base.zip-like project, but using Clang (via a CMake toolchain file). Compiling prints a linking warning :

    C:/msys64/mingw64/lib/libMagnumGlfwApplication-d.a(GlfwApplication.cpp.obj): duplicate section ".rdata$_ZTSN6Magnum8Platform15GlfwApplicationE[_ZTSN6Magnum8Platform15GlfwApplicationE]" has different size. 
    

    Forcing the usage of LLVM's LLD with -fuse-ld=lld gives me this error :

    lld-link: error: duplicate symbol: typeinfo name for Magnum::Platform::GlfwApplication
    >>> defined at CMakeFiles/appExec.dir/src/main.cpp.obj
    >>> defined at libMagnumGlfwApplication-d.a(GlfwApplication.cpp.obj)
    

    My toolchain file is as simple as :

    list(APPEND CMAKE_PREFIX_PATH 
        ${MINGW64_ROOT} 
    )
    SET(CMAKE_BUILD_TYPE Debug)
    SET (CMAKE_C_COMPILER "clang")
    SET (CMAKE_CXX_COMPILER "clang++")
    SET (CMAKE_C_FLAGS "-fuse-ld=lld")
    SET (CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS})
    

    I've tried this using the official Magnum MSYS2 package, but also with the latest HEAD (local compilation of Corrade + Magnum). Same issue with both SDL2 and GLFW.

    I've had absolutely no issue nor warnings with GNU tho.

    Am I doing something wrong here ?

  • Rewrite FindOpenAL so it works with add_subdirectory'd OpenAL Soft sources

    Rewrite FindOpenAL so it works with add_subdirectory'd OpenAL Soft sources

    Requested by @hsdk123. Currently the forked upstream FindOpenAL only works with bundled OpenAL Soft binaries, but not with sources.

    EDIT: And also allow DLL copying like with FindSDL and FindGLFW.

  • Audio features

    Audio features

    Hi @mosra, Hi everybody!

    As discussed, here is a work-in-progress pullrequest for everything related to Audio and SceneGraph.

    TODOs:

    • [x] PlayableGroup
    • [x] Playable
    • [x] Listener
    • Adapt audio-example (later)

    Greetings, Squareys

  • Extension points in builtin shaders

    Extension points in builtin shaders

    Discussed on Gitter a while ago, putting it here to avoid forgetting the details.

    The main idea is that vertex (fragment, geometry...) shaders would contain various extension placeholders using macros. At the very least one for defining extra uniforms / inputs / outputs, and one inside the main function, with actual code.

    #ifdef VERTEX_SHADER_INTERFACE_EXTENSION
    VERTEX_SHADER_INTERFACE_EXTENSION
    #endif
    
    void main() {
        ...
        #ifdef VERTEX_SHADER_MAIN_EXTENSION
        VERTEX_SHADER_MAIN_EXTENSION
        #endif
    }
    

    Then, the user would have an option to subclass the shader and supply an additonal file to the base class, which defines a subset of these macros, such as:

    #define VERTEX_SHADER_INTERFACE_EXTENSION \
        uniform(location = 69) in float fancyFactor;
    #define VERTEX_SHADER_MAIN_EXTENSION \
        gl_Position.z *= fancyFactor;
    

    This file would be inserted as the very first (after the #version directive), to allow also enabling various extension in it:

    #extension GL_ARB_bindless_texture: require
    
    #define VERTEX_SHADER_INTERFACE_EXTENSION \
        ...
    

    What's left to figure out:

    • [ ] Figure out a nice way to supply the extra file. Adding yet another positional argument to each shader constructor doesn't scale and every such addition causes a breaking change for users, so the constructors should probably have some ShaderConfiguration class supplied, like apps or Vk APIs do.
      • [ ] Could this configuration be shared between GL and Vulkan to avoid code duplication? Probably not much, at the very least the flags are different (Flag::UniformBuffers are implicit on Vulkan).
    • [ ] What to do if something has to be done before constructing the parent class? NoCreate and then *this = BaseShader{actualConstructorParameters}; in the constructor could work, but is kinda nasty. Another option could be a subset of #534 reused for this purpose as well.
    • [ ] On nasty old GL platforms, new attributes have to be bound after compiling and before linking. Make extension points impossible there? Or reuse a subset of #534 again?
    • [x] Code that has to be run after the shader is compiled & linked is easy, just put that into the derived class constructor.
    • [ ] Can something like this be done for SPIR-V? At the very least there could be a possibility to override the supplied SPIR-V binary, and the overriden binary could be generated pretty much the same as with runtime GLSL compilation, only through an offline tool.
      • [ ] Might need to extend GlslangShaderConverter with an ability to do "implicit includes" similarly to GCC's -include option, doing all this via a -DVERTEX_SHADER_INTERFACE_EXTENSION=... passed to magnum-shaderconverter would be PAINFUL.a
  • Please help fix the GCC bug

    Please help fix the GCC bug

    I notice that a commit of this project reported a rounding error:https://github.com/mosra/magnum/commit/fb51f25a7b613aa5be744deea5a4ddb88f3de064

    As this may be a GCC bug, I have filed this problem to GCC:

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905

    Would you please provide more feedback through the url? GCC developers can fully resolve the problem.

  • AnyImage{Importer,Converter}: detect also KTX1

    AnyImage{Importer,Converter}: detect also KTX1

    Even though KtxImporter / KtxImageConverter doesn't support these (and probably never will), the rationale here is to provide a somewhat better message than "unable to detect file format" when trying to open a *.ktx file, or when trying to save to a *.ktx by accident, instead of *.ktx2 (which I do quite often). The concrete plugins are able to provide a much better error message about version 1 not supported.

    However, this means that once some new plugin actually supports KTX1, KtxImporter will still get picked over it, since it always has a precedence over any alias. So this might actually be counterproductive, ending up in the same endless pain as is with the still pretty much uselessly barebone ObjImporter being picked over AssimpImporter. Different ideas?

    • Don't detect KTX1 at all, like until now? Goes against what I wanted to fix in the first place, to have a reasonable error message when trying to open or save a *.ktx file.
    • Detect, but delegate them to a new Ktx1Importer / Ktx1ImageConverter, which won't have any matching plugin in the foreseeable future (and thus also being utterly confusing?)
    • Wait for integration of some plugin that knows KTX1 and then use Ktx1Importer / Ktx1ImageConverter for it? I don't know about any, and integrating Khronos' KTX Software (which depend on GLUT and whatnot) is one thing I definitely did not want and thus went with plugins implemented from scratch instead. OIIO is flexible but doesn't seem to support KTX and there doesn't seem to be any interest in adding that.
    • Support KTX1 in KtxImporter / KtxImageConverter? Ugh. Actually, integrating KTX Software seems a better idea than wasting time implementing KTX1 myself, but it would need to have some other added value than just being able to work with KTX1.
  • Feature Request: Support std::stop_token as optional parameter to Sdl2Application::exec()

    Feature Request: Support std::stop_token as optional parameter to Sdl2Application::exec()

    See: https://en.cppreference.com/w/cpp/thread/stop_token

    And Sdl2Application::exec() is implemented as follows:

    int Sdl2Application::exec() {
        #ifndef CORRADE_TARGET_EMSCRIPTEN
        while(mainLoopIteration()) {}
        #else
        emscripten_set_main_loop_arg([](void* arg) {
            static_cast<Sdl2Application*>(arg)->mainLoopIteration();
        }, this, 0, true);
        #endif
        return _exitCode;
    }
    

    It would be nice, if Magnum was compiled with C++20, to have the ability to pass an std::stop_token into the exec() function as an additional way to terminate.

    This would be an alternative to calling Sdl2Application::exit();

    The motivation behind this feature request is to support slightly better encapsulation, where an application that has a threadpool, holding one or more std::jthread objects may not want to have the threadpool code aware of special rules to shutdown the threads, allowing instead for the std::stop_token to be respected directly for a pool-wide graceful shutdown.

  • Test buffer contents on GLES3 & WebGL, fix global symbol duplication in GL test libraries

    Test buffer contents on GLES3 & WebGL, fix global symbol duplication in GL test libraries

    Split off of #560, because it uncovered a deeper problem in how *TestLib libraries are built.

    • FooTestLib is mostly the same as Foo, except that it has CORRADE_GRACEFUL_ASSERT defined in order to be able to test assertion messages -- then an assert won't abort, but instead gracefully return, allowing the message to be captured.
    • MagnumGL has a global "current context" pointer, and then there's MagnumGLTestLib which has also a global "current context" pointer. To avoid having two copies of the same, a GL test should then link to either one or the other and never both.
    • To avoid duplication, there's also MagnumOpenGLTesterTestLib, which links to MagnumGLTestLib instead of MagnumGL. Unfortunately it does so only on Windows, which has to be fixed.
    • And because we're now using DebugTools::bufferData() to query buffer contents, there also needs to be (a subset of) DebugTools that links to MagnumGLTestLib instead of MagnumGL.

    Things to do:

    • [x] Test buffer contents on GLES3 (fix all cases of /** @todo How to verify the contents in ES? */)
    • [ ] Make MagnumOpenGLTesterTestLib link against MagnumGLTestLib everywhere, not just on Windows
    • [x] Make a MagnumDebugToolsGLTestLibSubset linking to MagnumGLTestLib
      • [ ] Remove now-outdated info from the commit message
  • Can vcpkg be used to install a later version of magnum?

    Can vcpkg be used to install a later version of magnum?

    Currently vcpkg points to magnum version 2020.06. I would like to use some of the new functionality such as transformations on MeshData.

    I tried installing magnum using the --head option but it failed.

    vcpkg install magnum --triplet=x64-windows-static-md --head

    So is it somehow possible to use a later release? will there be a new release to vcpkg soon?

Alpha Plot is a free application for Scientific Data Analysis and Visualization for Windows, Linux and Mac OS X
Alpha Plot is a free application for Scientific Data Analysis and Visualization for Windows, Linux and Mac OS X

Alpha Plot is a free application for Scientific Data Analysis and Visualization for Windows, Linux and Mac OS X (probably BSD also). Web Link Website

May 30, 2022
Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal
Low Level Graphics Library (LLGL) is a thin abstraction layer for the modern graphics APIs OpenGL, Direct3D, Vulkan, and Metal

Low Level Graphics Library (LLGL) Documentation NOTE: This repository receives bug fixes only, but no major updates. Pull requests may still be accept

Jun 19, 2022
A terminal-based graphics library for both 2D and 3D graphics.
A terminal-based graphics library for both 2D and 3D graphics.

TermGL A terminal-based graphics library for both 2D and 3D graphics. Written in C, created for terminals supporting ANSI escape codes. Table of Conte

Jun 19, 2022
kaun is a replacement for löve's built-in love.graphics module intended for 3D graphics

kaun kaun is a replacement for löve's built-in love.graphics module intended for 3D graphics. It is a Lua module you can require from a shared library

Apr 5, 2021
This repo contains the DirectX Graphics samples that demonstrate how to build graphics intensive applications on Windows.
This repo contains the DirectX Graphics samples that demonstrate how to build graphics intensive applications on Windows.

DirectX-Graphics-Samples This repo contains the DirectX 12 Graphics samples that demonstrate how to build graphics intensive applications for Windows

Jun 17, 2022
Metal-cpp is a low-overhead C++ interface for Metal that helps developers add Metal functionality to graphics apps, games, and game engines that are written in C++.

About metal-cpp is a low overhead and header only C++ interface for Metal that helps developers add Metal functionality to graphics applications that

Jun 15, 2022
Powerful, easy to use, and portable visualization toolkit for mixed 3D and 2D content
Powerful, easy to use, and portable visualization toolkit for mixed 3D and 2D content

Powerful, easy to use, and portable visualization toolkit for mixed 3D and 2D content

Jun 14, 2022
HARFANG®3D is an all-in-one 3D visualization library usable in C++, Python, Lua and Go.
HARFANG®3D is an all-in-one 3D visualization library usable in C++, Python, Lua and Go.

HARFANG® 3D engine HARFANG®3D is an all-in-one 3D visualization library usable in C++, Python, Lua and Go. Table of contents About Features Screenshot

Jun 21, 2022
RGL - 3D visualization device system for R using OpenGL
RGL - 3D visualization device system for R using OpenGL

RGL - 3D visualization device system for R using OpenGL INTRODUCTION The RGL package is a visualization device system for R, using OpenGL or WebGL as

Jun 20, 2022
Binary visualization tool primarily aimed at videogame reverse engineering & research.
Binary visualization tool primarily aimed at videogame reverse engineering & research.

binviz Binary visualization tool. Allows you to load a binary and pan/zoom around its content. Each byte (or 4 bytes in 4-byte mode) is represented by

Apr 25, 2022
Vis: Asynchronous 3D Visualization Tool
 Vis: Asynchronous 3D Visualization Tool

English | 简体中文 Vis: Asynchronous 3D Visualization Tool Vis 是一款交互式异步3D可视化工具,旨在让3D视觉和机器人应用开发更简单。 其核心功能包括: 图形绘制 3D模型文件导入 多种交互工具 Gzimo 安装 Linux # 安装必要的依

May 17, 2022
Mandelbrot set visualization in OpenGL

Mandelbort-Set done in OpenGL Steps to build and run ( program tested only on Linux-Ubuntu 18.04,20.04 ) install the necessary packages- glut,glfw,glm

Feb 13, 2022
C++14 network/graph visualization library / Qt node editor.
C++14 network/graph visualization library / Qt node editor.

QuickQanava QuickQanava is a C++14 library designed to display graphs and relational content in a Qt/QML application. QuickQanava provide QML componen

Jun 17, 2022
Yocto/GL: Tiny C++ Libraries for Data-Driven Physically-based Graphics
Yocto/GL: Tiny C++ Libraries for Data-Driven Physically-based Graphics

Yocto/GL: Tiny C++ Libraries for Data-Oriented Physically-based Graphics Yocto/GL is a collection of small C++17 libraries for building physically-bas

Jun 18, 2022
Brand new engine with new and QoL features. Grafex is Psych engine with some additions and Better graphics

Friday Night Funkin' - Graphex Engine Credits: Grafex Mod aka Psych Graphic Rework: Xale - Lead Coding, Artist PurpleSnake - Second Coder Psych Engine

Apr 22, 2022
A modern cross-platform low-level graphics library and rendering framework
A modern cross-platform low-level graphics library and rendering framework

Diligent Engine A Modern Cross-Platform Low-Level 3D Graphics Library Diligent Engine is a lightweight cross-platform graphics API abstraction library

Jun 17, 2022
Dear PyGui 3D Engine (early development) and Graphics API demos.
Dear PyGui 3D Engine (early development) and Graphics API demos.

Marvel This repo is the working location of the eventual Dear PyGui 3D Engine. It also contains several single file examples of creating a triangle wi

Jun 21, 2022
This repository is used for storing sourcecode related to final project of Computer Graphics and Computer Vision
This repository is used for storing sourcecode related to final project of Computer Graphics and Computer Vision

Computer Graphics and Computer Vision Description: This repository is used for storing sourcecode related to final project of Computer Graphics and Co

Jun 16, 2022
Yet another Chip-8 interpreter, this time written in C++ using GLFW and OpenGL as its graphics library 💻
Yet another Chip-8 interpreter, this time written in C++ using GLFW and OpenGL as its graphics library 💻

Yet another Chip-8 interpreter, but this time with a beautiful interface ??

Jun 4, 2022