It has not been the most productive week. My husband celebrated his 40th birthday last weekend and being the fabulous wife I am, I gave him the best birthday gift of all – covid. After almost exactly 2 years of successfully evading it, we both succumbed, me on his birthday, and him a couple of days after. The major silver lining to all of this was that due to the military’s rules, he had to stay here in Canmore to ride out his 10-day isolation period. So, between coughing fits, brain fog, and enjoying an unusually extended bit of time with my husband,  I haven’t spent a great deal of time in front of the computer. Oh, and yesterday we thought we had a malfunctioning washing machine, so we spent most of the day taking that apart and putting it back together (we learned that 1. washing machines are surprisingly easy to take apart, 2. The 15-yr old washing machine we inherited when we moved in is actually still doing ok, so no unexpected $1000 purchase required, and 3. washing machines and dryers can get pretty disgusting after 15 years).

Although I didn’t make a bunch of progress on my project(s), I still have a stack of catch up posts to write. And, as mentioned in my first post, I owe some column inches to the major focus of my VR life so far – the Elevator to the Centre of the Earth. Since I’ve been working on this for a year, this might take a few posts, so today I’ll start with the first month or two of development.

Part 1: The basic elevator mechanic (April-May 2021)

I did not enter this as a big gamer (although I’m playing more now), so I didn’t really have a lot of experience with different game mechanics and how to set things up to get the effect I wanted. However, right off the bat it seemed that it would probably be easier to simulate elevator movement with a stationary elevator and moving shaft than with a moving elevator and stationary shaft. It turns out this is quite a common (and, I was told, simple…) mechanic called the Infinite Runner. Of course it wasn’t quite as easy as it was made out to be, but I was able to figure something functional (if not elegant or efficient) on my own.

I needed my infinite runner mechanic to do the following:

  • Simulate the elevator’s movement (up or down) within the shaft towards a specific “depth” based on the elevator’s “current depth” and player input
  • Have the correct shaft section (i.e. rock type) visible based on elevator depth so that the player sees the different layers in the Earth at the right time

I built both the elevator and shaft sections within Unity using ProBuilder and made prefabs out of each shaft type (for each rock layer) so they could be instantiated in the scene easily during gameplay.

Then I built a movement script that accomplished my goals by doing the following:

  1. When the game begins, three stacked crustal sections are instantiated so it looks like the elevator is within a rocky shaft near Earth’s surface. Each section is exactly stacked on on top of the other to make a total shaft that is big enough so that it looks like it is infinitely long
  2. The game keeps track of two main numbers: destination depth (set by the player when they select a destination) and current depth (calculated and updated as the elevator “moves”). Each frame, the game compares these two numbers: if the current depth is greater (i.e. deeper) than the destination depth, the shaft sections move incrementally downwards to make it look like the elevator is going up; if the current depth is less (i.e. shallower) than the destination depth, the shaft sections move incrementally upwards to make it look like the elevator is going down; finally, if the current depth is equal to the destination depth, the shaft sections don’t move. After each frame update the current depth is updated to reflect the movement that has just taken place.
  3. To avoid running out of shaft, when a section gets to a particular threshold depth, it flips back to the end so it can begin its journey again.
  4. When a layer boundary is reached, the current shaft sections are destroyed and the new sections instantiated at the same locations, making it look like you are moving up and down through the sections.

I was pretty damn excited when I got this to work but, like I said, my initial approach had some…inefficiencies and inelegancies. Thankfully I had the help of my Circuit Stream mentor, Ashley, to help clean up some things for me. Firstly she taught me that instantiating and destroying game objects is pretty resource-intensive and showed me how to get around this by instantiating everything at the beginning and toggling the shaft visibility instead of creating and destroying things. She also helped me fix (and enhance) the for and while loops I had tried to use and introduced me to using some lists and custom constructors (although I didn’t know at the time that was what they were). I also added the sound of a clunky old elevator for when the elevator is moving, something that still makes me smile.

Code snippet from the main script controlling elevator movement (after help from my mentor)

Part 2: Finding the right shaft materials (May-June 2021)

One of the things that I really wanted to focus on right from the beginning was using high-quality, realistic materials for my shaft sections – I want people to really get a visceral sense of what Earth is made of. Unsurprisingly, not many Unity creators are making geologically realistic rock materials, so I wasn’t able to find much on the Unity Asset Store (except for things like granite that you find in kitchens the world over). Fortunately for me, though, I work for a post-secondary institution and was able to take advantage of Adobe’s very generous (i.e. free!) licences for PSI staff and students for its Substance suite of programs. Substance Sampler is a clever piece of software that can build 3D textures and materials from photos. I am still looking around for better photos that allow me to get rid of some of the tiling effects, but I should be able to source some pretty good stuff from the geologist friends I have scattered around various research universities.

However, it is the materials that I created for Earth’s core that I am particularly proud of. There is definitely more creative licence involved here (not even close to direct visual evidence of what it looks like down there), but I used info I had and tried to make something that felt right, even if it might not be spot on. The outer core, responsible for Earth’s magnetic field, is a convecting soup of liquid metal (nickel and iron). To create the material, I found a lava texture in the Unity Asset Store and removed the red colouring and increased the metallic settings to make it look like liquid metal instead of liquid rock. The key to this texture, though, is its movement. The texture itself is animated, and looks like it is flowing and convecting around you. I did this by applying a script that alters the vertical and horizontal scale of the material using an offset sin function (i.e. the scaling of along the y-axis is offset relative to the scaling of the x-axis) to make it look a little more chaotic. I love how dynamic this makes everything feel when you’re in the game – amazing that something so cool can come from 5 or 6 lines of code.

Video of the flowing outer core

The inner core is also a nickel-iron alloy, but under such high pressures, it is solid. So, no animated textures, but some pretty cool features. I was able to find a material with some features that resemble the Ni-Fe crystallisation textures found in iron meteorites – what I figure to be a reasonable approximation of what the inner core looks like.

I think that’s probably enough for now! Animating buttons and the Project Deletion Disaster of June 2021 can wait until next time.


1 Comment

Val · March 24, 2022 at 19:48

Wow!! Brilliant work, Lou. I would love to be a student in a class using this technology.

Comments are closed.