[{"content":"I am a Computer Engineer and Game Programmer with a Master’s degree from Politecnico di Torino, specialized in Graphics and Multimedia. My work centers on gameplay architecture, internal tooling, and core subsystems. I build software structured around clear module boundaries, efficient data flows, and predictable runtime performance.\nTechnical Profile # Gameplay systems: modular game logic, entity interaction models, and state management designed for clear decoupling and seamless mechanic iteration. Tooling and workflows: custom editor extensions, runtime inspectors, and debugging utilities designed to streamline internal development workflows. Core architecture: subsystem design, entity lifecycle management, and memory-conscious data structures that ensure stability under heavy runtime workloads. Target Roles # I am pursuing opportunities in Gameplay Programming, Tools Development and Engine Programming. My priority is building robust technical foundations that bridge the gap between engineering and game design. I deliver flexible codebases and intuitive tools for rapid experimentation, ensuring the runtime remains performant and maintainable.\n","date":"16 September 2026","externalUrl":null,"permalink":"/about/","section":"Home","summary":"Giulio Arecco — Computer Engineer and Game Programmer.","title":"About Me","type":"page"},{"content":"","date":"16 September 2026","externalUrl":null,"permalink":"/","section":"Home","summary":"Personal portfolio of Giulio Arecco, Computer Engineer and Game Developer.","title":"Home","type":"page"},{"content":"","date":"10 June 2026","externalUrl":null,"permalink":"/projects/","section":"All Projects","summary":"A complete archive of my engineering project, case studies, and tools.","title":"All Projects","type":"projects"},{"content":"","date":"10 June 2026","externalUrl":null,"permalink":"/tags/computer-graphics/","section":"Tags","summary":"","title":"Computer Graphics","type":"tags"},{"content":" View Source Code This project is a CPU-based Monte Carlo path tracer built entirely in Zig. Inspired by the Ray Tracing in One Weekend series, encompassing the vast majority of concepts from the first two books, the codebase deliberately shifts away from traditional C++ object-oriented patterns. Instead, it was developed from the ground up to explore the Zig programming language and implement a multi-bounce global illumination engine from scratch without relying on external dependencies.\nTech Stack # Language: Zig 0.16.0-dev External Dependencies: None (Standard Library only) Architectural Overview # The engine is built as a complete pipeline divided into the following sub-systems. For a comprehensive breakdown of the software architecture, please refer to the repository\u0026rsquo;s README.\nApplication Configuration Core Utilities and Mathematics Camera, Rays, and Color Scene and Materials Geometry and Spatial Acceleration Rendering Frame Buffers and G-Buffers Post-Processing and Denoising Display and Image Output Testing and Resource Management Engineering Highlights # Zero-Cost Polymorphism via Comptime # To avoid the runtime overhead of virtual function calls typical of C++ inheritance, the rendering backend utilizes a Strategy Pattern implemented through tagged unions. By leveraging Zig\u0026rsquo;s inline else prongs within the rendering pipepline orchestrator (Renderer.render), backend dispatching is resolved entirely at compile-time. Compile-time metaprogramming is also utilized in the I/O pipeline, specifically in evaluating PPM header lengths to bypass dynamic heap allocations during string formatting, as well as in many mathematical utility functions.\nExplicit Memory Ownership and State Isolation # The architecture strictly enforces data-oriented contexts. Persistent runtime configurations are decoupled from both the execution state and the user-dependent configurations they-re derived from. Memory buffers are injected into core algorithms as transient data structures, ensuring the renderers remain stateless and easily testable.\nMemory management is handled explicitly via std.mem.Allocator. The Scene struct acts as the sole owner of all dynamically allocated entities on the heap, ensuring deterministic cleanup. Geometrical primitives hold only non-owning *const pointers to their materials, eliminating lifetime ambiguity and double-free vulnerabilities.\nSelective Denoising # The post-processing pipeline mitigates Monte Carlo noise at low sample counts using custom Joint Bilateral and À-Trous spatial filters. To guarantee memory safety during complex filtering operations, denoisers receive G-Buffer data through a dedicated read-only view. This leverages compile-time type coercion ([]T to []const T) to prevent accidental state corruption.\nFurthermore, the path tracer separates light transport into diffuse, specular, and emission components. This separation enables the engine to selectively bypass spatial denoising for perfectly glossy materials, preserving sharp, mirror-like reflections that would otherwise be incorrectly blurred.\nGallery # Denoising Results # Other Renders # Key Takeaways # Zig\u0026rsquo;s Explicit Philosophy: Prioritizing explicit control flow and zero hidden allocations proved highly effective in preventing code obfuscation as architectural complexity grew. Enforcing the explicit std.mem.Allocator pattern eliminated unexpected side effects, while leveraging the updated I/O and allocation interfaces in Zig 0.16 facilitated a modular and maintainable codebase. Engineering From Scratch: Deliberately avoiding third-party dependencies required writing custom functions and libraries to handle tasks like vector math and raw .ppm image serialization. This low-level approach consolidated my theoretical computer graphics knowledge, granting absolute control over every stage of the execution pipeline. Expanding the Scope: Venturing beyond standard light transport to implement custom spatial denoising filters provided hands-on experience with image-space data manipulation and lightweight post-processing algorithms. Application Polish: Designing a robust command-line interface to parse custom execution arguments transformed the project from a standalone algorithmic exercise into a fully configurable rendering application. Future Improvements: Integrating advanced sampling strategies (such as those detailed in Ray Tracing: The Rest of Your Life) would significantly strengthen the mathematical foundations of the path tracer. ","date":"10 June 2026","externalUrl":null,"permalink":"/projects/path-tracer/","section":"All Projects","summary":"A CPU-based Monte Carlo path tracer written in Zig, featuring multi-bounce global illumination, BVH acceleration, and custom spatial denoisers.","title":"Path Tracer","type":"projects"},{"content":"","date":"10 June 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"10 June 2026","externalUrl":null,"permalink":"/tags/zig/","section":"Tags","summary":"","title":"Zig","type":"tags"},{"content":" View Source Code Play on Itch.io Thesis Document Beyond The Line is a text-based interactive survival drama developed in Unity. It was designed as a serious game for my Master\u0026rsquo;s Thesis to evaluate if and how serious games have the ability to foster Complex Problem Solving cognitive skills through interactive narrative frameworks and targeted information management strategies.\nFor a comprehensive breakdown of the design process, the theoretical research foundations (including the CPS-GFC framework), and the empirical evaluation methodology, please refer to the thesis document.\nTech Stack # Engine: Unity Language: C# Narrative Scripting Language: Ink Architectural Overview # The project is built around a decoupled, event-driven architecture structured into the following functional areas:\nCore Engine \u0026amp; Execution: custom update managers and reflection-powered global stat tracking. Narrative Interoperability: centralized story orchestration, narrative variable registries, and Ink-to-C# function binding. Entity \u0026amp; Storage Systems: immutable ScriptableObject databases and generic IStorage\u0026lt;T\u0026gt; event-driven collections. UI Architecture: stack-based layer navigation (UINavigator) and decoupled MVC view controllers. Auxiliary Utilities: generic global state managers (Singleton\u0026lt;T\u0026gt;, PersistentSingleton\u0026lt;T\u0026gt;, RegulatedSingleton\u0026lt;T\u0026gt;) and custom interface serialization wrappers (InterfaceReference\u0026lt;T\u0026gt;). Telemetry Pipeline: zero-allocation behavioral tracking arrays and unified JSON stat exporters. Engineering Highlights # Unity and Ink Interoperability # To translate narrative choices into systemic gameplay consequences, the architecture implements a robust interoperability layer between Ink and Unity. A centralized StoryManager orchestrates text parsing and UI instantiation. To maintain global state persistence across branching paths, a StoryVariablesRegistry injects and extracts narrative variables into the Ink runtime. On top of that, a StoryFunctionsBinder utilizes reflection and type casting to safely execute C# backend logic triggered directly by Ink\u0026rsquo;s EXTERNAL functions. This interoperability layer also leverages ScriptableObjects as centralized databases, allowing narrative scripts to directly fetch game assets (such as inventory items, companions or audio tracks) and update the global game state at the most appropriate narrative moments.\nGeneric Storage and Type-Agnostic UI # The inventory and companion systems rely on a generic IStorage\u0026lt;T\u0026gt; interface. Under the hood, this architecture leverages C# generics to guarantee data integrity, preventing the creation of collections with heterogeneous concrete types. Simultaneously, it exposes a type-agnostic interface (IStorage) to the presentation layer; the UI can then dynamically render the collection contents without requiring any knowledge of the underlying data types.\nLayer-Based UI and MVC Pattern # The user interface is engineered using a Model-View-Controller (MVC) pattern to strictly isolate raw logic from its visual representation. Decoupled view controllers respond passively to backend C# events, dynamically repopulating panels without continuous polling. Navigation is governed by a custom stack-based UINavigator that manages overlapping layers.\nCustom Auxiliary Tooling # To overcome native engine limitations and streamline the development of complex systems, the architecture relies on a suite of custom foundational utilities. Because Unity does not natively support the serialization of C# interfaces, a custom InterfaceReference\u0026lt;T\u0026gt; wrapper was engineered to allow the assignment of scripts that implement a specific interface directly within the Inspector. Additionally, a set of generic base classes (Singleton\u0026lt;T\u0026gt;, PersistentSingleton\u0026lt;T\u0026gt;, and RegulatedSingleton\u0026lt;T\u0026gt;) was developed to expedite the creation of global managers while providing granular control over their instantiation and lifecycles across scene transitions.\nUnified Telemetry Infrastructure # To support the project\u0026rsquo;s research objectives, the game implements a silent telemetry system designed to track player behavior without impacting performance. It unifies narrative outcomes captured from Ink\u0026rsquo;s global variables with gameplay metrics tracked by the Unity engine. These C# RuntimeStats utilize low-overhead static arrays indexed by strongly typed enumerations, ensuring constant O(1) access time and no dynamic memory allocations. At the end of a session, a dedicated exporter aggregates these synchronized states into a unified JSON dataset for empirical analysis.\nGallery # ","date":"21 February 2026","externalUrl":null,"permalink":"/projects/beyond-the-line/","section":"All Projects","summary":"A text-based serious game developed as a Master’s thesis to explore Complex Problem Solving through resource management, narrative branching, and systemic uncertainty.","title":"Beyond The Line","type":"projects"},{"content":"","date":"21 February 2026","externalUrl":null,"permalink":"/tags/c%23/","section":"Tags","summary":"","title":"C#","type":"tags"},{"content":"","date":"21 February 2026","externalUrl":null,"permalink":"/tags/game-development/","section":"Tags","summary":"","title":"Game Development","type":"tags"},{"content":"","date":"21 February 2026","externalUrl":null,"permalink":"/tags/unity/","section":"Tags","summary":"","title":"Unity","type":"tags"},{"content":" Play on Itch.io Project Mecha-Ball is a 3D tactical puzzle game built in Unity, designed around simulated AI training scenarios and spatial problem-solving. Developed as a collaborative group project for the \u0026ldquo;Game Design\u0026rdquo; exam at Politecnico di Torino.\nProject Overview:\nRole: Game Programmer, Technical Game Designer (Team of 6). Context: Collaborative Game Design and Development Project. Responsibilities: Game concept and design, execution architecture, custom tooling, serialization improvements, teleport implementation, platforms and buttons mechanics. Contribution Overview # Execution Architecture: a custom polling system utilizing the Observer pattern to manage the execution order of game state updates reliably. Trigger Optimization: procedural bounding-box generation tools and zero-allocation overlap querying systems to bypass the standard need for Rigidbody components on kinematic triggers. Teleportation Infrastructure: teleportation logic featuring vector-preserving momentum calculations and object caching to prevent infinite teleport cycles. Custom Editor Tooling: reflection-driven property drawers and polymorphic lists serialization allowing level designers to construct puzzle interactions directly within the Unity Inspector. Engineering Highlights # Custom Update Loop # Relying heavily on distributed native update methods can make it challenging to maintain a predictable execution order. To ensure determinism, the architecture implements centralized update managers utilizing the Observer pattern. Active objects register to pending buffers to safely handle state changes mid-frame. The execution array is dynamically sorted by priority and iterated backwards, naturally accommodating real-time observer unsubscription.\nTriggers Optimization # Standard Unity trigger callbacks typically require at least one interacting object to possess a Rigidbody component, which did not align with the needs of our specific kinematic platforming mechanics. To accommodate this, custom bounding boxes (acting like trigger colliders) are calculated to automatically extrude and snap to a visual mesh\u0026rsquo;s top vertex, adapting dynamically as level designers scale objects in the Editor. To maintain performance, these custom triggers manage physics interactions using pre-allocated buffers. Collisions are evaluated using Physics.OverlapBoxNonAlloc(), preceded by a Physics.SyncTransforms() call to ensure accurate spatial queries without overlap latency on high-velocity platforms.\nTeleporters Implementation # Puzzle mechanics required teleportation systems to preserve momentum accurately while preventing actors from getting trapped in infinite interaction loops. Upon entering the teleporter trigger, the player\u0026rsquo;s velocity is cached, and the exact output trajectory is calculated using Quaternion.FromToRotation. This mirrors the object\u0026rsquo;s inertia relative to the receiving portal\u0026rsquo;s spatial orientation. To manage the teleportation state securely, a caching structure temporarily flags the actor on the receiving end, enforcing a cooldown loop that breaks the transfer cycle until the entity fully exits the teleporter trigger.\nEditor Serialization Tools # To decouple puzzle triggers (such as buttons) from receiver logic (such as platforms), the system relies on an interface-driven bridge. To empower level designers to configure these connections directly in the Unity Inspector, a custom Property Drawer was developed. By utilizing C# reflection, the tool dynamically discovers scripts inheriting from a base effect class, and then generates polymorphic concrete classes on the fly within the Inspector. This allows designers to assign diverse visual and logical effects without writing new code.\nGallery # ","date":"14 July 2025","externalUrl":null,"permalink":"/projects/project-mecha-ball/","section":"All Projects","summary":"A 3D puzzle game developed in Unity, centered on spatial problem-solving.","title":"Project Mecha-Ball","type":"projects"},{"content":"","date":"19 June 2025","externalUrl":null,"permalink":"/tags/javascript/","section":"Tags","summary":"","title":"JavaScript","type":"tags"},{"content":" View Source Code This project implements a full-stack web application centered around an order-estimation card game. Players must maintain a hand of cards sorted by a concealed numerical \u0026ldquo;misfortune index\u0026rdquo; evaluating the severity of various scenarios. Engineered as a decoupled client-server architecture, the project integrates a React 19 Single-Page Application with a stateless Node.js Express REST API, backed by a relational SQLite database for historical record-keeping.\nTech Stack:\nFrontend: React 19, React Router v7, Vite, Bootstrap. Backend: Node.js, Express, Passport.js, express-validator. Database: SQLite, custom asynchronous DAOs. Architectural Overview # React 19 Client: a Single-Page Application bundled via Vite, utilizing React Router for navigation guards and the useActionState hook for asynchronous form submission pipelines. Express REST API: a Node.js backend exposing game management, round handling, and user session endpoints, secured via Passport.js local authentication and express-session cookies. Relational Storage: a strict SQLite schema enforcing foreign key constraints, managed through asynchronous Data Access Objects executing parameterized queries. Request Validation Pipeline: an express-validator middleware chain that enforces type coercion, boundary checks, and input sanitization across all API payloads. Cryptographic Security: password hashing and validation utilizing Node.js native crypto.scrypt and crypto.timingSafeEqual primitives. Engineering Highlights # Concurrency Control and Race Condition Elimination # The core gameplay loop enforces a strict 30-second countdown timer per round. A critical race condition arises if a player submits their card placement at the exact moment the timer expires, potentially triggering both a submission outcome and a timeout penalty simultaneously. To eliminate this, the frontend interval relies on functional state updates. When the timer reaches zero, the update handler inspects the previous state\u0026rsquo;s round result. If the form submission pipeline has already resolved the round (assigning a 'win' or 'loss'), the timer aborts without incrementing the error counter, ensuring deterministic game state progression.\nAsynchronous Form Pipeline and Boundary Evaluation # Card insertion logic is managed without manual pending-state tracking by utilizing React useActionState hook. The user interface renders an interleaved array of potential insertion slots. Each radio input slot dynamically computes and serializes its boundary parameters (prevMisfortune and nextMisfortune) into a JSON string. Upon submission, the action state parses these boundaries and evaluates whether the target card\u0026rsquo;s true misfortune value falls correctly between the adjacent constraints.\nAnti-Cheat and Information Hiding # To prevent clients from inspecting network traffic to cheat the sorting mechanic, the architecture implements an information-hiding protocol. When the client draws a new card, the API endpoint is queried with a getMisfortune=false parameter. The backend DAO actively strips the numerical misfortune value, returning null to the client. The true numerical value remains isolated on the server and is only retrieved for validation after the player definitively locks in their insertion choice via the frontend form.\nData Deduplication and Relational Mapping # Generating random cards requires ensuring no duplicates are drawn within a single game session. This is handled directly in the SQL persistence layer via a nested subquery that filters the Card table against all cardId records already associated with the current gameId in the RoundCard junction table. Furthermore, querying a user\u0026rsquo;s match history requires reconstructing deeply nested hierarchical data (Games containing Rounds containing Cards) from flat SQL JOIN rows. The DAO implements a two-pass mapping algorithm utilizing a Map data structure to progressively reconstitute the nested arrays while preserving histories.\n","date":"19 June 2025","externalUrl":null,"permalink":"/projects/misfortune-game/","section":"All Projects","summary":"A relative-order card game implemented in React and Express/SQLite. Features real-time round timers, anti-cheat hidden card indexes, secure scrypt authentication, and match history tracking","title":"Misfortune Game","type":"projects"},{"content":"","date":"19 June 2025","externalUrl":null,"permalink":"/tags/web-development/","section":"Tags","summary":"","title":"Web Development","type":"tags"},{"content":" View Source Code Play on Itch.io The Plague in Milan is a first-person 3D interactive narrative experience built in Unity, recreating the historical and social environment of 17th-century Milan during the plague epidemic described in Alessandro Manzoni\u0026rsquo;s The Betrothed. It was developed as a collaborative project.\nProject Overview:\nRole: Game Programmer, System Designer (Team of 4). Context: Virtual Reality Project. Responsibilities: Character and camera physics synchronization, input normalization, narrative progression architecture, spatial NPC interaction systems. Contribution Overview # Direct engineering contributions to the project encompass the following functional areas:\nFirst-Person Character and Physics Setup: implementation and editor configuration of a Rigidbody-driven first-person player controller. Player Camera Synchronization: elimination of camera jitter and visual stutter by synchronizing the first-person camera position with the engine\u0026rsquo;s physics fixed update cycle. Input Management: configuration of Unity\u0026rsquo;s Input System, including action map context switching and vector processing across keyboard/mouse and gamepads. Modular Progression System: an event-driven architecture structured around modular objective steps (dialogues, spatial locations, physical interactions), supporting both individual progression checkpoints and composite steps that require multiple sub-objectives to be completed in arbitrary order. PC Interaction and Dialogue System: A complete conversational architecture combining ScriptableObject data containers, synchronized audio voiceovers, dynamic typewriter text streaming, proximity-based interruption, programmatic camera framing, and billboard UI. Engineering Highlights # First-Person Controller and Camera Synchronization # Player movement is built on a Rigidbody physics setup configured to interact reliably with level geometry and spatial triggers. In physics-driven first-person controllers, discrepancies between the fixed-rate physics update and the variable-rate frame rendering frequently produce visible jitter and camera stuttering. To resolve this, the camera tracking logic was tied directly to the physics simulation lifecycle. This ensures stable head movement while preserving consistent physical collision responses against the environment.\nInput Management # To handle locomotion consistently across both keyboards and gamepads, raw input vectors are processed before driving character mechanics. Orthogonal keyboard inputs inherently produce a diagonal magnitude greater than 1, which is mathematically normalized to prevent diagonal speed inflation. Conversely, analog stick inputs preserve their fractional magnitude to retain nuanced walk/jog speeds. Sprint states are gated by evaluating forward vector thresholds, preventing unnatural sideways or backward sprinting while tolerating thumbstick drift. Additionally, a centralized manager coordinates action map switching, disabling look or movement actions while in menus or during scripted sequences.\nModular Progression System # To handle story progression the architecture is structured around modular, event-driven steps. Individual steps can be grouped together into composite quest phases, which allows designers to create progression checkpoints that require multiple sub-objectives (such as inspecting several clues or visiting different locations) to be fulfilled before advancing, regardless of the order in which the player completes them. Dedicated controllers encapsulate distinct interaction paradigms (listening to dialogue end events, tracking physical prop interactions, or monitoring spatial triggers), keeping gameplay mechanics decoupled from the global state. Spatial trigger volumes remain disabled until their specific step becomes active, unhooking themselves immediately upon completion to avoid redundant evaluations.\nNPC Interaction and Dialogue System # When talking to an NPC, the character rotates toward the player using a planar projection that zeroes out pitch deltas, tracking the player at a controlled angular rate without abnormal tilting. Simultaneously, scripted camera rotations interpolate target angles via Mathf.LerpAngle across an easing curve to select the shortest angular path during look-lock. Conversational content is structured via ScriptableObjects into specific behavioral archetypes: one-shot exchanges, ambient loops, event notifications, and progression barriers. A centralized manager streams dialogue lines through an internal FIFO queue with typewriter pacing while triggering synchronized voiceover clips directly from the speaker\u0026rsquo;s audio source. To maintain physical plausibility, interactions enforce proximity constraints: if the player moves beyond an interaction threshold, active conversations are interrupted and queues are cleared. In-world nameplates and prompts rely on billboard calculations executed in LateUpdate with the roll axis clamped to zero, preventing horizon tilting during oblique camera angles.\nGallery # ","date":"24 February 2025","externalUrl":null,"permalink":"/projects/the-plague-in-milan/","section":"All Projects","summary":"An interactive first-person experience bringing to life the dramatic events of 17th-century Milan as depicted in Alessandro Manzoni’s “The Betrothed”.","title":"The Plague in Milan","type":"projects"},{"content":" View Source Code Read Full Report This project implements an adversarial deep learning pipeline built in PyTorch for the automatic colorization of line art and black-and-white illustrations. Based on the methodology introduced in Colorful Image Colorization (Zhang et al.), the system pairs the convolutional generator with adversarial discriminators to counteract desaturation. For an in-depth analysis of the training dynamics, hyperparameter tuning, and comparative metrics (PSNR, SSIM), refer to the full technical report.\nProject Overview:\nRole: Machine Learning Engineer (Team of 2). Context: Computer Vision / Deep Learning. Responsibilities: Color space quantization, GPU soft-encoding, loss optimization, dataset preprocessing. Contribution Overview # CIELAB Gamut Quantization: discretization of continuous chrominance space into 313 physically realizable color centroids using lattice filtering and k-means clustering. Chunked Soft-Target Encoding: a GPU-accelerated mapping pipeline converting continuous chrominance channels into probability distributions via Gaussian-weighted k-nearest neighbors. Numerically Masked Multinomial Loss: vectorized multinomial cross-entropy loss over continuous probability distributions, stabilized with log-domain zero masking. Dataset Sanitization and Preprocessing: data validation routines filtering corrupted image headers, standardizing multi-channel formats, and flattening alpha transparency channels. Engineering Highlights # Gamut Sampling and Color Space Discretization # Treating colorization as an \\(L_1\\) or \\(L_2\\) regression problem leads to desaturated, sepia-toned predictions because the loss minimizes expected error by predicting the mean of multimodal color distributions. To avoid this, the architecture adopts a classification formulation across discrete color bins in the CIELAB color space (\\(L^*a^*b^*\\)). Because unconstrained Cartesian sampling across the \\(a\\) and \\(b\\) axes generates chromatic coordinates outside the displayable sRGB spectrum, candidate pairs are concatenated with a reference luminance (\\(L^* = 50\\)) and projected into sRGB to discard non-physical values. The valid in-gamut points are clustered via k-means down to \\(Q = 313\\) centroids, producing an empirical color lattice that preserves natural density across high-saturation regions.\nMemory-Bound Soft-Target Encoding # Assigning continuous \\(ab\\) channels to discrete bins using 1-hot encoding produces severe quantization boundaries and high gradient variance. The target pipeline instead uses a soft-encoding mapping (\\(H^{-1}\\)) that distributes probability mass across the \\(k = 5\\) nearest color centroids weighted through a continuous Gaussian kernel. In a standard training batch of 32 images downsampled to \\(64 \\times 64\\), computing pairwise distances for \\(131,072\\) pixels simultaneously exceeds available GPU memory. To prevent out-of-memory faults, the target encoding runs in fixed chunk partitions. For each slice, pairwise Euclidean distances against all 313 centroids are computed, converted to Gaussian proximity weights, normalized across the probability simplex, and accumulated directly in VRAM.\nNumerically Masked Multinomial Loss # Standard cross-entropy implementations expect discrete class indices, whereas the soft-target colorization objective optimizes cross-entropy over continuous probability distributions:\n$$L_{cl}(Z, \\widehat{Z}) = - \\sum_{h,w} \\sum_{q=1}^{Q} Z_{h,w,q} \\log(\\widehat{Z}_{h,w,q})$$Here, \\(Z\\) represents the soft-encoded target distribution and \\(\\widehat{Z}\\) denotes the predicted class probabilities from the network\u0026rsquo;s classification layer. Because manga panels are dominated by neutral backgrounds and text, standard class rebalancing was excluded, relying instead on adversarial training and auxiliary pixel loss to enhance color saturation. Evaluating \\(\\log(\\widehat{Z})\\) risks divergence when predicted probabilities approach zero, yielding \\(-\\infty\\) or NaN values that corrupt backpropagation gradients. To maintain numerical stability, the calculation isolates strictly positive probabilities with a boolean mask before computing the logarithm, evaluating the reduction via a single vectorized tensor product.\nDataset Sanitization and Preprocessing # Raw manga scans collected from public datasets present substantial variations in format, including corrupted file headers, 1-channel bilevel line art, and 4-channel RGBA scans. The sanitization process validates image metadata at the header level during dataset indexing, skipping corrupted or incompatible files without reading entire pixel arrays into host memory. An alpha-detection preprocessor converts RGBA scans to 3-channel RGB representations prior to spatial resizing, preventing tensor dimension mismatches during batch collation. Additionally, CPU execution limits were configured to restrict OpenMP worker allocation between Scikit-learn and PyTorch DataLoader workers, preventing thread contention and memory leaks during data preparation.\n","date":"14 February 2025","externalUrl":null,"permalink":"/projects/automatic-manga-colorization/","section":"All Projects","summary":"A deep learning framework in PyTorch for automatic manga and line art colorization, combining quantized color classification with adversarial training.","title":"Automatic Manga Colorization","type":"projects"},{"content":"","date":"14 February 2025","externalUrl":null,"permalink":"/tags/machine-learning/","section":"Tags","summary":"","title":"Machine Learning","type":"tags"},{"content":"","date":"14 February 2025","externalUrl":null,"permalink":"/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"12 February 2025","externalUrl":null,"permalink":"/tags/c++/","section":"Tags","summary":"","title":"C++","type":"tags"},{"content":" View Source Code This project implements a GPU-accelerated simulation of an N-body system utilizing the all-pairs approach. Developed collaboratively, the application computes gravitational interactions using NVIDIA CUDA, supplemented by real-time visualization and performance benchmarking.\nProject Overview:\nRole: Software Engineer (Team of 2). Context: Parallel Computing / GPU Programming. Responsibilities: Shared memory optimizations, numerical validation harness, and hardware diagnostic utilities. Contribution Overview # Shared Memory Tiling: parametric tiling that decouples tile width from thread block size, combined with register-level state caching to minimize global memory traffic. CPU Validation: a multi-threaded OpenMP reference implementation providing lockstep verification and adaptive tolerance analysis for floating-point calculations. Hardware Diagnostics: runtime GPU introspection that queries streaming multiprocessor limits to perform pre-flight validation on kernel launch parameters. Engineering Highlights # Parametric Tiling and Register Caching # Evaluating all-pairs gravitational forces requires \\(O(N^2)\\) interactions, which quickly saturates memory bandwidth if threads query global memory directly. To optimize data reuse, a parametric shared memory tiling system was implemented. By decoupling tile width from the thread block dimension, the kernel stages larger contiguous chunks of particle data into fast on-chip shared memory while maintaining coalesced global reads. In addition, particle positions and velocities are cached directly in thread-local registers during the numerical integration step. This confines intermediate Leapfrog updates to registers, reducing global memory traffic to a single read at kernel launch and a single write upon completion.\nNumerical Validation and Adaptive Tolerance # Because floating-point addition is non-associative, varying warp execution orders introduce numerical deviations that make it difficult to distinguish expected rounding errors from actual concurrency bugs. To verify algorithmic correctness, a deterministic multi-threaded CPU reference implementation was developed using OpenMP. Both implementations include a Plummer softening factor (\\(\\epsilon^2\\)) to prevent numerical divergence when particle distances approach zero. A testing harness runs the CPU and GPU simulations in lockstep, using page-locked host memory (cudaMallocHost) for fast DMA transfers. Rather than relying on fixed epsilon thresholds, which fail across large coordinate spans, the validator evaluates discrepancies using an adaptive relative tolerance, preventing false positives while catching true mathematical divergence.\nHardware Diagnostics and Launch Validation # Arbitrary thread block configurations and shared memory allocations risk exceeding device limits, causing runtime launch failures (cudaErrorLaunchOutOfResources). To prevent this, a diagnostic module queries the GPU\u0026rsquo;s hardware properties (including register availability, shared memory capacity per SM, and maximum grid dimensions) via the CUDA Runtime API. A pre-flight validation check evaluates kernel requirements against these physical limits before launch, throwing explicit exceptions if resource budgets are exceeded. Additionally, the execution pipeline separates computational benchmarking from display rendering, enabling headless execution to measure raw kernel throughput without display synchronization constraints.\nVisual Demo # Your browser cannot play this video. Download video.\n","date":"12 February 2025","externalUrl":null,"permalink":"/projects/cuda-n-body/","section":"All Projects","summary":"A CUDA-accelerated gravitational N-Body Simulation based on the all-pairs approach. Features optimized kernels utilizing shared memory and loop unrolling, a benchmark suite, and OpenGL real-time visualization.","title":"CUDA N-Body Simulation","type":"projects"},{"content":"","date":"12 February 2025","externalUrl":null,"permalink":"/tags/parallel-computing/","section":"Tags","summary":"","title":"Parallel Computing","type":"tags"},{"content":"","date":"12 February 2025","externalUrl":null,"permalink":"/tags/systems-programming/","section":"Tags","summary":"","title":"Systems Programming","type":"tags"},{"content":"","date":"13 September 2024","externalUrl":null,"permalink":"/tags/c/","section":"Tags","summary":"","title":"C","type":"tags"},{"content":" View Source Code This project implements a demand-paging virtual memory subsystem within the OS/161 operating system kernel. It replaces the default static memory allocator, enabling the execution of user programs whose memory footprint exceeds available physical RAM.\nProject Overview:\nRole: Kernel Developer (Team of 2). Context: Systems Programming — OS/161 Architecture. Responsibilities: Swap space storage, page replacement logic, TLB management, on-demand ELF loading. Contribution Overview # To support demand paging, the following core components were implemented:\nSwap Space Management: a disk-backed storage manager utilizing a custom self-describing framing protocol and in-place frame swapping to prevent unbounded file growth. Page Replacement: a doubly-linked FIFO tracking data structure designed to manage page residency and victim selection in the absence of hardware reference bits. TLB Management: a translation lookaside buffer manager providing round-robin slot replacement and software-enforced write protection. On-Demand ELF Loading: a loading sequence that eliminates eager binary loading by lazily streaming executable segments directly from disk into memory. Engineering Highlights # Swap Space and In-Place Replacement # To serialize evicted pages to disk without maintaining complex external block-allocation tables, a self-describing framing format was designed. Every page written to the swap file is structured as a 4100-byte record: a 4-byte header storing the virtual address followed by a 4096-byte data payload. This structure allows the swap manager to perform linear disk lookups and assert data integrity directly against the on-disk record header. To prevent continuous file expansion during sustained paging, which would quickly exhaust disk capacity, an in-place swap replacement mechanism was implemented. When retrieving a swapped page, the data is read into a temporary intermediate buffer, the exact disk offset is overwritten with the data of the newly evicted victim page, and the buffered page is finally copied into RAM. This ensures disk usage remains neutral during active page replacement.\nFIFO Page Replacement # Because the MIPS R3000 CPU lacks hardware reference or access bits, implementing a strict Least Recently Used (LRU) algorithm without severe software overhead is impractical. Instead, a FIFO replacement policy was developed. The tracking structure is maintained on a per-address-space basis as a doubly-linked list, encapsulating page table indices. Maintaining both head and tail pointers enables \\(\\mathcal{O}(1)\\) push operations at the tail when a physical frame is mapped, and \\(\\mathcal{O}(1)\\) pop operations at the head to instantly identify eviction candidates. The queue also supports arbitrary node extraction, allowing the kernel to gracefully remove entries if a page is unmapped or migrated independently of the standard replacement sequence.\nTLB and Memory Protection # On the MIPS R3000 processor, virtual-to-physical address translation is managed through a software-managed Translation Lookaside Buffer containing 64 hardware slots. When a TLB miss occurs, the trap handler searches for a free slot or, if the buffer is full, delegates to a rolling modulo counter for deterministic round-robin victim selection. Furthermore, the MIPS architecture does not provide a dedicated \u0026ldquo;write-enable\u0026rdquo; control bit, relying instead on a \u0026ldquo;dirty\u0026rdquo; bit. This behavior was leveraged to enforce segment protection. By leaving the dirty bit cleared for addresses falling within the compiled program\u0026rsquo;s text segment, any illegal write attempt safely triggers a VM_FAULT_READONLY hardware trap, which the dispatcher intercepts to terminate the rogue process. To ensure atomic programming, the entire TLB update sequence is strictly wrapped between interrupt masking calls.\nOn-Demand ELF Loading # The baseline OS/161 kernel eagerly copies all ELF program segments into contiguous memory during load_elf, wasting physical RAM on unexecuted code and failing completely on large executables. To enable demand loading, a segment metadata structure was designed to store executable vnode references, program headers, and virtual base addresses without allocating physical frames upfront. The kernel loader was modified to bypass segment copying entirely, initializing process address spaces with empty page tables and metadata descriptors, thereby consuming negligible RAM at startup. Because pages must be read dynamically during execution, the filesystem lifecycle was updated. The internal reference count of the binary vnode is explicitly incremented during process startup, preserving the active file handle long after the initial launch and ensuring the executable remains accessible for lazy loading.\n","date":"13 September 2024","externalUrl":null,"permalink":"/projects/demand-paging-os161/","section":"All Projects","summary":"An OS/161 kernel extension implementing demand paging, swap space management, per-process page tables, dynamic ELF loading, and TLB handling.","title":"OS/161 Demand Paging","type":"projects"},{"content":"","date":"16 July 2024","externalUrl":null,"permalink":"/tags/3d-modeling/","section":"Tags","summary":"","title":"3D Modeling","type":"tags"},{"content":"","date":"16 July 2024","externalUrl":null,"permalink":"/tags/animation/","section":"Tags","summary":"","title":"Animation","type":"tags"},{"content":" Watch the Animation This project is a 3D animation reproduction of the animated promotional short The Postman. Developed collaboratively in Blender, the goal was to recreate the original piece\u0026rsquo;s staging, timing, character posing, and scene layout.\nProject Overview:\nRole: 3D Animator (Team Project). Context: 3D Animation Project. Responsibilities: Keyframe animation, character posing, shot staging, 3D asset and prop. Contribution Overview # I was responsible for some of the work on the following sequence intervals and scenes of the final video:\n[0:01 – 0:02 / 0:16 - 0:17]: The postman starts the car. [0:02 – 0:03 / 0:17 - 0:18]: Shot of the postman driving. [0:03 – 0:04]: Zoom on the postman driving. [0:04 – 0:05]: Wide shot of the postman arriving at the house and opening the car door. [0:05 – 0:07]: The girl exits the front door holding the dor in her arms. [0:18 – 0:19]: The dog hears the appoaching car and wakes up. [0:29 – 0:31]: The dog lying asleep on its back. [0:32 – 0:33]: Close-up of the postman and girl\u0026rsquo;s hands brushing as he hands over the package. ","date":"16 July 2024","externalUrl":null,"permalink":"/projects/the-postman-recreation/","section":"All Projects","summary":"A 3D character animation project in Blender reproducing Renault’s “The Postman” commercial, focusing on keyframe animation, shot staging, and timing.","title":"The Postman: 3D Animation Recreation","type":"projects"},{"content":" View Source Code Gameplay Demo Dragòn is a 2D scrolling arcade game developed in C++ using OpenGL, GLFW, and GLM. Developed as a collaborative team project, the game combines 2D sprite rendering, keyboard navigation, projectile dodging, and stage progression.\nProject Overview:\nRole: Game Developer / 3D Artist and Animator (Team of 3). Context: Computer Graphics / Game Development. Responsibilities: Menu and UI management, multi-part player hitboxes, fixed-rate animation control, player movement constraints, save state serialization, and 3D modeling/rigging in Blender. Contribution Overview # User Interface: menu screens and UI buttons supporting hover states, cursor hit-testing, stage unlocking based on save data, and mouse-click handling. 3D Asset Creation and Fixed-Rate Animation: creation of the 3D dragon model and wing-flap cycle in Blender, exported as a 2D sprite sequence and updated at a fixed 24 FPS. Multi-Part Hitbox Geometry: division of the dragon\u0026rsquo;s shape into 5 distinct bounding boxes moving synchronously with the player. Movement and Viewport Clamping: directional WASD movement with sprint and precision speed modes, clamped to the window boundaries accounting for sprite padding. Pause Logic and Save Serialization: game pause state that freezes gameplay and compensates timers, alongside stage progression persistence to disk. Engineering Highlights # Asset Modeling and Fixed-Rate Animation # The player character was modeled, rigged, and animated in Blender, then exported as an 8-frame sequential 2D sprite set. To avoid tying the animation speed directly to the rendering framerate, which would cause the wings to flap too quickly or slowly depending on frame rate, an accumulator-based animation controller was implemented. By accumulating delta time until reaching a fixed interval, the controller advances the sprite sequence in a bidirectional ping-pong loop locked at 24 FPS.\nMulti-Part Hitbox Geometry # Using a single bounding box for the dragon leaves large areas of empty space around the neck, wings, and tail, causing projectiles to register hits on transparent pixels. To match the character\u0026rsquo;s silhouette, the dragon\u0026rsquo;s shape was subdivided into 5 separate bounding rectangles, scaled relative to the sprite size. When the player moves, the translation vector is applied directly to the player coordinates and simultaneously propagated to all 20 vertices of the sub-boxes, keeping the hitbox positions aligned without allocating memory or recalculating offsets from scratch. For basic circular projectiles, a closest-point check computes squared distances against each box, avoiding square root operations.\nUI and Input Handling # The interface was built around dedicated Menu and Button classes to keep menu logic separate from game loops. Buttons manage idle and hover states, scaling slightly when hovered. Cursor collision is evaluated using an axis-aligned point-in-box check. To prevent misclicks, such as pressing down on one button and dragging the cursor off before releasing, the input handler records the active button on mouse-down and only fires the associated action if the cursor is still over that same button on mouse-up. The menu also queries completed stages to dynamically show medals and unlock subsequent levels.\nMovement Controls, Pause State, and Save System # Player movement integrates directional WASD inputs with a speed modifier that toggles between a standard speed, a sprint mode, and a precision slowdown mode for navigating tight bullet spaces. To keep the dragon within the window, the movement function checks target positions in advance, using visual offsets that account for transparent padding along the wing edges. A pause state machine halts actor updates and darkens the background scene using a shader uniform. While paused, the game timer accumulates the elapsed pause delta to prevent the in-game clock from advancing during pauses. Finally, level progression is written to disk as a text file (save.txt), recording the highest completed tiers across both campaign themes.\n","date":"5 March 2024","externalUrl":null,"permalink":"/projects/opengl-dragon-game/","section":"All Projects","summary":"A 2D scrolling arcade game built in C++ and OpenGL, featuring collectible power-ups, health and mana management, and unlockable levels with escalating difficulty.","title":"Dragòn - 2D OpenGL Arcade Game","type":"projects"},{"content":"This project is a 3D environment set inside a gothic cathedral, created in Blender and rendered using the Cycles engine. Developed as complementary visual art for the Dragòn - 2D OpenGL Arcade Game project, the scene showcases fantasy props, procedural asset modeling, and atmospheric lighting.\nProject Overview:\nRole: 3D Artist (Team of 3). Context: 3D Environment Art / Offline Rendering. Tools Used: Blender, Cycles Render Engine. Responsibilities: Procedural modeling via Geometry Nodes, prop modeling, procedural shading, scene lighting. Contribution Overview # Dragon Egg (Geometry Nodes): procedural distribution, scaling, and alignment of overlapping scales across the egg surface using a custom Geometry Nodes graph. Prop Modeling: 3D modeling of the floor wrought-iron candelabras, altar candleholders, wax candles, and the carved dragon fang resting on the ceremonial pillow. Procedural Materials: node-based procedural shading, including subsurface scattering for the translucent candle wax, metallic surfaces for candleholders and candelabras, and organic texturing for the dragon fang and egg. Lighting Setup: multi-source illumination setup balancing warm local point lights at candle wicks and the glowing lava contained in the dragon vessel with cool, low-intensity ambient light streaming from the cathedral windows. Gallery # ","date":"25 February 2024","externalUrl":null,"permalink":"/projects/dragon-3d-environment/","section":"All Projects","summary":"A 3D cathedral environment modeled in Blender and rendered in Cycles, featuring procedural geometry nodes, custom props, and physically-based materials.","title":"Dragòn - 3D Environment","type":"projects"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]