Evaluating magnum as a graphics backend for our project

[andy.s...@gmail.com]

Hi All, 

We're evaluating using Magnum as a possible graphics backend for our real-time physics simulation project, and I've got a few questions:

* We suport Mac, Windows and Linux, how good is cross-platform support with Magnum?

* How easy is it to hook up Magnum to an existing native window, i.e. say on Windows, I create a new Win32 window, or on Mac I create a Cocoa window, is it possible to hook up Magnum to that window. I know that I'll have to grab the window events (mouse, resize, etc...) in my app and forward them to Magnum, that's not a big deal. We'll be using the native toolkit on each platform for the gui, i.e. WPF on Windows, Cocoa on Mac and GTK on Linux, so it's important that we can hook up our rendering code to native windows. 

* Much of our application will entail displaying highly dynamic deformable elastic surfaces and particle systems with programmatically generated textures, do you thing Magnum is a good fit? 

* We also plan to do a bit of 2D drawing (objects in a tree structure), I saw that 2D is also well supported in Magnum, so this looks promising. 

* I saw that Magnum has a scene graph API, that's good for us, because part of what we'll be doing will be constructive solid geometry, similar to OpenSCAD, http://www.openscad.org, and a scene graph we think is a good way to represent this kind of geometry. 

* From looking at the Magnum code, it looks like there are no 3rd party dependencies. This is very appealing, as maintaining dependencies is a giant pain. 

* It also looks like Magnum is just focused on rendering, and does not do physics, audio, etc... This too is very appealing to us, as we're looking for just a back end for rendering. 

* It would appear that Apple, in their infinite wisdom (sarcasm) is slowly deprecating OpenGL in favor of metal. In the future, do you think Magnum could have different backends (metal, directx)? 

Thanks, 

-- Andy 

[andy.s...@gmail.com]

One more thing, how open are the Magnum developers to accepting code patches that say fix bugs or add functionality? 

[Squareys]

Hi Andy!

I am not the project maintainer, but I have used magnum for over two years now and successfully contributed many pullrequests during this time. (Which should answer your last question ;) )

* We suport Mac, Windows and Linux, how good is cross-platform support with Magnum?

Magnum supports all of these platforms plus iOS, Android and Web. And all of these are automatically tested in publicly available CIs!
 

* How easy is it to hook up Magnum to an existing native window, i.e. say on Windows, I create a new Win32 window, or on Mac I create a Cocoa window, is it possible to hook up Magnum to that window. I know that I'll have to grab the window events (mouse, resize, etc...) in my app and forward them to Magnum, that's not a big deal. We'll be using the native toolkit on each platform for the gui, i.e. WPF on Windows, Cocoa on Mac and GTK on Linux, so it's important that we can hook up our rendering code to native windows. 

I will skip this question as I am not entirely sure, but it would really surprise me if this were not possible. (Let's see what @mosra says about this).

 

* Much of our application will entail displaying highly dynamic deformable elastic surfaces and particle systems with programmatically generated textures, do you thing Magnum is a good fit? 

You should be able to easily implement this on top of Magnum, yes. Magnum gives you the flexibilty and performance of raw OpenGL through a way nicer modern C++11 API, so you should be able to do basically anything.

 

* We also plan to do a bit of 2D drawing (objects in a tree structure), I saw that 2D is also well supported in Magnum, so this looks promising. 

Indeed it is!

* I saw that Magnum has a scene graph API, that's good for us, because part of what we'll be doing will be constructive solid geometry, similar to OpenSCAD, http://www.openscad.org, and a scene graph we think is a good way to represent this kind of geometry. 

I personally am not a huge fan of Magnums SceneGraph, but I have used it quite alot anyway and it is definitely flexible enough to extend to this kind of usecase.

 

* From looking at the Magnum code, it looks like there are no 3rd party dependencies. This is very appealing, as maintaining dependencies is a giant pain. 

The repositories "corrade" and "magnum" (which builds on corrade) can be dependency free, but optionally compiled components like Audio require OpenAL, magnum-integration has a component for bullet physics and Oculus VR, magnum-plugins features a huge variety of file formats which may also require additional dependencies.

 

* It also looks like Magnum is just focused on rendering, and does not do physics, audio, etc... This too is very appealing to us, as we're looking for just a back end for rendering. 

Magnum has some code to integrate with bullet phyics (optional and in the magnum-integration repository) as well as an optionally compiled library which wraps OpenAL for audio, should you ever need those.

 

* It would appear that Apple, in their infinite wisdom (sarcasm) is slowly deprecating OpenGL in favor of metal. In the future, do you think Magnum could have different backends (metal, directx)? 

I started sketching out a Vulkan implementation last year (which doesn't really help with Apple hardware either), but that is more a new API rather than a backend. I think @mosra mentioned something about Metal to be once, but you'll have to wait for his reply on that.

Personally, I see Magnum as a "Zen-Garden". I don't know of any project which has such thorough documentation, meticulously maintained code quality (you get alot of feedback on pullrequests from which I learned so much about C++ in the last two years, they are generally highly interactive) and amazing test coverage ontop a very neat test framework. The maintainer of the project, Vladimír Vondruš, really cares and puts as much effort into this project as humanly possible even when employed full-time.

It would be great to read which library you decided to go with for this project, please do write about your final decision here, even if it turns out not to be magnum in the end!

Kind regards,
Jonathan

[Vladimír Vondruš]

Hello!

1. Support for Mac, Windows and Linux platforms is well maintained and there are currently numerous people working on these three desktop platforms on a day-to-day basis, using Xcode, Visual Studio and other common IDEs. Support for all platforms is also consistently verified on public CIs, as you can see e.g. here: https://github.com/mosra/magnum#supported-platforms

2. Hooking up to a native window system is a well-supported scenario -- the Application classes Magnum is providing are just convenience wrappers on top of that. At the very bottom, all that Magnum needs is some active OpenGL context. Here's documentation about that: http://doc.magnum.graphics/magnum/platform.html#platform-custom and here you can find a sample "bootstrap project" that shows how to hook into Qt, for example: https://github.com/mosra/magnum-bootstrap/blob/base-qt/src/MyApplication.cpp

3. Yes, Magnum is trying to be as thin layer as possible, so it won't impose any restrictions on what you can do. Feel free to open an issue or propose an improvement, if you would think some of the APIs are limiting you. Also, if the OpenGL wrapping layer is too restrictive or is missing some functionality, you are always able to use raw OpenGL calls, if you really need to. Interaction with the engine layer and things to be aware of are documented here: http://doc.magnum.graphics/magnum/opengl-wrapping.html#opengl-state-tracking There is also a helpful API mapping table: http://doc.magnum.graphics/magnum/opengl-mapping.html

4. 2D drawing is well supported, both in the math classes (2D matrix transformations, complex numbers...) as well as in the scene graph and asset management pipelines. We're trying hard in this direction :)

5. Yes, there is a scene graph. You are free to not use it, though, if you think some other scene graph library would be a better fit :) It's all modular -- use what you want, ignore/disable what you don't care about.

6. The core library (Corrade + Magnum) is self-contained with no external dependencies (except for OpenGL). Besides that, there are numerous additional plugins for image import/export, scene loading, text rendering etc. -- you can use them if you want, but you don't have to. Because of the external dependencies, these are in a separate plugins repository: https://github.com/mosra/magnum-plugins

7. The core is focused just on rendering, yes. I was using this recently in a project that was all about GPU data processing and there we used basically just the OpenGL wrapping layer in an offscreen context, so I made sure that the project can be stripped down to just that and nothing else. However, because the project is used by game developers as well, there is a tiny OpenAL wrapper API and also stuff like Bullet Physics integration -- but these are contained in additional repositories. So if you don't need these, they won't bother you.

8. This is on the roadmap, yes. The initial plan is to remove the implicit dependency on OpenGL and make it optional so it is possible to implement other backends (or use Magnum with your own direct-to-metal code).

9. (From the other e-mail) Patches and bugreports are very welcome! We also have a very friendly project chat over at https://gitter.im/mosra/magnum -- if you are not sure that a thing you are seeing is really a bug or if you would be planning to contribute something bigger (or request a bigger feature), it's always good to discuss it first. The community over there is also very helpful to answer questions or give hints how to do something easier.

Besides all that, I'm now building a proper project website with feature overview, interactive WebGL demos and also a blog in order to make the project more approachable and to have some official channel for updates and announcements.

Regards
mosra

______________________________________________________________
> Od: andy.s...@gmail.com
> Komu: Magnum C++/OpenGL Graphics Engine <magnum...@googlegroups.com>
> Datum: 22.06.2017 19:30
> Předmět: [magnum] Evaluating magnum as a graphics backend for our project

>
>Hi All,
>
>We're evaluating using Magnum as a possible graphics backend for our
>real-time physics simulation project, and I've got a few questions:
>

>* We suport Mac, Windows and Linux, how good is cross-platform support with
>Magnum?
>

>* How easy is it to hook up Magnum to an existing native window, i.e. say
>on Windows, I create a new Win32 window, or on Mac I create a Cocoa window,
>is it possible to hook up Magnum to that window. I know that I'll have to
>grab the window events (mouse, resize, etc...) in my app and forward them
>to Magnum, that's not a big deal. We'll be using the native toolkit on each
>platform for the gui, i.e. WPF on Windows, Cocoa on Mac and GTK on Linux,
>so it's important that we can hook up our rendering code to native windows.
>

>* Much of our application will entail displaying highly dynamic deformable
>elastic surfaces and particle systems with programmatically generated
>textures, do you thing Magnum is a good fit?
>

>* We also plan to do a bit of 2D drawing (objects in a tree structure), I
>saw that 2D is also well supported in Magnum, so this looks promising.
>

>* I saw that Magnum has a scene graph API, that's good for us, because part
>of what we'll be doing will be constructive solid geometry, similar to
>OpenSCAD, http://www.openscad.org, and a scene graph we think is a good way
>to represent this kind of geometry.
>

>* From looking at the Magnum code, it looks like there are no 3rd party
>dependencies. This is very appealing, as maintaining dependencies is a
>giant pain.
>

>* It also looks like Magnum is just focused on rendering, and does not do
>physics, audio, etc... This too is very appealing to us, as we're looking
>for just a back end for rendering.
>

>* It would appear that Apple, in their infinite wisdom (sarcasm) is slowly
>deprecating OpenGL in favor of metal. In the future, do you think Magnum
>could have different backends (metal, directx)?
>

>Thanks,
>-- Andy
>
>--
>You received this message because you are subscribed to the Google Groups "Magnum C++/OpenGL Graphics Engine" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to magnum-engin...@googlegroups.com.
>To post to this group, send email to magnum...@googlegroups.com.
>Visit this group at https://groups.google.com/group/magnum-engine.
>For more options, visit https://groups.google.com/d/optout.
>
>

[Vladimír Vondruš]

Hi!

(Somehow the google groups thing doesn't show this message in the UI anymore, so I'm replying via e-mail. Not sure what's wrong there, I hope at least this message gets in.)

Thank you for the appreciation! That's quite some motivation boost :)

Plugins -- maybe there's just some misunderstanding. Let me explain: it's either dynamic plugins, which you don't link explicitly to at all (in fact, you *can't* link to them), but they are instead found (or tried to be found) on predefined paths on the filesystem and then loaded using dlopen(). The predefined path is coming from CMake variable MAGNUM_PLUGINS_DIR that you can change easily from CMake and also depends on whether you have a Debug or Release build. Or there are static plugins (compiled as static libraries), that you *do* explicitly link to. But, in addition to that, one also needs to explicitly import them from the code, because otherwise the static linker just doesn't see any reason to link the library in. That's done with the CORRADE_IMPORT_PLUGIN() macro. Here's a documentation that hopefully explains everything in enough detail: http://doc.magnum.graphics/magnum/plugins.html#plugins-static (if it doesn't or you find something wrong/confusing, please tell me
how to improve it -- feedback on the docs is very appreciated).

Great to read about the student joining -- all contributions are welcome, especially examples.

Hearing about nanogui for the first time -- looks nice, except for the dependencies, yeah :) Just FYI, if this would be maybe an easier way, there's already a port of "Dear ImGUI" ( https://github.com/ocornut/imgui ) for Magnum at https://github.com/denesik/MagnumImguiPort -- just a rough version, though. The plan is to integrate it in the magnum-integration repository, but it needs quite some work with automated tests, docs etc.

Oh and I'm also working on a "builtin" UI library for Magnum -- it's in the extras repo here: https://github.com/mosra/magnum-extras and here's a tiny WebGL 2 demo: http://magnum.graphics/tmp/ui/ . This one is trying a bit different approach to all the other libraries, trying to be very efficient at render time. It was made as a "minimum viable product" for an internal project at a company I was working for until now, so the documentation is lacking a bit and it's quite basic on features. I will be extending it more soon so it can be used in the example code and elsewhere.

Regards
mosra

______________________________________________________________
> Od: Andy Somogyi <andy.s...@gmail.com>
> Komu: Vladimír Vondruš <mo...@centrum.cz>
> Datum: 24.06.2017 22:11
> Předmět: Re: [magnum] Evaluating magnum as a graphics backend for our project
>
> CC: <magnum...@googlegroups.com>
>Hi all
>
>Magnum looks very very promising, and I think this is most like the direction I’ll go with.
>
>Things I like:
>
>* active development and community
>* very smart design, I really like how meshes / shaders are handled.
>* small, and relatively easy to step through, debug and understand. This is big one, because that means I can actually fix things it (if need be).
>* modularity is nice.
>
>I’ve created a self-contained magnum-examples, that uses git submodules to include magnum, corrade and magnum-examples at:
>
>https://github.com/AndySomogyi/magnum-bootstrap/tree/base
>
>I’m having a few issues with dynamic libraries and plugins on MacOS. It build fine either way, however, I can’t seem to get dynamic linking to work when I create CMake makefile build, issue with @rpath not found, however dynamic linking works fine with Xcode builds. This is something I’ll have to look closer into. It’s not really a big deal for me, and I only plan on using static linking.
>
>I’ve not been able to get static plugins to work with the examples. I’ve added
>
>target_link_libraries(magnum-textured-triangle
> Magnum::Application
> Magnum::Magnum
> Magnum::TgaImporter)
>
>Seems to build OK, but fails with:
>
>"PluginManager::Manager::load(): plugin TgaImporter is not static and was not found in lib/magnum-d/importers"
>
>I’m presently stepping through this code to see what’s going on. When built statically, stepping into AbstractManager.cpp here
>
>
> 67 auto AbstractManager::initializeGlobalPluginStorage() -> GlobalPluginStorage& {
> 68 static GlobalPluginStorage* const plugins = new GlobalPluginStorage;
> 69
> 70 /* If there are unprocessed static plugins for this manager, add them */
> 71 if(staticPlugins()) {
>-> 72 for(StaticPlugin* staticPlugin: *staticPlugins()) {
> 73 /* Load static plugin metadata */
> 74 Resource r("CorradeStaticPlugin_" + staticPlugin->plugin);
>
>it gets to line 71, but never enters the loop to processes static plugins, which tells me that the static plugins are not loading correctly.
>
>In resoruce_TgaImporter.cpp, if I put a breakpoint on line 24:
>
> 22 int resourceInitializer_TgaImporter();
> 23 int resourceInitializer_TgaImporter() {
>-> 24 Corrade::Utility::Resource::registerData("CorradeStaticPlugin_TgaImporter", 1, resourcePositions, resourceFilenames, nullptr);
> 25 return 1;
> 26 } CORRADE_AUTOMATIC_INITIALIZER(resourceInitializer_TgaImporter)
>
>It never stops there, indicating the static constructor never gets called.
>
>On a side note, I’ve got a student who’s going to work for me over the summer, I think I’m going to have him create some more examples with Magnum, and work on writing up some more docs. Another I think interesting small project I could have him work on is I’ve taken a look at nanogui, a rather nice, simple OpenGL GUI:
>
>https://github.com/AndySomogyi/nanogui
>
>Unfortunately, it seems to be abandoned by it’s maintainers, and one of the issues I have with it is that it has a lot of dependencies, particularly on Eigen. Magnum has literally everything nanogui needs to work, it would be possible to port nanogui to depend only on Magnum.

[Andy Somogyi]

Got the message just fine. I (after reading the docs which I should have in the first place :) ) found out about CORRADE_IMPORT_PLUGIN. 

I’ve got the examples working with static plugins, though I had to fiddle with it a bit. Basically the issue is how the CORRADE_IMPORT_PLUGIN expands, in that it only works when placed in the global namespace. Is a super quick hack just to get things working, I wrote a global namespace init_plugins() function, and placed the macro inside it, and call this function from the TexturedTriangleExample ctor, because of the MAGNUM_APPLICATION_MAIN macro: 

MAGNUM_APPLICATION_MAIN(Magnum::Examples::TexturedTriangleExample)

I know there’s a nice way to get both static and dynamic plugins to work in the magnum_examples project, I just haven’t fiddled with it yet. 

In any case, what I’m working on is a simulation engine like the attached image. I’m currently writing a paper on a new graph data structure based on the idea of ‘partial faces’ that enables these kinds of sims. You can see from the attached image that the graph data struct needs to efficiently keep track of a lot of connectivity info, especially as  compartments are created/destroyed at runtime based on the physics that acts on them.  The sim engine will store most of it’s state in this graph structure, and it will then generate set of indices and faces (the could change potentially every time step), then slam these indices and faces into a Magnum Mesh, and have Magnum do the rendering. 

Basic idea I have for reading initial conditions is this:

* store a set of cell centers as a point set in collada

* use Magnum’s collada reader to get a MeshData3D struct (that contains the point set)

* use a Voronoi tesselator (I have one) to generate a indexed face set from this point set. 

* use the indexed face set to initialize the sim engine graph. 

* run the sim engine, and each time step, sim engine slams the updated indices and faces to Magnum. 

Anyways, I’ve spent a good couple weeks looking at a bunch of different graphics engines, and Magnum seems to be the best choice, I’m going to put together a little writeup on my explorations / and reasons I choose Magnum and post it on my site. 

[Vladimír Vondruš]

Regarding COLLADA -- the importer was done in quite early stages of the engine development and it depends on Qt, which you might not like in the long run. There is a new, alternative, COLLADA importer being worked on right now, which will be using Assimp instead (related WIP PR, if you want to subscribe for notifications there: https://github.com/mosra/magnum-plugins/pull/31 ). Besides that, I'm personally pushing for the OpenGEX ( http://opengex.org/ ) format, which aims to be a cleaner, much better manageable alternative to COLLADA. We have a custom importer for it, which doesn't have any external dependencies. Similar case is with the good ol' OBJ format, we have a dependency-less importer for it.

Looking forward to the writeup and what you achieve with this. It all looks very interesting, will be following closely.

Regards
mosra

______________________________________________________________
> Od: Andy Somogyi <andy.s...@gmail.com>

> Komu: Magnum C++/OpenGL Graphics Engine <magnum...@googlegroups.com>

> Datum: 25.06.2017 01:11

> Předmět: Re: [magnum] Evaluating magnum as a graphics backend for our project
>

> CC: <andy.s...@gmail.com>

><https://lh3.googleusercontent.com/-6-5eXsD1tAA/WU7xoyt9c-I/AAAAAAAAAis/oIqd10EOWmgHSiUEoVnelw-SZLqo3Oz8ACLcBGAs/s1600/sim2.jpg>

>
>
>On Saturday, June 24, 2017 at 4:52:51 PM UTC-4, mosra wrote:
>>

>> > Od: Andy Somogyi <andy.s...@gmail.com <javascript:>>
>> > Komu: Vladimír Vondruš <mo...@centrum.cz <javascript:>>

>> > Datum: 24.06.2017 22:11
>> > Předmět: Re: [magnum] Evaluating magnum as a graphics backend for our
>> project
>> >

>> > CC: <magnum...@googlegroups.com <javascript:>>

>> >>> Od: andy.s...@gmail.com <javascript:>

>> >>> Komu: Magnum C++/OpenGL Graphics Engine <magnum...@googlegroups.com

>> <javascript:>>

>> an email to magnum-engin...@googlegroups.com <javascript:>.

>> >>> To post to this group, send email to magnum...@googlegroups.com

>> <javascript:>.

[Andy Somogyi]

Ah, good to know about the current importer. 

I'll just go ahead and use AssImp directly in my code to read assets and generate a MeshData3D directly. 

The more long-term goal of the Mechanica language I'm developing is to be able to represent geometry directly in the language, in addition to importing external file formats like OpenGEX and so forth. 

On the short term, my goal is to get this mesh data structure and dynamics compartment simulation engine working in the shortest time possible so I can get a paper published on it. Short term, really all I need is just a simple way to read point sets from, and I think AssImp is the quickest way to accomplish this. Plus, reading them myself lets me get a better understanding of the code.  

[Andy Somogyi]

[Vladimír Vondruš]

Just FYI: it's not *mandatory* to use the MeshData3D structure at all. It's there just to cover (most of) the possible data layout variants and so there are some trade-offs involved (such as indices being always 32bit etc.). I guess you know how exactly your data are structured and since you want to use AssImp directly anyway, you might achieve way more flexibility if you would fill the vertex/index buffers directly the way you need, instead of having the MeshData3D abstraction in between.

Just a suggestion, though :)

______________________________________________________________
> Od: Andy Somogyi <andy.s...@gmail.com>
> Komu: Magnum C++/OpenGL Graphics Engine <magnum...@googlegroups.com>

> Datum: 26.06.2017 18:44

> Předmět: Re: [magnum] Evaluating magnum as a graphics backend for our project
>
> CC: <andy.s...@gmail.com>

>Ah, good to know about the current importer.
>
>I'll just go ahead and use AssImp directly in my code to read assets and
>generate a MeshData3D directly.
>
>The more long-term goal of the Mechanica language I'm developing is to be
>able to represent geometry directly in the language, in addition to
>importing external file formats like OpenGEX and so forth.
>
>On the short term, my goal is to get this mesh data structure and dynamics
>compartment simulation engine working in the shortest time possible so I
>can get a paper published on it. Short term, really all I need is just a
>simple way to read point sets from, and I think AssImp is the quickest way
>to accomplish this. Plus, reading them myself lets me get a better
>understanding of the code.
>
>On Sunday, June 25, 2017 at 7:15:48 AM UTC-4, mosra wrote:
>>

>> Regarding COLLADA -- the importer was done in quite early stages of the
>> engine development and it depends on Qt, which you might not like in the
>> long run. There is a new, alternative, COLLADA importer being worked on
>> right now, which will be using Assimp instead (related WIP PR, if you want
>> to subscribe for notifications there:
>> https://github.com/mosra/magnum-plugins/pull/31 ). Besides that, I'm
>> personally pushing for the OpenGEX ( http://opengex.org/ ) format, which
>> aims to be a cleaner, much better manageable alternative to COLLADA. We
>> have a custom importer for it, which doesn't have any external
>> dependencies. Similar case is with the good ol' OBJ format, we have a
>> dependency-less importer for it.
>>
>> Looking forward to the writeup and what you achieve with this. It all
>> looks very interesting, will be following closely.
>>
>> Regards
>> mosra
>>
>> ______________________________________________________________

>> > Od: Andy Somogyi <andy.s...@gmail.com <javascript:>>

>> > Komu: Magnum C++/OpenGL Graphics Engine <magnum...@googlegroups.com
>> <javascript:>>

>> > Datum: 25.06.2017 01:11
>> > Předmět: Re: [magnum] Evaluating magnum as a graphics backend for our
>> project
>> >

>> > CC: <andy.s...@gmail.com <javascript:>>

[Andy Somogyi]

I’m actually using the Assimp importer from (https://github.com/mosra/magnum-plugins/pull/31), I copied it over and it seems to be working rather well so far. I had to tweak the FindAssimp a bit for OS X though.

The MeshData3D is working very well, this is the geometry exchange structure I’m going to use between many of my modules.

The basic flow I have for initial conditions is this:

[pointset_mesh.obj] -> AssimpImporter -> MeshData3D -> VoronoiTesselator -> MeshData3D -> SimulationEngine

Then at run time, the SimulationEngine populates a Mesh, responds to a Drawable3D::draw event and draws.