Hi, my name is Nathan Peters. Welcome to my portfolio for tech art, systems, tools and more.

What problem was I trying to solve?
I wanted a way to quickly create low-poly assets directly in Unity by combining simple procedural shapes, drawing onto them, and turning the result into a reusable prefab.

How did I solve it?
I built an editor-based asset creation pipeline that combines a procedural Poly Lofting system with a compute shader painting system. In build mode, the tool raycasts onto surfaces while I left click and uses the surface normal to place new Poly Loft objects. The lofting system connects polygon layers by calculating how the polygons are positioned around a circle, adding triangles to the top or bottom so the connections are distributed evenly. I also added the math needed to control the position and rotation of those polygon layers.

The painting system keeps track of the current and previous raycast positions while drawing. A compute shader checks each pixel to see whether it falls within the radius of the painted line and changes its color when it does. The editor tools also include saving and loading patterns and a build process that bakes the procedural result into a prefab asset.

What makes this solution interesting?

• Combines procedural shape creation and texture painting into a single Unity editor workflow.
• Uses editor raycasts and surface normals to place procedural shapes directly onto existing geometry.
• Uses a compute shader to paint onto the generated asset by evaluating each pixel against the brush radius.
• Procedurally connects polygon layers with evenly distributed geometry based on their position around a circle.
• Includes editor tools for saving and loading patterns so designs can be reused.
• Bakes the completed procedural asset into a prefab that can be used normally in the project.

What problem was I trying to solve?
I wanted to make a flexible drawing-based puzzle system where different drawings could trigger different events and where the drawn shapes could also be turned into physical 3D objects.

How did I solve it?
I built a modular node-based puzzle system where nodes can be placed onto a drawing grid. The system tracks the order the nodes are crossed and allows different methods to be assigned for success, failure, clearing, or crossing a node. This makes it possible to build puzzles that require specific sequences of inputs and connect those results to different events.

I also built a 3D mesh generator that converts the drawing into geometry. It uses marching squares to determine the shape of the drawing, smooths the edges by adjusting vertices when nearby pixels have similar colors, connects the hypotenuses of the generated cells, and creates caps on both sides of the shape so the final mesh has depth.

What makes this solution interesting?

• Uses configurable nodes to define the valid paths and sequences for a puzzle.
• Allows puzzle logic to trigger different events for success, failure, clearing, or crossing nodes.
• Supports puzzles where nodes must be activated in a specific order.
• Keeps the puzzle logic modular so different node layouts can be combined with different event behaviour.
• Generates a 3D mesh directly from the player's drawing using marching squares.
• Smooths the generated edges by adjusting vertices based on the similarity of the drawing's pixel colors.
• Connects the generated geometry and creates caps on both sides to turn the 2D drawing into a solid 3D shape.

What problem was I trying to solve?
I wanted to add thick, stylized moss to rocks, trees, and other environment assets without modeling thousands of individual blades. The effect needed to be lightweight, reusable, and capable of naturally climbing surfaces.

How did I solve it?
I built a shell texturing system using GPU instancing and a custom URP shader. Multiple mesh layers are rendered on top of one another while the shader offsets each shell, applies procedural masking, and animates the moss with wind. Growth is controlled by surface height, allowing moss to naturally spread across objects while remaining fully adjustable in the Unity Inspector.

What makes this solution interesting?

• Uses shell texturing to create the appearance of thick moss without modeling individual geometry.
• Renders multiple moss layers using GPU instancing, allowing the entire effect to be drawn efficiently.
• Applies procedural masking and height-based growth so moss naturally climbs surfaces instead of covering the entire mesh.
• Includes animated wind movement to give the moss subtle motion and bring static environment assets to life.
• Exposes artist-friendly controls for shell count, growth height, density, wind, and color directly in the Unity Inspector.
• Reused the same shader on multiple assets, including trees, demonstrating a flexible material that adapts to different environment meshes.

What problem was I trying to solve?
I wanted a way to quickly add natural-looking vines to buildings without placing them by hand. The system needed to work on different surfaces while producing unique results each time it was generated.

How did I solve it?
I created a procedural generation system that scans nearby geometry using configurable raycasts, builds a network of surface nodes, and connects them with Bézier curves. Those curves are converted into procedural vine meshes, then populated with randomly placed leaves to create organic-looking vegetation.

What makes this solution interesting?

• Built a configurable surface scanner that projects raycasts onto nearby geometry to generate vine attachment points.
• Supports multiple projection directions, allowing vines to grow across walls, ceilings, and other surfaces without changing the generation logic.
• Uses cubic Bézier curves with randomized control points to create natural branch shapes while maintaining smooth growth.
• Procedurally generates vine meshes with adjustable thickness, radial detail, UV mapping, and tapered branch tips.
• Places leaves at randomized positions and orientations along each branch to create varied, organic results.
• Exposes generation settings such as branching density, leaf count, vine thickness, and scan resolution, making the system easy to iterate on inside the Unity Editor.

What problem was I trying to solve?
I wanted players to freely expand and reshape the interior of their home without breaking the existing layout. Expanding a room meant keeping walls, furniture placement, and gameplay data synchronized while the grid changed size in real time.

How did I solve it?
I built a runtime expansion system that reconstructs the room layout from a stored reference matrix whenever its size changes. The system recalculates the grid, shifts existing objects when necessary, rebuilds placement cells, and keeps every connected system synchronized after each expansion.

What makes this solution interesting?

• Built a dedicated StretchManager that handles room expansion independently from rendering and gameplay systems.
• Uses a preserved copy of the original room layout to rebuild expanded rooms consistently instead of modifying the existing grid repeatedly.
• Automatically shifts placed furniture, updates occupancy data, and rebuilds snap cells whenever the room changes size.
• Supports expanding rooms in all four directions while preserving valid object placements whenever possible.
• Uses events to notify dependent systems when the room layout changes, keeping placement, rendering, and gameplay synchronized.

What problem was I trying to solve?
I wanted to create a stylized wood material without relying on texture files. The shader needed to generate unique-looking wooden planks while remaining lightweight, customizable, and easy to reuse across different modular building pieces.

How did I solve it?
I wrote a procedural shader for Unity's Universal Render Pipeline that generates plank layouts and wood grain entirely through mathematical functions. Noise, fractal Brownian motion (FBM), and randomized plank variation are combined to produce natural-looking wood while exposing artist-friendly controls directly in the Inspector.

What makes this solution interesting?

• Generates wood grain procedurally without using texture maps, reducing the need for authored assets.
• Creates randomized plank layouts with configurable widths, lengths, and subtle variation to avoid visible repetition.
• Combines procedural noise, FBM, and sine-based grain patterns to produce flowing wood grain with adjustable contrast and sharpness.
• Applies unique color variation to individual planks, giving large wooden surfaces a more natural appearance.
• Includes adjustable controls for grain frequency, warp, plank variation, and color, allowing the material to be tuned directly in the Unity Inspector.
• Designed for Unity's Universal Render Pipeline using HLSL, making the shader lightweight and easy to integrate into the modular building system.

What problem was I trying to solve?
I needed a reliable way to save and load complex, interconnected modular homes. The biggest challenge was the order of operations: if a dependent object (like an attached module or piece of furniture) tried to load before its parent room even existed, the references would break and ruin the entire layout.

How did I solve it?
I built a queue-based loading system that respects parent-child dependencies. It scans the save data, identifies the main "root" structures, and builds those first. If a child module tries to load but its parent isn't in the scene yet, the system simply pushes it to the back of the line until the parent is ready.

What makes this solution interesting?

• Uses a smart queue to delay loading dependent modules, preventing broken references without stalling the game.
• Packages the entire scene's data—including custom wall slots and furniture—into a compact JSON format encoded in Base64, automatically copying it to the player's clipboard for easy sharing.
• Safeguards against missing or renamed assets using string matching and regex, ensuring old save files don't completely crash if a prefab's name changes slightly.
• Handles physical transformations carefully, strictly separating root world coordinates from local child placements so modules don't warp or inherit weird scaling.
• Includes a fallback placement system for interior decorations, snapping them to the nearest valid room if their original grid coordinates fail validation.

What problem was I trying to solve?
I wanted players to freely customize walls, windows, and other modular pieces while preventing combinations that would conflict with nearby objects or building rules. The system needed to enforce those restrictions automatically without requiring custom logic for every object.

How did I solve it?
I built an interactive customization system where each module contains editable slots that open a popup menu when selected. Placement rules are configured directly in the Unity Inspector, allowing furniture and building pieces to dynamically enable or restrict available wall options as the player builds.

What makes this solution interesting?

• Created reusable placeholder slots that allow walls, windows, and other module pieces to be swapped without modifying the surrounding structure.
• Built a popup interface that automatically generates its available options and visually greys out restricted selections instead of removing them.
• Designed a rule-based restriction system where placed objects can lock specific customization options on the current module or neighboring modules.
• Uses reference counting so multiple objects can safely apply restrictions without accidentally removing each other's rules.
• Automatically replaces invalid wall selections whenever building rules change, ensuring every module always remains in a valid state.
• Allows new restriction behaviors to be configured through the Inspector, making the system easy to expand without writing additional code.