From October 2023 to October 2024 I interned at Qvisten Animation, the biggest animation studio in Norway. I interned in the XTND-department, which was formed for smaller commercial projects such as small games, museum installations and advertisements.
I was originally supposed to mainly shadow the team to learn from them, but after their Unity developer quit just a few weeks after I joined, I was quickly thrust into the role of actual developer. A part-timer and a junior still, but now the only developer on the team.
I would like to ramble on about three of the projects we worked on over the course of my year there, the challenges we faced, and what I learned both in terms of technical abilities and project management.
Nordpeis
The first project was a configurator for an oven company. This was meant to be akin to 3D previewing tools you see on certain furniture websites. They wanted an adjustable 3D environment, meant to run in-browser, with different lighting modes, and the ability to replace and adjust various oven models. Mobile-first, of course.
We quickly learned that WebGL was a poor choice for this. It simply did not run well enough in iOS-devices, nor even macbooks. We started in early december, but had to scrap most of our work by new years as we had to find another solution. We decided to use a ThreeJS-framework, speficially one called Needle Engine, which essentially let us use Unity more as a compiler than an actual engine. We’d make the scenes there, write the scripts in TypeScript (not C# as you’d expect in Unity), and then compile through the Needle Engine plugin, and it’d essentially output a ThreeJS-based project that no longer actually utilized Unity.
To say that there were complications from this would be an understatement, but we got into a flow eventually, and by the end of the project we had a happy customer. I also had to learn TypeScript for this, very much on the fly. I mostly have experience working with C++ and C#, I’ve briefly touched HTML and CSS, and barely glanced at JavaScript, so this was a bit of a hurdle, but overall not too bad of an experience.
Another hurdle involved inconsistencies in rendering from Unity and Needle. Certain forms of transparency, parts of the particle system, and some of the ways we did animation, were simply not compatible. We did have contact with the Needle team directly though, some of the issues we had were patched as a result of us contacting them and giving them access to the development build, which was a satisfying experience.
Expology / Skimuseet
The next major project was for a museum in Holmenkollen in Oslo. Their vision was an installation consisting of a round table with three or four touch screens equidistant from each other, and a projector showing a scene on the rest of the table. Said scene was supposed to change based on actions taken on the different screens.
The game we were asked to make was themed around the effects of climate change on different parts of Oslo, with some educational content on climate change in general. A scene where Nydalen is flooded, and a scene where Bjørvika is experiencing a serious drought, each of which would have three minigames, and picking one or the other would then cause the environment the projector was projecting to change for that screen’s section. Either the area would dry out, or flood, and the skier skiing around the table would have to either start swimming or walking.
We worked in Unreal Engine for this project. Hurdle number one came in the form of not knowing exactly how to optimize UE5. The documentation for optimizing performance is, in my opinion, rather lacking. The hardware they originally wanted us to work on was also inadequate; a mini computer without an actual graphics card, clearly meant for conference rooms and simple tasks, not running 3D games.
We did manage to get some better hardware eventually, but we were still somewhat limited. This was around when I learned that if you disable lumen, the very beautiful but rather heavy lighting system Epic made, in one place in UE5 that does not mean you’ve actually disabled it everywhere. That both the camera and the postprocessing volumes we used would have that setting and the engine not making it clear which actually mattered.
For the projector, I just made a simple unreal project, our 3D modeller made a table split in three with some different blend shapes, I made some animations to transition between states and some zones to decide which animations to play, and set up a simple file reader in the projector build and a file writer in the client builds. It’s a pretty elegant solution, but there’s not really that much more to say about it either.
Vestnes Kommune – Den Trondhjemske Postvei
Finally, I will talk about a VR project we did for Vestnes Kommune to educate about the way the mail used to be delivered in the mid-1800s around Trondheim.
I worked with a different 3D artist for parts of this, which caused a slight hiccup as he was used to creating 3D models for movies and commercials, not games, and certainly not VR games. This is when I really started to understand the impact of unnecessarily high polycounts and texture resolutions, as I had to make a lot of adjustments, and I gained a slight vendetta against megascan textures. I recognize the use cases, but attempting to do automatic LoD-adjustments with megascan textures is not always a clean process, and sometimes leaves behind some artifacts that I maybe still wish I had had the time to fix.
In addition to optimization issues (that I luckily had experience with now, following the Skimuseet project), I had to contend with figuring out physics with VR controllers now, particularly in regards to the rowing minigame and the mail sorting minigame.
The former is a fairly simple minigame, where you row across a river to deliver mail. Now, I wanted to make the physics somewhat realistic, ignoring the fact that you’re essentially sitting backwards in the boat so that you don’t need to crane your neck backwards to see where you’re going. I had to set up a system where the position and movement of the oars would affect the movement of the boat, and by proxy the player. Moving the VR camera was a challenge in itself, figuring out which part of the actor was actually willing to move and which would cause your body to leave your head behind, but getting the boat movements feeling natural was what really took a lot of work, and some spinning boat trips into space giving me motion sickness like I’ve only ever gotten on 11 hour drives to Brønnøysund before, within seconds. There was also the issue of getting the water to look good without being too heavy. I had to abandon my attempts to use Unreal’s water plugin, and had to opt for some moving textures instead. Not optimal, but it works well enough.
The latter of the two, the mail sorting game, mainly involved getting collision and ‘throwing’ physics working properly. Compared to the boat it was a piece of cake, but there are some peculiarities to consider when it comes to throwing something in VR, namely that it’s easy to let go ‘too late’, meaning you’ve started retracting your hand before letting go so the letter goes flying into your face. It might just be me, but I ‘flick’ when I throw things in real life quite often, which game physics aren’t necessarily build to handle. Setting some timing/input buffers and measurements on speeds generally fixed this fairly quickly.
Overall, I’m very happy with the time I had at Qvisten, even if I ended up with far more responsibility than I was supposed to have, and I’m forever grateful to the XTND team for having me and teaching me so much. I might’ve landed in something of a sink-or-swim situation, but I managed to swim this time, and I feel confident in calling myself a (junior) Unreal Developer now.
Thanks for continuously reading my ramblings, by the by.
Folio and Foliage 