Interactive Portfolio
This portfolio is both a presentation layer and a documented software project. It combines an interactive Three.js room, the AFFAN_OS file environment, long-form project and interest pages, a searchable object index, responsive non-3D navigation, adaptive rendering, structured metadata, and deployment checks so the visual idea does not replace usability or evidence.
Why the room exists
I wanted the first view to communicate more than a grid of project cards. The room connects technical work and personal interests to physical objects: the workstation opens AFFAN_OS, the rack represents networking and the home lab, the printer explains fabrication, the racket opens badminton, the camera opens photography, and the bookshelf opens reading.
The visual idea only works if visitors can understand it. The page explains how to move and select, highlights complete targets instead of relying on invisible click points, records viewed objects, provides a numbered index, and keeps conventional Info, Interests, and project content available outside the 3D scene.
Room construction
The desk, workstation, printer, rack, bookshelf, sports equipment, props, and cat are procedural Three.js models built from reusable geometry and materials. A locally hosted CC0 camera asset is documented separately. Lighting, shadows, camera targets, object labels, and movement limits are tuned together so the room remains readable rather than becoming a model viewer with portfolio text attached afterward.
Objects are interactive systems rather than decoration. Selection changes camera position, focus, labels, visited state, and available links. The scene also has to recover cleanly when a visitor closes a panel, resizes the page, switches tabs, uses touch input, or asks for reduced motion.
AFFAN_OS
Powering on the room computer opens a React interface designed like a small personal operating system. It organizes projects, Cisco labs, education, experience, interests, contact paths, inspiration references, the current resume, TryHackMe records, and the synchronized learning log into folders and readable documents.
The desktop includes window state, back navigation, minimized and maximized views, a launcher, file search, keyboard access, touch-friendly controls, and a Bash-inspired terminal. Project documents now contain their complete journals so a visitor can remain inside the file instead of opening another page to obtain the important context.
Performance strategy
The initial room should appear before optional visual effects. Bloom and glTF parsing are loaded only when required, nonessential model work is deferred until the browser is idle, hidden tabs pause rendering, and idle scenes use a reduced update rate. Pixel ratio, shadow maps, reflections, and geometry detail respond to device capability.
These choices do not make Three.js free. The core renderer remains the largest client-side dependency, so performance work focuses on bounding repeated work, limiting asset weight, and preserving a useful non-3D route rather than pretending the scene has the cost of an ordinary static page.
Accessibility and responsive behavior
The WebGL canvas is a presentation layer, not the only document structure. The object index exposes targets as ordinary controls, detail windows use headings and links, and the standard site routes remain usable without orbiting a camera. Touch devices receive larger targets and simplified motion; reduced-motion preferences remove nonessential animation.
Responsive work includes the site header, case-study typography, AFFAN_OS windows, folder grids, resume viewer, terminal, room labels, and the small in-app browser pane used during development. Visual novelty is not allowed to make project evidence unreachable.
Content and evidence
Public repositories are linked where source can be shared. Private work explains architecture, observed results, test totals, limitations, and my exact responsibility without exposing confidential material. Repeated facts such as test counts, project status, deployment links, and graduation date are checked across the resume, room, files, and long-form routes.
Before a release, lint checks the source, the production build renders every route, and automated tests inspect generated output for core content, metadata, project facts, interests, the desktop environment, and local assets. Deployment occurs only after those checks pass.
Lessons and ongoing record
The project taught me to separate visual ambition from the content contract. A recruiter still needs a clear resume, a technical reviewer needs evidence, a keyboard user needs another path, and a slower device needs a bounded workload.
This portfolio is maintained as an ongoing journal. New entries should record the problem, decisions, evidence, limits, and next step—not merely add another technology name.