Update: Apr 09, 2019 Up­dat­ed project links at the bot­tom with sources for two more games.

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. Here, stu­dents use the fol­low­ing five-sid­ed pro­jec­tion in­stal­la­tion for their own project.

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 synchObject s that can hold a fixed size gener­ic da­ta type. Those synchObject s 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.

Project sources With a per­mis­sion from the stu­dents in­volved, we’ll be grad­u­al­ly pub­lish­ing sources to projects men­tioned in the above link — feel free to dig in and see how they were made. Here’s the first one, with more to fol­low: Time­Gun­VR by Kon­stantin Gomm and Sergey Mitchenko

Bowl­ing God by Se­bas­tian Per­al­ta Fried­burg

We Ar­rr Pi­rates by Yan­nick Weiss Please note the projects are pri­mar­i­ly built for the CAVE en­vi­ron­ment and thus can’t run with­out mod­i­fi­ca­tions. The code is al­so pro­vid­ed as-is, with­out any war­ran­ty, and the stu­dents have no obli­ga­tion to an­swer ques­tions or fix bugs 😉

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.