News & Blog

An Engine to Power Virtual Worlds

In our last post, we men­tioned we were de­vel­op­ing a cus­tom game en­gine for our “Side Trip to Won­der­land” and “VR Toy­room”. Our Won­der­land En­gine gave us full con­trol of per­for­mance.
As a re­sult, per­for­mance was great: while VR games need to stay be­low 11 ms per frame to keep la­ten­cy low, VR Toy­room was at 4 ms on min­i­mum re­quired hard­ware for the Ocu­lus Rift CV1!
Our re­sult­ing game bi­na­ries would have been very small, com­pi­la­tion was very fast and the ed­i­tor was di­rect­ly in­te­grat­ed in­to Blender.

On the oth­er hand, de­vel­op­ment took in­cred­i­bly long. If we want­ed shad­ows, we had to im­ple­ment those our­selves in the en­gine first. If we had want­ed re­al time am­bi­ent oc­clu­sion, we would have had to im­ple­ment that to. In Un­re­al En­gine or Uni­ty you hit a check­box and you’re done.

Why not use Unity or Unreal Engine?

Our games are pret­ty sim­ple. They do not re­quire a lot of vis­ual fi­deli­ty nor elab­o­rate AI, net­work­ing or com­plex tex­ture stream­ing code. In ad­di­tion, since we de­vel­op ex­clu­sive­ly for vir­tu­al re­al­i­ty, there are a lot of post-pro­cess­ing fil­ters you want to avoid any­way:
Lens flares, vi­gnettes and depth of field for ex­am­ple try to em­u­late ef­fects which on­ly ap­pear with cam­eras, not with the hu­man eye. Mo­tion blur, if ap­plied to the en­tire screen, can even in­tro­duce mo­tion sick­ness.

In VR per­for­mance in king. The low­er the la­ten­cy of your game, the bet­ter the game will feel in VR and the eas­i­er it will be to cre­ate pres­ence and im­mer­sion. This even works with styl­ized or car­toony worlds, you do not even need pho­to re­al­is­tic ren­der­ing. This la­ten­cy is the time be­tween head mo­tion of a us­er un­til the im­age on the screen is up­dat­ed ac­cord­ing­ly. Goal is to have that at least be­low 20 ms, which is the thresh­old for “fool­ing your sub­con­scious­ness”.

When we start­ed VR de­vel­op­ment, “de­ferred ren­der­ing” was very pop­u­lar among game en­gines. It is a ren­der­ing tech­nique that al­lows you to ren­der many many light sources with­out huge per­for­mance im­pact. For VR, though, this tech­nique is less de­sir­able, since the head po­si­tion and ro­ta­tion are need­ed ear­li­er while ren­der­ing a frame, which in­creas­es la­ten­cy. See Ocu­lus blog post on this for fur­ther in­for­ma­tion. At the present day, though, Un­re­al En­gine caught up and pro­vides a For­ward Ren­der­er as an al­ter­na­tive to the De­ferred Ren­der­er.

Why *do* use Unreal Engine?

Un­re­al and Uni­ty pro­vide tools to get ev­ery­thing done for a sim­ple game ex­treme­ly quick­ly. En­tire pro­duc­tion pipe­lines are built around them, as­set man­age­ment and ver­sion­ing tools are in­te­grat­ed al­ready, there is sup­port for di­verse file for­mats and a healthy com­mu­ni­ty builds plug­ins to get them to do ba­si­cal­ly any­thing you want.

All in all, ev­ery­thing is there al­ready. You can fo­cus on cre­at­ing the game rather than the en­gine. Fea­tures like Blue­prints en­able you to quick­ly click to­geth­er game ideas, it makes game de­vel­op­ment al­most too easy.

We now start­ed a third project with Un­re­al En­gine to see how it goes (putting the oth­er two on hold for now). We had ba­si­cal­ly three op­tions: Un­re­al, Uni­ty and CryEngine. A quick sum­ma­ry of what led up to the fi­nal choice:
Since our de­vel­op­ers know C++ very well and Un­re­al En­gine pro­vides a C++ API, that was one of the most im­por­tant de­cid­ing fac­tors. View­ing Uni­ty’s source code is ex­pen­sive and even a sim­ple pro li­cens­es is not af­ford­able for a eight-head­ed 0-bud­get team. CryEngine does cur­rent­ly not sup­port An­droid which is re­quired when tar­get­ing mo­bile VR such as GearVR or Day­dream head­sets.

Warning, Technical: The Wonderland Engine

I spent alot of time on our en­gine, hence I will ded­i­cate a small para­graph to it in the hopes some­one reads it and thinks “Wow, hey, that is pret­ty cool!” ;)

Our game en­gine is fit­ting­ly named “Won­der­land En­gine”, since it is meant to pow­er the won­der­lands we as Vhite Rab­bit guide you to. The en­gine it­self is writ­ten in C++, based on Mag­num, an open source C++11/14 OpenGL graph­ics en­gine. Our ed­i­tor is writ­ten as an ad­don for the open source 3D cre­ation suite Blender, which al­lows our artists to cre­ate as­sets and then eas­i­ly view them di­rect­ly in the mod­el­ling tool (at least that’s the idea). Si­mul­ta­ne­ous­ly, we prof­it from the un­be­liev­ably fast start­up times of blender.

To man­age com­pile-time de­pen­den­cies, we wrote a cus­tom pack­age man­ag­er in python which al­lowed us to de­ploy bi­na­ries man­u­al­ly or even via git­lab-ci and pro­vide au­to­mat­ic up­dates to the team.

Ex­change of da­ta be­tween Blender and our en­gine is done us­ing the OpenGEXscene file for­mat us­ing a cus­tom ex­porter plug­in (which is open source!). In com­par­i­son to the of­fi­cial ex­porter, this one sac­ri­fices fea­tures we do not need, for speed, but al­so al­lows us to ex­port ex­ten­sions which con­tain prop­er­ties not sup­port­ed by the orig­i­nal spec­i­fi­ca­tion of the for­mat. This in­cludes physics ma­te­ri­als, au­dio prop­er­ties or par­ti­cle sys­tem set­tings for ex­am­ple.

In ad­di­tion, we can com­pile the en­gine and game projects through blender, which al­lows Artists to view their changes di­rect­ly in the game.

Our cus­tom en­gine al­lows our artists to “wish” for fea­tures, which can then be im­ple­ment­ed while still keep­ing per­for­mance re­al­ly re­al­ly good.
If you are in­ter­est­ed in fur­ther de­tails, go tweet at me @Squareys!