My Gaming Room

I wanted to design a room that felt like my own: a soft pink-and-white gaming setup with a standing desk, dual monitors, a microphone arm, and furniture that could actually move. That personal design exercise grew into an end-to-end technical art project, from concept development and high-poly asset creation to an interactive website and a separate physics simulation environment.

I developed the project independently using an AI-assisted workflow. My work covered visual direction, asset review and assembly, mechanical part preparation, optimization, web interaction, and the physics pipeline. The central challenge was carrying the same design through different representations while preserving its proportions, moving parts, and intended behavior.

Work in progress. Updated September 17, 2026 with the cabinet-top book stack and fresh local Three.js captures, including the hero image. The early concept and high-poly images document the original design; physics validation results are from the saved August 30, 2026 reports.

Table of Contents

• Designing a Personal Room
• Building the High-Poly Scene
• Preparing Real Moving Parts
• Optimizing for Three.js
• Making the Room Interactive
• A Separate Path into Physics Simulation
• Results and Further Work

Designing a Personal Room

The design started with a practical workstation layout: an adjustable desk, storage, a swivel chair, a PC tower, and the peripherals I would want within reach. I developed that into a softer science-fiction gaming aesthetic, using rounded furniture, white surfaces, macaron pink accents, and restrained RGB lighting.

The approved pink-and-white gaming workstation concept, establishing the furniture silhouettes, color palette, and lighting direction.

Original AI-generated visual-development reference, before the cabinet-top plant was replaced with books.

The concept guided the room's composition, but the 3D layout also had to work spatially. The microphone needed a believable desk attachment and clearance from the displays. The PC had to fit between the desk structure and storage. Lighting strips needed to sit on the furniture instead of floating beside it. These relationships became part of the asset review, alongside silhouette and color.

In the latest iteration, I replaced the cabinet-top plant with books because I enjoy reading, especially science fiction, and wanted those interests reflected in my personal space. I chose Dune, Foundation, and Neuromancer for the horizontal stack, with The Three-Body Problem leaning against them. The arrangement keeps the cabinet surface clear around the lamp while making the room feel more like my own.

The updated gaming room with a science-fiction book stack on the cabinet beside the lamp.

Blender presentation render of the current desktop web geometry, using the original scene camera, lighting, and native floor and screen materials. The Three.js captures show the browser's actual appearance.

Building the High-Poly Scene

I used six-view references to guide Seed3D High generation for 13 individual assets. Each generated model contained roughly one million triangles and arrived as a single mesh, so the output provided a dense starting shape rather than a ready-to-animate assembly.

In Blender, I normalized the assets to consistent dimensions, assembled the workstation, and added the room shell, window, rug, wall art, plants, display surfaces, and lighting. The monitor and speaker assets were reused as linked instances. I reviewed the composition from multiple views and corrected intersections around the microphone clamp, desk legs, PC, and cabinet.

The assembled high-poly workstation rendered in Blender, including the room shell, lighting, furniture, and repeated monitor and speaker assets.

Early Blender render of the static high-poly assembly, retaining the original plant. The book stack was added to the web derivative while preserving this authoring source.

I kept the generated masters, static assembly, and articulated scene as separate versions. This preserved a visual reference while allowing later mechanical and optimization work to develop without overwriting the accepted source assets.

Preparing Real Moving Parts

A dense generated mesh does not identify a drawer, hinge, sliding leg, or rotating support. Its disconnected topology islands also do not reliably correspond to physical parts. I used semantic masks and geometric analysis to separate the parts by function, then created explicit pivots and parent hierarchies.

Color-coded microphone-arm segmentation used to identify the clamp, links, joints, and terminal assembly before rigging.

Diagnostic part-separation view. The colors identify regions for mechanical preparation.

The cabinet received four independently sliding drawers and a hinged door. The desk uses telescoping stages, with the middle section moving at half the tabletop's travel. The keyboard, mouse, speakers, monitors, and microphone follow the tabletop; the PC and floor furniture stay in place. The chair separates its swivel assembly from its base, with additional controls for removing the headrest and lumbar cushion.

For the microphone arm, the hierarchy coordinates shoulder and elbow folding while keeping the microphone upright. The web derivative also develops the monitor support into articulated rigid links with separate screen pitch controls. Baking the imported world transforms into geometry and using unit-scale joint frames prevents nonuniform source scale from shearing a link when it rotates.

These mechanisms made placement constraints concrete: a good resting pose still needed to remain connected and clear of neighboring objects throughout its allowed motion.

Optimizing for Three.js

The articulated authoring scene contains about 15 million triangles. I built two web variants directly from that source, assigning budgets by part instead of applying one reduction ratio to everything. Large curved surfaces such as the chair and desktop retain more geometry, while small generated interior supports and clean mechanical hardware receive explicit treatment.

Version	Triangles	GLB size
High-poly source	14,998,700	—
Desktop	558,249	11.19 MB
Lightweight	231,478	4.95 MB

Values are from the export documentation and pipeline 2.7.0 room manifest, checked September 17, 2026. Web totals include the new book stack and rendered instances; GLB sizes use decimal MB. Texture dimensions are capped at 2,048 px for desktop and 1,024 px for the lightweight variant. Triangle reductions against the original authoring scene are approximately 96.3% and 98.5%; these are asset statistics, not frame-rate measurements.

The difficult work was preserving surface quality after reduction. Imported UV islands contained duplicate, disconnected vertices; collapsing them independently could open cracks and reveal the cabinet's dark interior. I reconnected exact coincident vertices within audited rigid meshes while retaining the per-corner UVs. The exporter then checks that reduction does not increase the allowed open-edge count.

Shading needed its own treatment. I rebuilt angle-aware normals in world space, accounting for the source scale, and checked the actual exported surfaces. Blanket smoothing and nearest-high-poly normal transfer were insufficient for thin scanned parts. Some supports were more reliable when rebuilt as clean hard-surface geometry while retaining their established joint identities.

The delivered assets use Meshopt geometry compression and WebP textures. Position values remain lossless float32 to avoid inverting extremely thin triangles. Independent checks decode the compressed GLBs and validate normals, surface boundaries, and semantic node references before replacing the published asset manifest. Each variant is derived from the high-poly source, so rebuilding does not compound damage from an earlier reduction pass.

Adding a Web-Ready Book Stack

The new prop follows a smaller asset workflow: an original-cover reference, Seed3D low-subdivision generation, then Blender optimization and PBR baking. The final stack uses 8,000 triangles, one material, and 1,024 px base-color, normal, and roughness maps. Both room variants retain the same baked geometry and normals.

The optimized science-fiction book stack, with three horizontal volumes and one leaning book.

Render of the optimized prop with original decorative covers. Small generated lettering is intended for room-scale viewing.

The exporter replaces the original plant in memory and fits the books uniformly to a 32 cm width, preserving their proportions. A stable scene identity attaches them to the cabinet's static root, so they stay on the cabinet when the desk rises or the drawers and door open. Asset, normal, and placement checks verify the replacement and lamp clearance before updating the web assets; the original Blender master remains unchanged.

Making the Room Interactive

I built the website around exploring the room itself: drag to orbit, scroll to zoom, and select a device to move it or open its controls. The interface provides 11 primary interaction targets, finer adjustments for individual mechanisms, a demonstration sequence, and resets for either the selected device or the complete room.

The updated Three.js website with the desk raised to 118 cm; peripherals follow the tabletop while the book stack stays on the cabinet.

Browser capture from the local application, with the desk-height control at its upper limit.

The browser reads a scene manifest containing stable node IDs, control ranges, click targets, and sampled local transforms. This carries authored movement into Three.js without depending on Blender object-name guesses or replaying one fixed demonstration timeline. Click proxies follow their moving assemblies, keeping selection aligned with the visible devices.

An interaction state machine handles direct slider input, smooth transitions, reversal, and reset. Changing a control during an animation begins from its current value; resetting one device preserves the other devices and camera. This makes it possible to explore combinations instead of watching only a predetermined sequence.

The updated browser scene with the top drawer fully extended and the cabinet door partially open; the new book stack remains on the cabinet top.

For delivery, the application chooses a lightweight asset variant for smaller screens or constrained devices, caps pixel density, and reduces rendering resolution when sustained frame time is high. The interface also supports English and Chinese and respects reduced-motion preferences. These choices keep the interaction understandable while accounting for the cost of displaying a detailed room in a browser.

A Separate Path into Physics Simulation

The second branch takes the articulated room into MuJoCo. Here, the goal is to represent bodies, joints, contact, and measurable actions. A browser animation can place a drawer at a requested position; a simulation also needs the collision shapes, limits, mass, and forces that govern how it moves.

Stage	Three.js	MuJoCo
Assets	Optimized GLBs	Visuals and collision proxies
Motion	Transform controls	Bodies and joints
Validation	Surface and interaction checks	Contact and stability tests

I created a separate Blender physics derivative with visual, collision, joint, and non-colliding layers. The high-poly source remains available for reference, while the simulation uses simplified representations. A structured physics manifest generates the MJCF scenes and keeps dimensions, joint interfaces, and estimated physical parameters auditable.

Collision proxies exported from the Blender physics-authoring branch, rendered with diagnostic colors and the room walls hidden to reveal the mechanisms.

Diagnostic render of the earlier physics-authoring proxy mesh, before the web book-stack revision. This is a preparation view, separate from a MuJoCo runtime or robot-task capture.

The simulation has a full profile with 109 independent keycap degrees of freedom, alongside the major furniture mechanisms, mouse controls, fans, and casters. A training profile retains the scene's visual and collision bodies while locking most keys to reduce the state dimensions. A separate entry point incorporates the Stretch 3 robot from MuJoCo Menagerie.

Eight tasks provide measurements and success criteria: approach the desk, open a drawer, open the cabinet door, press a desk button, press the spacebar, adjust a monitor, fold the microphone arm, and push the chair. The saved August 30 acceptance report passes 13 check groups, including stability, joint endpoints, drop tests, and the eight robot-contact tasks.

The evidence distinguishes direct state fixtures, which test measurement logic, from robot actions that require physical contact and target movement. The recorded microphone task uses forearm support before fingertip folding; the chair task checks caster swivel and rolling as well as displacement. These are deterministic controller baselines, with mass, inertia, friction, and spring values still marked as estimates. Physical calibration and learned-policy generalization remain further work.

Results and Further Work

The project produced an articulated high-poly room, two substantially smaller web assets, an interactive Three.js experience, and a separate MuJoCo environment. The most useful outcome is the connection between those stages: design decisions become spatial constraints, semantic parts become controllable mechanisms, and each runtime receives the representation it needs.

Further work includes refining the web lighting and close-up surfaces, testing performance across more devices, and calibrating the physics parameters. The browser experience is currently demonstrated locally; the captures in this article document its working interactions. This project brings together the work I enjoy most as a technical artist: directing a visual result, solving the asset and pipeline problems behind it, and making that result usable in a real-time system.