Last year, Mag­num was used to in­tro­duce stu­dents to vir­tu­al re­al­i­ty pro­gram­ming at the Lud­wig-Max­i­m­il­ians-Uni­ver­sität München — pow­er­ing a CAVE-like en­vi­ron­ment, a room-scale five-sid­ed pro­jec­tion in­stal­la­tion.

Teach­ing about vir­tu­al re­al­i­ty al­ways ben­e­fits from prac­ti­cal ex­pe­ri­ence. For that, a big part of the lec­ture Vir­tu­al Re­al­i­ty, host­ed at the Lud­wig-Max­i­m­il­ians-Uni­ver­sität München, open for stu­dents of both Mu­nich Uni­ver­si­ties, is to get hands on in­to their own VR project. This project has to run on the fa­cil­i­ties of the Vir­tu­al Re­al­i­ty and Vi­su­al­i­sa­tion Cen­tre (V2C) of the Leib­niz Su­per­com­put­ing Cen­tre (Leib­niz-Rechen­zen­trum, LRZ) of the Bavar­i­an Acad­e­my of Sci­ence and Hu­man­i­ties.1 Here, stu­dents use the fol­low­ing five-sid­ed pro­jec­tion in­stal­la­tion for their own project.

Five-sided projection installation

Im­age cred­it: Elis­a­beth May­er

Hav­ing past ex­pe­ri­ence with OpenSG, last year we de­cid­ed to use Mag­num as the graph­ics en­gine for the stu­dents to start with — and we will stick to it for this year as well. We were lucky to get Vladimír to vis­it us in Mu­nich and give an in­tro­duc­to­ry lec­ture on how to use Mag­num. In this lec­ture, the stu­dents got a gen­er­al over­view of how Mag­num is struc­tured and learned how to cre­ate their own ren­der­ing ap­pli­ca­tion us­ing the scene graph, the mod­el load­ing fea­tures and the in­put event sys­tem.

Al­though this yield­ed a great start­ing point, our five-sid­ed pro­jec­tion in­stal­la­tion re­quires that you code for a set­up that con­sists of 10 nodes that ren­der and one node that works as a mas­ter node. For that, we pro­vide our own small li­brary that helps to keep one ap­pli­ca­tion on those 10 nodes in sync.

The ap­pli­ca­tion must be built as two ex­e­cuta­bles — one for ren­der­ing, which runs on the ren­der nodes, and one that runs on the mas­ter node. We have for each a dis­tinct class with a dif­fer­ent set of fea­tures. The mas­ter node works as a syn­chro­niza­tion serv­er. That means da­ta is dis­trib­uted from here to each of the ren­der nodes. This da­ta can be track­ing da­ta, trans­for­ma­tions from in­ter­ac­tions or physic sim­u­la­tion as well as all oth­er kinds of in­puts or dy­nam­ics. For the ren­der nodes, the mas­ter node al­so func­tions as a syn­chro­niza­tion point for buf­fer swaps. This means that af­ter all ren­der­ing is fin­ished each node sends a re­quest to the mas­ter node and waits un­til it gets a re­sponse. The mas­ter node it­self does on­ly re­spond if all pre-de­ter­mined nodes have sent a re­quest. This way we can be cer­tain that each node is ren­der­ing the same scene with the same in­put da­ta.

The syn­chro­niza­tion li­brary it­self is based on Boost.Asio which pro­vides an ab­strac­tion lay­er to UDP and TCP net­work­ing. Based on this we fur­ther im­ple­ment­ed so called synchObjects that can hold a fixed size gener­ic da­ta type. Those synchObjects al­low to set da­ta on the mas­ter node and to syn­chro­nize them with all the pre-de­fined ren­der nodes us­ing udp mul­ti­cast.

In hind­sight, the big­gest chal­lenge for us was to pro­vide the stu­dents with a work­ing start­ing pack­age, com­prised of a Mag­num ex­am­ple that works on our in­stal­la­tions but al­so gives the stu­dents the pos­si­bil­i­ty to de­vel­op on their own com­put­ers, which might use Win­dows, a Lin­ux derivate or mac­OS. For this, it re­al­ly helped that Mag­num is in Home­brew, al­lows you to use Vcp­kg or to build your own Ubun­tu pack­age.

Our stu­dents could eas­i­ly start cre­at­ing their own projects us­ing Mag­num. The sheer amount of pos­si­bil­i­ties and the size of doc­u­men­ta­tion was both an ad­van­tage and a chal­lenge. A small ex­am­ple for this might be get­ting the ro­ta­tion ma­trix of a trans­for­ma­tion — while one might think us­ing the func­tion ro­ta­tion() as in

Matrix4 transformationMatrix;
Matrix3x3 rotMatrix = transformationMatrix.rotation();

is the ob­vi­ous choice, con­sult­ing the doc­u­men­ta­tion gives you the note that this func­tion as­serts that the trans­for­ma­tion is not skewed in any way and so you might rather con­sid­er us­ing the func­tion ro­ta­tion­Scal­ing() as in

Matrix4 transformationMatrix;
Matrix3x3 rotMatrix = transformationMatrix.rotationScaling();

How­ev­er, this al­so teach­es a valu­able les­son — read the doc­u­men­ta­tion!

What our stu­dents re­al­ly liked were all the de­bug­ging func­tion­al­i­ties, es­pe­cial­ly the De­bug class that sup­ports us­ing Debug{} << myData; for al­most any type. Fur­ther­more, hav­ing the Prim­i­tives li­brary, the built-in Shaders as well as the GL ab­strac­tion lay­er that does most of the te­dious work for you al­lowed our stu­dents to quick­ly de­vel­op their own ap­pli­ca­tions and try out dif­fer­ent ap­proach­es.

Over­all, we are very ex­cit­ed about all the dif­fer­ent projects our stu­dents de­vel­oped with Mag­num. The pho­tos pre­sent­ed above are from our Open Lab Day in De­cem­ber 2018 where our stu­dents pre­sent­ed their work to fam­i­ly, friends and the pub­lic.

^ The V2C at LRZ of­fers mod­ern tech­nolo­gies for vi­su­al­is­ing sci­en­tif­ic da­ta. This al­lows for a more rapid ad­vance­ment and sig­nif­i­cant en­rich­ment of sci­en­tif­ic knowl­edge. The abil­i­ty of sci­en­tists to un­der­stand their da­ta and dis­cov­er new in­ter­re­la­tions in them is vast­ly im­proved by the three di­men­sion­al, high-res­o­lu­tion da­ta pro­jec­tion on the Pow­er­wall, by the use of the five-sid­ed pro­jec­tion in­stal­la­tion, and by the in­ter­ac­tive nav­i­ga­tion pro­vid­ed in the V2C lead­ing to break­throughs in un­der­stand­ing and in­ter­pret­ing re­sults. In ad­di­tion to be­ing used in the nat­u­ral sci­ences and in tech­nol­o­gy, com­plex datasets in hu­man­i­ties and so­cial sci­ence re­search are al­so vi­su­alised us­ing the V2C, for in­stance in the fields of arts and mul­ti­me­dia, ar­chae­ol­o­gy, and ar­chi­tec­ture. A new LED-based Pow­er­wall ex­tends the V2C ca­pa­bil­i­ties with the lat­est tech­nol­o­gy.
Markus Wiedemann

About the author

Markus Wiede­mann is a sci­en­tist work­ing with, lec­tur­er teach­ing about and en­thu­si­ast ad­dict­ed to Vir­tu­al Re­al­i­ty. He is cur­rent­ly with the Vir­tu­al Re­al­i­ty and Vi­su­al­i­sa­tion Cen­tre of the Leib­niz Su­per­com­put­ing Cen­tre, lec­tur­er at the Lud­wig-Max­i­m­il­ians-Uni­ver­sität München and mem­ber of the Mu­nich Net­work Man­age­ment Team.

Guest Posts

Guest Posts

This is a guest post by an ex­ter­nal au­thor. Do you al­so have some­thing in­ter­est­ing to say? A suc­cess sto­ry worth shar­ing? We’ll be hap­py to pub­lish it. See the in­tro­duc­to­ry post for de­tails.