Zachariah Lee's Portfolio

The renderer uses a physically based shading model with a Lambrtian diffuse component and a specular component based on a microfacet BRDF using the Beckmann normal distribution function. It uses normal maps and has multiple Debug visualisations such as mipmap levels, depth, partial derivatives, overdraw/overshading and vertex density.

The raytracer uses phong shading, and can render scenes with hard shadows with point lights/soft shadows with area lights, impulse reflections, transparent objects with refraction and the fresnel effect, monte-carlo sampling with next event estimation for indirect lighting, anti-aliasing and caustics.

Abstract:

Anaglyph (Red-Cyan) 3D is a method of showing a stereoscopic 3D effect through a combination of colour encoded media and colour filter glasses. Issues include ghosting, where light for one eye is incompletely filtered and perceived by the other eye. This causes poor image quality and a reduced ability to perceive depth information. Current fixes for Anaglyph 3D involve optimising colours of the image to align with the display and glasses used. This reduces ghosting but the colour quality of the image is negatively impacted and requires specialised hardware such as a colorimeter. This project aimed to alleviate ghosting while preserving colour quality and depth perception by utilising the fact that ghosting is proportional to the parallax of the object, which is the distance between the object as perceived in each eye. A renderer was built that readjusts the focus plane in real time to where the user is focusing, which minimised parallax in the focused area. 9 participants were asked to use colour correction via gamma adjustment to alleviate ghosting with and without focus plane adjustment. Results showed focus plane adjustment required 71.5% less gamma adjustment, and in some test cases most participants required no adjustment. Although newer forms of presenting 3D such as polarised lenses are now widespread, Anaglyph 3D does not require specialised displays, is cost-efficient, and is the only way of presenting 3D effects on printed media. This fix is a highly accessible way of reducing ghosting as it does not require additional specialised hardware.

The second part involved creating a simple physics engine, I coded collision detection between the spheres, the spheres and the terrain, and the spheres and the skeleton. This involved keeping track of the state of each object, and i used impulses for collision response. I used euler intergration to update each object.

The game was coded in C# in Unity and the version control was handled through GitHub.

The gameplay controls were inspired by cozy gardening games such as Stardew Valley, but for this game we added a puzzle element where the goal was to summon creatures by planting flowers in specific patterns on the soil. These patterns were found in a spellbook and would be partially filled in, the rest of the pattern would have to be deducted through rules such as a daffofil could not be planted next to other plants. This gave the puzzle a sudoku like feel.

Parts of the game that I contributed to are the tiling system code, animation code, Menu and UI control code, some of the level design, and most of the art.

The game was coded in C# in Unity and the version control was handled through GitHub.

The gameplay controls took inspiration from the level select screen in the Overcooked video game series. The core gameplay loop involves sucking up parcels from shops to drive to and shoot at target homes. This was achieved by having a shop manager which allocated parcels to homes and spawns them, and through a collector class which handled recieving the package, additionally there was an inventory system which recorded which parcels you had in the van. There was also a game over system inspired by the video game Mini Metro where if there were too many unsent parcels it would activate a timer and after a set time if there were still too many unsent parcels it would trigger a game over

Parts of the game that I contributed to are the camera physics and control code, the code of the UI elements and menu, parts of the level design and 3D modelling and most of the sprite art and UI art.

This was coded in python with the pygame module

After researching and reviewing articles and pages on ray casting, i decided to try to code an implementation in python. I did this by building a grid of tiles that signify if there is a wall there or not, and given the players position and its forward facing direction cast rays from different angles relative to the player, each ray recording the distance to the closest wall from that angle. With this information i can then construct a view with each ray contributing a slice of the screen, with shorter slices representing walls that are far away and vice versa. It was quite challenging to work out the code as opposed to traditional vector directions, pygame's y vector is reversed.

Additionally I added the ability to jump, though this was a trick of the rendering, I simply moved the slices down inversely proportional to the jumping height to create the illusion of jumping.

As an afterthought, I added the game snake to the project, this was achieved by adding a 'trail' to the player with varying length, and a 'fruit' to be collected by walking into it, the fruit is functionally the same as a wall but once the player touches it, it dissapears and another fruit is spawned at a random point in the map. Each fruit increments the trail length by one, of which is a history of the players movement, which is filled with walls to simulate the snake body

As a consequence to this, there is now a lose condition, if the player is walled in by its own body and/or the wall, then the screen will flash a message to say that the player has lost, and to press the x key to exit the game (the x key could always be pressed to leave the game but it not explicitly mentioned until now)

A lot of the development of the code was actually pen and paper working out of the algorithm, the rendering was also quite tedious as I orignally set the relationship between distance and slice size to be linear, which caused a "fish-eye" like effect, eventually I used the square cube law to figure out that the slice size is proportional to the square of the distance.