top of page

Creative Portfolio

Thomas Carter

Unity-Logo.png

Cone of Confusion

the probe.png
forest 2.png
Jelly.png
AndyWarhol.png
Forest.png

Cone of Confusion is a VR audio exploration game demo created in the Unity game engine. Originally designed to be a more close to life sound recording game, time constraints led to the project being taken in an abstract direction.

The main aim of the demo was to explore the relationship between a player in VR and the audio feedback they recieve from the game. The player is able to control where their ears are in the world. This allows them to explore the world through audio instead of through vision.

During this project I leant about the Unity engine and the Steam VR implementation.

A Time Before

Bathroommirrors-2048x1152.jpg
Algue-2048x1152.jpg
Boywoods-2048x1152.jpg
Undertable-scaled.jpg
riverunderwater16_9-2048x1152.jpg

A Time Before (2024) explores memory and perception by blending hand-drawn animation (representing memories) with 360-degree live-action underwater footage (depicting dreams).

The experience incorporates a participatory element, inviting audiences to navigate their own mental landscapes and contemplate the nature and formation of their earliest memories.

The aim of this project was to have a virtual reality experience combining 360-degree video and interactive player driven sections. I joined this project in the early stages of development, working on the inital implementations of interactions and the blending of 3D objects and the 2D 360 video.

There was a particular difficulty early on with trying to get the video files to play in the Unity engine. The videos were split into the different scenes, but the level of quality required for VR combined with the 360-degree video necessitated the video be at minimum 8k resolution. This caused a lot of challenges trying to load the videos fast enough whilst not running out of memory on the VR headset.

Trash Pandamonium

YMcmjF.png
gi0god.png
Vs_moI.png
PA9o8G.png
S2oGxX.png

Trash Pandamonium is an arcade style, hide and seek heist game demo, built using the Unity engine. The aim of this project was to create a minimum viable product game demo as part of a five person team.

The player plays as a mischievous racoon, who sneaks around the house trying to find and pick up a variety of items, to deposit in the drop zone to bring back to the den. They must do this while evading Finn, the electronic cleaning assistant, who is looking after the house while the owners are out.

As the team leader on this project, I was required to create and maintain a schedule for the project, which included ensuring all of the team members were aware of the schedule, and making decisions about whether certain features had enough development time left to be completed. Additionally, I took on the role of 3D modelling, animation, and level design. The Finn robots were modelled, rigged, and animated by me. Due to the time constraints of the project, an asset pack was used for the racoon and the house interior.

Godot

godot.png

WOAH, THATS A PAINTBALL

Capture.PNG

Using blender for asset creation.

In engine final product.

wtap3.PNG
wtap2.PNG

WOAH, THATS A PAINTBALL (WTAP) was the first game demo project I undertook in the Godot engine. I had learnt how to use the engine just a month prior at a game jam. This project required me to learn many novel techniques that have wide usage in games development.

This was my first project with the goal of multiplayer, so I had to learn how to code and design the game to be multiplayer from the ground up. WTAP also required that I learn how to prebake large physics simulations in Blender. Godot does not have the strongest or most performant physics engine, so it was critical for the animation of the map blowing up to be prebaked.

Dogfight

df1.PNG

10 minute timelapse of asset creation to reference.

df2.PNG

Development footage of the physics based movement.

Dogfight was a game demo I created as a way to test fully physics based vehicular movement. This involved researching the complex physics behind how planes fly and how to equate those calculations into code that was streamlined enough to run in real time.

This was the first project that I experimented with capturing extensive development footage. Some of this development footage has been collated into the videos above. The 10 minute timelapse shows the creation of the main fusilage of the BF 109E model that I created for the game. The Spitfire and 109E were both modelled, based on reference sheets in blender.

blender.png

The Traveler

The Traveler is a 4 minute animation to music completed entirely in Blender. The animation makes use of multiple different aspects of the Blender toolset, including procedural animation through geometry nodes, glass transmission shaders, and sound to animation curve generation. The project was then rendered using 20 computers set up in a render array.

Physical Technology

The Kraken Ambisonics project

IMG-20241122-WA0000.jpg

Fully assembled release candidate one.

Kraken is the current name for an ongoing joint project, with the aim of creating an affordable kit and instruction set for building a 2nd order ambisonic microphone. The project is aimed at hobbyist and low budget audio recording enthusiasts. Kraken has just reached its first major milestone with the finalisation of our first release candidate.

Kraken was designed through an iterative process to make sure that it was not only a lightweight and compact device, but to also ensure that it was rigid and stable enough for field use. The design builds off the work of Fernando Lopez-Lezcano's 2019 paper "THE SPHEAR PROJECT UPDATE: REFINING THE OCTASPHEAR, A 2ND ORDER AMBISONICS MICROPHONE", Eric Benjamin's 2012 paper "A Toolkit for the Design of Ambisonic Decoders", as well as the 2021 Ambi-Alice project by DJJules.

These papers make clear the importance of orientation, distance between microphone capsules, and the dangers of hollow shell bodies in the creation of a 2nd order microphone. The grated design of the head and capsule holders has been designed to reduce internal resonances while maintaining structure.

Design Timeline

1.

o1.PNG
o6.jpg
o2.PNG
o3.PNG
o7.jpg
o4.PNG
o10.PNG

Clamp to isolate the capsules from external cable tension.

o8.PNG
soldering4.jpg
soldering2.jpg
soldering3.jpg
soldering1.jpg

Kraken follows the same principles as laid out in the Ambi-Alice project, using Electret microphone capsules with FETs to maintain sound quality while keeping costs relatively low. The XLR end of the cable has a capacitor and a resistor to act to remove the DC offset so that the -48V phantom power does not return to the recorder along with the signal. With the aim of the low budget enthusiast market, we felt it was best to use tried and tested components and schematics to expand on what already existed.

Research into Audio Multiplexing

In line with the Kraken project, I also did some research into audio multiplexing as a possible solution for using large microphone arrays on a budget. Ambisonic microphones use a large number of audio channels, and suitable audio equipment can be prohibitvely expensive for individuals. This research came about from me wondering if it would be possible to interlace audio samples in real time before the analogue-digital converter (adc) in the audio recorder.

Unfortunately, the reality of multiplexing is that it would need to be done in the digital domain. This requirement defeats the purpose of the multiplexing because you would still need an ADC for each audio channel. From here we started looking into signal modulation as a potential solution to this problem. Radios can pick up and select between multiple channels with ease, so we looked to that medium for inspiration. Both frequency and amplitude modulation seemed like good candidates for the application. We have done some digital testing inside the Max MSP audio environment that makes a promosing case for thse modulation types.

The main difficulty with modulation is that it requires a carrier frequency, and the more sub-channels you want to modulate into the carrier, the more headroom you need in the sample rate. In order to have two 48KHz signals in the same signal, you need a sample rate of at least 96KHz. The equipment needs to have the hardware capacity for both the high sample rate, and the high frequency range. This is so that you do not have aliasing issues, where the frequency of the sample is "reflected" as you go above the sampling limit. This creates issues for trying to keep the project low in cost for consumers, as while extremely high sampling rate ADC chipsets do exist, they are either limited in some other aspect, or are prohibitively expensive.

The Christmas Playlist Box

IMG_20241222_183859.jpg
IMG_20241222_183906.jpg
IMG_20241222_183920.jpg
IMG_20241222_183944.jpg

The Christmas Playlist Box was put together by myself and my brother for our local resident's association. On Christmas eve, people from the local area volunteer their time to push a wooden sleigh around the streets and give presents to the children that are signed up for the event. Part of this event is having a Christmas playlist playing from loudspeakers. Previously this was achieved using a car CD player system, but the bulk and inconsistency of that system meant that it needed an update.

The new system is designed to be as simple as possible, so that anyone might be able to use it. The new system also fits into the old ecosystem, being powered by the 12v car battery carried in the sleigh for the lights. Inside the watertight project box is the car speaker amplifier board, and the car bluetooth board. These boards were selected because they could be powered by the 12v battery. They also allow for us to keep the box operation simple.

There is a single potentiometer with switch which acts as the volume and the power for the circuit. This ensures the circuit cannot be turned on when the volume is above zero, to avoid damage to the amp and the speakers. Once the circuit is on, you connect to the system via any bluetooth capable device and play music.

IMG_20241222_183927.jpg
bottom of page