Magnum 2020.06 released

Re­designed ge­om­e­try pipe­line to­geth­er with mas­sive ad­di­tions to im­porter plug­ins, new de­bug­ging, vi­su­al­iza­tion and pro­fil­ing tools, new ex­am­ples in­clud­ing flu­id sim­u­la­tion and ray­trac­ing, in­stanc­ing in builtin shaders and a gallery of cool projects to get in­spired from.

Big re­works take time to fer­ment prop­er­ly, which is why this re­lease comes more than six months af­ter the pre­vi­ous one, 2019.10. I dare to say this is the busiest re­lease of Mag­num yet, with work span­ning across sev­er­al ar­eas of the project. Fol­low­ing are re­lease high­lights, for a de­tailed changel­og that’s about 100 times big­ger please see links at the bot­tom.

New ge­om­e­try pipe­line

As­set im­port and ge­om­e­try pro­cess­ing is one of the cen­tral parts of Mag­num. For 2020.06 it got rewrit­ten from a rather ba­sic decade-old “toy en­gine” im­ple­men­ta­tion full of nest­ed std::vec­tors to an ef­fi­cient and flex­i­ble GPU-friend­ly de­sign that’s ready for new par­a­digms such as mesh shaders. I won’t be re­it­er­at­ing ev­ery­thing that went in­to it again in this an­nounce­ment, please go see the in-depth in­tro­duc­tion ar­ti­cle for de­tailed in­for­ma­tion:

New Geometry Pipeline in Magnum cover image
New Ge­om­e­try Pipe­line in Mag­num May 27, 2020
Flex­i­ble and ef­fi­cient mesh rep­re­sen­ta­tion, cus­tom at­tributes, new da­ta types and a ton of new pro­cess­ing, vi­su­al­iza­tion and an­a­lyz­ing tools. GPU-friend­ly ge­om­e­try stor­age as it should be in the 21st cen­tu­ry.

Let’s fork C++ fur­ther

The move away from std::vec­tor, which is vis­i­ble es­pe­cial­ly in the re­designed Mesh­Tools names­pace, means Mag­num had to pro­vide a re­place­ment. Con­tain­ers::Ar­ray is around for quite a while — but for the pur­pose of cer­tain im­porters and Prim­i­tives that can’t eas­i­ly know the fi­nal in­dex/ver­tex count be­fore­hand — it had to be ex­tend­ed to sup­port ar­bi­trary grow­ing, like std::vec­tor has.

Containers::Array<Color3> palette;

arrayAppend<MyFancyAllocator>(palette, {

A Con­tain­ers::Ar­ray in­stance isn’t tied to a par­tic­u­lar al­lo­ca­tor — and you can al­so switch to a dif­fer­ent al­lo­ca­tor at any point lat­er.

The de­sign is rather un­con­ven­tion­al in or­der to avoid the well-known short­com­ings of std::vec­tor, es­pe­cial­ly when it comes to cus­tom al­lo­ca­tors. The im­ple­men­ta­tion present in 2020.06 is still miss­ing ar­bi­trary in­ser­tion and dele­tion which is why it’s not ad­ver­tised in more de­tail yet — once that’s done, ex­pect a ded­i­cat­ed ar­ti­cle to­geth­er with bench­marks and com­par­i­son to com­mon im­ple­men­ta­tions. Un­til then, see Grow­able ar­rays for an in­tro­duc­tion.

One of the last re­main­ing pieces of STL that are hold­ing us back not as light­weight & flex­i­ble as I’d want them to be are std::strings. Af­ter the re­lease cut I de­cid­ed that new APIs are not go­ing to use those any­more, which means a re­place­ment is un­der­way. Ex­ist­ing APIs will get grad­u­al­ly port­ed away, sim­i­lar­ly as was done with std::vec­tor or std::unique_p­tr in the past. Of course, as al­ways, an opt-in com­pat­i­bil­i­ty of the new APIs with std::string / std::string_view will be pro­vid­ed — the goal is not to alien­ate users of stan­dard C++, the goal is to be flex­i­ble and pro­vide al­ter­na­tives.

Math and al­go­rithm good­ies

Be­cause the new Trade::Mesh­Da­ta APIs ex­pand­ed a lot on sup­port­ed ver­tex for­mats, the math li­brary re­ceived batch Math::pack­In­to() / un­pack­In­to() func­tions that al­low for ef­fi­cient con­ver­sion be­tween float­ing-point and 8-/16-bit packed or half-float types. When no con­ver­sion is need­ed, Util­i­ty::copy() from a new Util­i­ty/Al­go­rithms.h head­er gives you a std::mem­cpy() / std::copy() al­ter­na­tive that works on mul­ti­ple di­men­sions and sparse da­ta lay­outs as well.

ImageView2D src, dst;

Utility::copy(src.pixels().flipped<1>(), dst.pixels());

Mir­ror­ing an im­age — in an one­lin­er, with Con­tain­ers::StridedAr­rayView un­der­neath.

The Mesh­Tools li­brary, apart from be­ing adapt­ed for the re­designed work­flow, now con­tains Mesh­Tools::con­cate­nate() for join­ing mul­ti­ple mesh­es to­geth­er, or for ex­am­ple Mesh­Tools::gen­er­ateIndices() for con­vert­ing strips, loops or fans to plain in­dexed mesh­es.

What’s new in plug­ins

The more Mag­num gets used to im­port a in­creas­ing­ly broad range of datasets in var­i­ous for­mats, the more pre­vi­ous­ly un­han­dled cor­ner cas­es get dis­cov­ered and fixed.

  • The As­simpIm­porter now cor­rect­ly im­ports mul­ti-prim­i­tive mesh­es, pre­serves al­pha in ma­te­ri­als and ac­counts for Y up / Z up ori­en­ta­tion over­ride, if a file de­fines it.
  • All im­porters now im­port both base col­or and tex­ture in­stead of ei­ther one or the oth­er. In­ter­est­ing­ly, this was a lim­i­ta­tion that orig­i­nat­ed from the COL­LA­DA for­mat — the ear­ly Trade APIs and the now-gone ColladaImporter plug­in were mod­elled af­ter it, how­ev­er when re­view­ing this de­sign de­ci­sion it turned out that COL­LA­DA is ac­tu­al­ly the on­ly for­mat with such re­stric­tion and ev­ery oth­er for­mat (OBJ, glTF, OpenGEX, …) sup­ports com­bin­ing both.
  • TinyGlt­fIm­porter failed to im­port in­ter­leaved mesh­es. This was a short­cut done to make the ear­ly im­ple­men­ta­tion sim­pler. To my sur­prise, ap­par­ent­ly the vast ma­jor­i­ty of glTF mod­els is ex­port­ed de-in­ter­leaved and thus in­ef­fi­cient for the GPU, which ex­plains why this lim­i­ta­tion went large­ly un­no­ticed since the orig­i­nal plug­in re­lease in 2018.

Im­age im­porters weren’t left be­hind ei­ther — for­mats that sup­port it such as DDS or Ba­sis Uni­ver­sal now can im­port par­tic­u­lar mip lev­els us­ing Trade::Ab­strac­tIm­porter::im­age2DLev­el­Count() and the sec­ond pa­ram­e­ter of Trade::Ab­strac­tIm­porter::im­age2D(), with this be­ing prox­ied in­to all scene im­porters as well. Vague­ly re­lat­ed to this, Dev­Il­Im­ageIm­porter and StbIm­ageIm­porter can now im­port frames of an­i­mat­ed GIFs for a very crude video play­back.

Suit­ed main­ly for test­ing pur­pos­es, the whole Prim­i­tives li­brary is now ex­posed through a Prim­i­tiveIm­porter plug­in. This can be used for ex­am­ple to ex­pose builtin prim­i­tives to ex­ist­ing Importer-based pipe­lines with­out hav­ing to add new code path for each.

As men­tioned in the New Ge­om­e­try Pipe­line in Mag­num ar­ti­cle al­ready, there’s sev­er­al ad­di­tions and im­prove­ments that go to­geth­er with the new Trade::Mesh­Da­ta APIs:

Fi­nal­ly, there is a new scene con­vert­er plug­in in­ter­face, with MeshOp­ti­miz­er­SceneCon­vert­er and Stan­ford­SceneCon­vert­er be­ing the first two plug­ins im­ple­ment­ing it. Apart from that, im­age im­porters now have a sim­ple IcoIm­porter for Win­dows *.ico files and there’s (al­so a very triv­ial) StlImporter for bi­na­ry STL files, com­mon­ly used in 3D print­ing.

All im­porter and con­vert­er plug­ins re­ceived a flag to en­able ver­bose out­put, which is al­so ex­posed as a --verbose op­tion in the mag­num-im­age­con­vert­er, mag­num-scenecon­vert­er and mag­num-play­er util­i­ties. The plug­ins use that to no­ti­fy you about longer-run­ning op­er­a­tions or pro­cess­ing stats. It’s prob­a­bly most help­ful in case of As­simp, which likes to crash or mis­be­have on cer­tain files.

Builtin shad­er im­prove­ments, new vi­su­al­iza­tion tools

Per­haps the most sig­nif­i­cant shad­er ad­di­tion is in­stanc­ing sup­port in Shaders::Phong and Shaders::Flat — while in­stanc­ing alone was sup­port­ed in the GL li­brary since 2014, the builtin shaders didn’t im­ple­ment this func­tion­al­i­ty un­til now. For show­case, the Bul­let Physics and Box2D ex­am­ples are now reim­ple­ment­ed us­ing in­stanc­ing, each of them us­ing just a sin­gle draw call for the whole scene. Try them out on­line:

Box2D example screenshot
Box2D Ex­am­ple we­bgl1 physics in­stanc­ing
Builds a pyra­mid out of cubes and al­lows you to de­stroy it af­ter.
Bullet Physics example screenshot
Bul­let Physics Ex­am­ple we­bgl1 physics in­stanc­ing
Shows a ro­tat­ing ta­ble full of cubes that you can shoot down.

Com­ple­ment­ing the glTF KHR_­tex­ture_­trans­form ex­ten­sion sup­port, there’s now Shaders::Phong::set­Tex­ture­Ma­trix() to­geth­er with abil­i­ty to have in­stanced tex­ture off­set, and the same in Shaders::Flat.

With tan­gent and nor­mal map im­port be­ing done, Shaders::Phong nor­mal map sup­port added in 2019.10 can fi­nal­ly be ful­ly uti­lized. This is close­ly tied with Shaders::MeshVi­su­al­iz­er3D now be­ing able to vi­su­al­ize not just wire­frame but al­so tan­gent, bi­tan­gent and nor­mal di­rec­tion — very use­ful for de­bug­ging those dread­ed light­ing is­sues.

Shaders::Phong / Shaders::Flat can now out­put al­so per-ver­tex Ob­ject ID at­tribute, which means Shaders::MeshVi­su­al­iz­er3D can vi­su­al­ize that one as well, to­geth­er with ver­tex and prim­i­tive ID. This goes hand-in-hand with a new De­bug­Tools::Col­orMap names­pace that in­cludes al­so the very rec­og­niz­able Tur­bo col­ormap by An­ton Mikhailov.

Cer­tain GL driv­ers con­tin­ue to be a hot mess

Even if all oth­er new fea­tures shown here wouldn’t be a con­vinc­ing rea­son for you to up­grade, you’ll def­i­nite­ly want to pick up these three work­arounds for bet­ter driv­er com­pat­i­bil­i­ty:

  • A hard-to-re­pro­duce syn­chro­niza­tion bug on In­tel Win­dows driv­ers makes the AR­B_­di­rec­t_s­tate_ac­cess ex­ten­sion ba­si­cal­ly un­us­able for any­thing re­lat­ed to buf­fers or VAOs. Usu­al­ly man­i­fest­ed as flick­er­ing in ImGui-based apps. A sub­set of this work­around was done for 2019.10 al­ready but due to its se­mi-ran­dom na­ture it didn’t cov­er all cas­es. This work­around aban­donds all hope and com­plete­ly dis­ables DSA for af­fect­ed code paths on these driv­ers.
  • In­tel Win­dows driv­ers don’t re­al­ly re­spect ex­plic­it uni­form lo­ca­tions but in­stead on­ly take it as a very vague sug­ges­tion. This bug was most cer­tain­ly al­so present since for­ev­er, but on­ly be­came vis­i­ble af­ter the lat­est ad­di­tions of tex­ture trans­form, nor­mal maps and in­stanc­ing to builtin shaders, which caused the uni­form lo­ca­tions to be any­thing but a con­tigu­ous in­creas­ing se­quence. Since there’s no ap­par­ent rhyme or rea­son in which the driv­ers al­lo­cate uni­form IDs, so­lu­tion was to dis­able the AR­B_­ex­plic­it_u­ni­for­m_­lo­ca­tion on In­tel Win­dows driv­ers al­to­geth­er.
  • It’s hard to find bugs in driv­ers that are ca­pa­ble of very lit­tle, but even then — while this bug was prob­a­bly present ev­er since Ap­ple rewrote their (dep­re­cat­ed) GL 4.1 driv­er on top of Met­al, it got in­de­pen­dent­ly dis­cov­ered by two dif­fer­ent users on­ly re­cent­ly. When GL::Buf­fer­Tex­ture is bound, it caus­es all buf­fer mod­i­fi­ca­tions to crash due to what I as­sume is cor­rup­tion of in­ter­nal driv­er state. The work­around avoids the crash by un­bind­ing the tex­ture when up­dat­ing or map­ping a GL::Buf­fer.

For your amuse­ment, the list of all cur­rent OpenGL driv­er work­arounds is in the doc­u­men­ta­tion.

But there are al­so some non-neg­a­tive GL news, even

Last 50 frames:
  Frame time: 16.65 ms
  CPU duration: 14.72 ms
  GPU duration: 10.89 ms
  Vertex fetch ratio: 0.24
  Primitives clipped: 59.67 %

An ex­am­ple where pipe­line statis­tic queries can be use­ful. Out­put from De­bug­Tools::Frame­Pro­fil­er.

Work­ing on the ge­om­e­try pipe­line and large datasets re­quired me to do var­i­ous mea­sure­ments, which led to a new GL::Pipe­lineS­tatis­tic­s­Query class. It ex­pos­es the AR­B_pipeline_s­tatis­tic­s_­query ex­ten­sion which doesn’t pro­vide re­al­ly much, but it’s at least some­thing — and sad­ly the on­ly non-pro­pri­etary way to get any stats on NVidia driv­ers. A new De­bug­Tools::Frame­Pro­fil­er class us­es those queries to give you a easy-to-in­te­grate per-frame pro­fil­ing.

Apart from that, var­i­ous tiny bits and pieces such as clip­ping plane sup­port were added, most­ly on-de­mand based on needs of var­i­ous users. See the changel­og links at the bot­tom for the full list.

One quite mi­nor but wide­ly ap­pre­ci­at­ed change was turn­ing mesh.draw(shader) in­to shader.draw(mesh). The orig­i­nal was a re­sult of how the API evolved over the years, which is why I was blind to its coun­ter­in­tu­itive­ness un­til it was fi­nal­ly point­ed out to me. A good take­away from that is — if you see any­thing in Mag­num APIs that feels strange or un­nec­es­sar­i­ly com­pli­cat­ed, please com­plain, no mat­ter how “noob” or in­ex­pe­ri­enced you might feel. Feed­back like this mat­ters a lot, and if I nev­er hear it, I might nev­er dis­cov­er the prob­lem.

One in­ter­est­ing project that is mak­ing great progress re­cent­ly is Mesa’s Zink OpenGL-over-Vulkan driv­er. Sta­ble Mesa 20.1 doesn’t have it en­abled by de­fault yet and there it’s just at GL 2.1, but lat­est com­mits al­ready bring it up to 3.1 sup­port. Af­ter fix­ing some bad as­sump­tions in con­text cre­ation rou­tines in or­der to make pure GL 2.1 con­texts work again, Mag­num can now work with Zink as well.

Ap­pli­ca­tion im­prove­ments

Thanks to a joint ef­fort from sev­er­al con­trib­u­tors, Plat­form::GlfwAp­pli­ca­tion and Plat­form::Sdl2Ap­pli­ca­tion now sup­port cur­sor man­age­ment, which is al­so used by the ImGui­In­te­gra­tion li­brary. Both ap­pli­ca­tions can now al­so set win­dow icon, and if you are on Win­dows, you can use it to­geth­er with the new IcoIm­porter to use one file to set an ex­e­cutable icon and a win­dow icon as well, op­tion­al­ly al­so pro­vid­ing sev­er­al res­o­lu­tions to let the OS choose from.

The ImGui­In­te­gra­tion li­brary was switched to use builtin Shaders::Flat2D in­stead of a cus­tom shad­er, which re­moved quite some code and made it work on We­bGL 1 as well. This was pos­si­ble thanks to builtin shaders re­ceiv­ing ver­tex col­or sup­port in the 2019.10 re­lease.

Win­dow­less apps, which are com­mon­ly used for da­ta pro­cess­ing or test­ing, got ex­tend­ed to sup­port con­text shar­ing. The Plat­form::Win­dow­lessEglAp­pli­ca­tion sup­ports EGL de­vice se­lec­tion through the --magnum-device op­tion since 2019.10 and now it sup­ports al­so --magnum-cuda-device for fil­ter­ing on­ly CU­DA de­vices, if you’re run­ning on a ma­chine with NVidia GPUs.

If you don’t use the builtin ap­pli­ca­tion wrap­pers, there’s a new base-gtk­mm boot­strap project to get you start­ed us­ing GTK­mm, join­ing base-wxwid­gets added in the pre­vi­ous re­lease, and with a QtQuick boot­strap be­ing worked on for the next.

A gi­ga­ton of cool new ex­am­ples

The Con­trib­u­tor of the Year award goes to Nghia Truong — sub­mit­ting five ex­treme­ly in­ter­est­ing ex­am­ples, each im­ple­ment­ing a dif­fer­ent al­go­rithm com­plete­ly from scratch, with many more good­ies promised. All of them are now avail­able as We­bGL demos, feel free to try them out:

2D Fluid Simulation example screenshot
2D Flu­id Sim­u­la­tion Ex­am­ple we­bgl2 physics ui
2D flu­id sim­u­la­tion us­ing the APIC method.
3D Fluid Simulation example screenshot
3D Flu­id Sim­u­la­tion Ex­am­ple we­bgl2 physics ui
SPH flu­id sim­u­la­tion with a dy­nam­ic bound­ary.
Ray Tracing example screenshot
Ray Trac­ing we­bgl1
Sim­ple it­er­a­tive CPU ray trac­ing.
Octree example screenshot
Oc­tree we­bgl1 physics in­stanc­ing
Loose oc­tree for ac­cel­er­at­ing col­li­sion de­tec­tion
Arc Ball example screenshot
Ar­cBall Cam­era Ex­am­ple we­bgl2
Im­ple­men­ta­tion of Ken Shoe­make’s ar­cball cam­era with smooth nav­i­ga­tion fea­ture.
WebXR example screenshot
We­bXR Ex­am­ple we­bgl1 we­bxr
A ba­sic demon­stra­tion of how to use the Em­scripten We­bXR li­brary with Mag­num.

Apart from these, the orig­i­nal We­b­VR API got ob­so­let­ed by We­bXR, and so fol­lows our ex­am­ple, linked above — cur­rent­ly you can try it out in Chrome, and it al­so works in the An­droid brows­er.

Buildsys­tem im­prove­ments

Clang-CL is now an of­fi­cial­ly sup­port­ed and test­ed com­pil­er, in case you want to build for Win­dows but hate both nei­ther MinGW nor MSVC suits your needs. Some work was done for MinGW Clang sup­port but se­ri­ous un­tack­led is­sues still re­main, so GCC is still the on­ly sup­port­ed com­pil­er un­der MinGW.

Be­cause de­pen­den­cy man­age­ment is hard un­less you have a sys­tem-wide pack­age man­ag­er or Vcp­kg do­ing the work for you, cer­tain de­pen­den­cies such as Ope­nAL, Ba­sis Uni­ver­sal, meshop­ti­miz­er or ImGui can now be bun­dled as CMake sub­pro­jects. In ad­di­tion, var­i­ous fix­es were done in CMake Find mod­ules for stat­i­cal­ly-linked de­pen­den­cies that are com­mon­ly used when dis­tribut­ing project bi­na­ries.

To bet­ter track ver­sions of your de­pen­den­cies, all Mag­num projects now con­tain a version.h head­er con­tain­ing the ex­act com­mit the li­brary was built from.

Builtin CMake An­droid sup­port, which got bro­ken with the in­tro­duc­tion of NDK r19, is work­ing with CMake 3.16+ again, on­ly with min­i­mal work­arounds. Build­ing doc­u­men­ta­tion and the An­droid trou­bleshoot­ing guide were up­dat­ed to re­flect this fact.

New and im­proved tools

Go­ing with the new Trade::Ab­stractSceneCon­vert­er plug­in in­ter­face, there’s a mag­num-scenecon­vert­er util­i­ty as well. Cur­rent­ly the on­ly sup­port­ed out­put is PLY (through Stan­ford­SceneCon­vert­er) and the amount of op­er­a­tions is lim­it­ed, but this area is go­ing to ex­pand over time, like it did for im­age con­ver­sion plug­ins. In ad­di­tion the tool al­so ex­pos­es var­i­ous Mesh­Tools al­go­rithms such as du­pli­cate re­moval or at­tribute fil­ter­ing.

mag­num-im­age­con­vert­er can now con­sume and pro­duce raw pix­el da­ta of a spec­i­fied for­mat, which is use­ful when deal­ing with low-lev­el pipe­lines that don’t un­der­stand high-lev­el im­age con­tain­er for­mats. For da­ta di­ag­nos­tic and de­bug­ging, both mag­num-im­age­con­vert­er and mag­num-scenecon­vert­er learned a new --info op­tion that prints in­for­ma­tion about file con­tents, pix­el / ver­tex for­mats and da­ta lay­out.

The mag­num-play­er util­i­ty is heav­i­ly used for in­ter­nal test­ing and thus ab­sorbed ba­si­cal­ly all new en­gine ad­di­tions — it can dis­play nor­mal maps, ex­pos­es all vi­su­al­iza­tion fea­tures of Shaders::MeshVi­su­al­iz­er3D and you can run De­bug­Tools::Frame­Pro­fil­er with the P key. On­ly the na­tive app has the new ad­di­tions right now, the web ver­sion wasn’t up­dat­ed yet.

Mag­num Project Spot­light

To give you an idea what Mag­num is used for, here’s a se­lec­tion of cur­rent­ly ac­tive or re­cent­ly pub­lished Mag­num-based projects, with many more get­ting ready to ap­pear next. Pre­sent­ed in no par­tic­u­lar or­der:


An ad­dic­tive and col­or­ful Tetris-in­spired puz­zle game, run­ning in a brows­er. My high­est score so far is 63k, beat me!


A work-in-progress light­weight game en­gine with an em­pha­sis on us­abil­i­ty and per­for­mance.


GPU-based sculpt/an­i­mate ap­pli­ca­tion. Cur­rent­ly in al­pha.


Vhite Rab­bit’s yet-un­re­leased Web-fo­cused Game En­gine.


An N-body grav­i­ty sim­u­la­tor, cur­rent­ly in process of be­ing port­ed to Mag­num. This an­nounce­ment cov­er im­age is a still frame from one of the sim­u­la­tions.

Quadratic Approximation of Cubic Curves

A sim­ple de­gree re­duc­tion tech­nique for con­vert­ing piece­wise cu­bic splines in­to piece­wise qua­drat­ic splines that main­tain pa­ram­e­ter­i­za­tion and C^1 con­ti­nu­ity.


A sin­gle-file, im­me­di­ate-mode se­quencer wid­get for C++17, Dear ImGui and EnTT. Ex­am­ple pow­ered by Mag­num.


Gen­er­ates re­al­is­tic ar­range­ments of rigid bod­ies and pro­vides var­i­ous out­puts that can be used to train deep learn­ing mod­els.

mpFluid CAVE Front End

In­ter­ac­tive Ex­plo­ration and Com­pu­ta­tion­al Steer­ing in CAVE-like En­vi­ron­ments for High-Per­for­mance Flu­id Sim­u­la­tions. The CAVE-like en­vi­ron­ment was fea­tured pre­vi­ous­ly here.

If you have a project that you want to have men­tioned in the next Project Spot­light, let us know! For projects host­ed on GitHub don’t for­get to add the #mag­num tag to make them eas­i­er to dis­cov­er.

Full changel­og

There’s so much hap­pen­ing that this ar­ti­cle is, as al­ways, just a dis­tilled ver­sion of the changel­og — and I’m sure I for­got to men­tion some of the hid­den gems:

Up­dat­ing from pre­vi­ous ver­sions

If you use Home­brew, Arch­Lin­ux AUR or build your own *.deb pack­ages, the 2020.06 re­lease is al­ready avail­able there. Vcp­kg pack­age up­date is cur­rent­ly wait­ing for a merge in mi­cro­soft/vcp­kg#12211, MSYS pack­ages are al­most ready in msys2/MINGW-pack­ages#6641 and Arch­Lin­ux com­mu­ni­ty pack­age up­dates will fol­low short­ly. If you use Mag­num Sin­gles, you’re not for­got­ten ei­ther — up-to-date gen­er­at­ed sin­gle-head­er libs are on the check­list as well.

If you have your code al­ready us­ing the new Trade::Mesh­Da­ta APIs, con­grats — you’re 95% there. If not, the new re­lease should most­ly com­pile with your ex­ist­ing code, on­ly emit a lot of dep­re­ca­tion warn­ings where each will tell you what API to use in­stead.

Thank you

A sig­nif­i­cant por­tion of the work on Mag­num is be­ing done by ex­ter­nal con­trib­u­tors, and this re­lease is no ex­cep­tion — thanks, ev­ery­body (and apolo­gies to those I for­got):

Magnum 2019.10 released

The new re­lease brings Python bind­ings, Ba­sis Uni­ver­sal tex­ture com­pres­sion, im­proved STL in­ter­op­er­abil­i­ty, bet­ter Uni­code ex­pe­ri­ence for Win­dows users, a more ef­fi­cient Em­scripten ap­pli­ca­tion im­ple­men­ta­tion, sin­gle-head­er li­braries, new OpenGL driv­er work­arounds and much more.

Introducing Magnum Python Bindings

Dur­ing the past four months, Mag­num be­gan its ad­ven­ture in­to the Python world. Not just with some au­to­gen­er­at­ed bind­ings and not just with some au­to­gen­er­at­ed Sphinx docs — that sim­ply wouldn’t be Mag­num enough. Brace your­selves, this ar­ti­cle will show you ev­ery­thing.

page 1 | older articles »