Limitation

1. The Performance

1.1 The Performance Dilemma

While our client-side 3D synthesis engine enables a highly modular experience, it creates a significant performance bottleneck. On mobile devices with limited RAM/VRAM, the "Summoning" process (assembly and rendering) can experience stuttering. This is primarily caused by the volume explosion of the final binary blob after Three.js decompressing, merging, and re-exporting 3D assets.

1.2 Strategic Rationale

Why stick to this architecture if performance is a challenge? Here is our strategic rationale, broken down into four core pillars.

Seamless AR Integration

Challenge:

Native AR engines (iOS Quick Look / Android Scene Viewer) only accept a single file path. Simple CSS layering of assets works on the web but breaks in AR, where mascots and accessories disappear.

Strategy:

By "welding" components into a single binary Blob via GLTFExporter, we ensure spatial persistence and visual consistency across the Web-to-AR transition.

Modular Scalability

Challenge:

Pre-rendering every possible combination (12 spots 脳 10 outfits 脳 5 accessories) would require storing thousands of massive GLB files.

Strategy:

We adopted an "Atomic Asset Pipeline." Codes act as an assembly line, dynamically mounting parts. Adding a new outfit now only requires a few KB of data instead of regenerating the entire library.

Client-side Edge Computing

Challenge:

Serverless platforms like Vercel impose strict 4.5MB payload limits, making it impossible to process or transfer uncompressed 3D streams server-side.

Strategy:

We offloaded the heavy lifting (3D parsing/merging) to the user's device. This eliminates server costs, reduces network latency, and allows for offline-ready interactions.

Quality-Efficiency Trade-off

Challenge:

Manual AR implementations are often brittle and visually inconsistent; hand-rolled approaches can produce visual artifacts, misalignment, and unreliable behavior across devices.

Strategy:

We utilized a dual-engine approach. Three.js handles the 'Logic & Assembly,' while <model-viewer> handles the 'Presentation.' This allows us to leverage Google鈥檚 PBR (Physically Based Rendering) engine for industry-grade visual fidelity without building a custom renderer from scratch.

Client-Side Component Synthesis and Rendering

1.3 The Iteration Log: Failed Attempts

We went through several pivots to balance AR compatibility, platform limits, and mobile performance.

Trial 1

DOM Slot Nesting

Approach

Nesting mascot models within building slots via <model-viewer>.

Pivot

Mascot disappeared in native AR mode. We prioritized the "Playful AR" core experience over simple UI layering.

Trial 2

Serverless Backend Compression

Approach

Sending raw 30MB streams to a Node.js API for gltf-pipeline compression.

GitHub: compress-model branch

This version is for backend compression. You can clone the branch and run it locally.

Pivot

Hit the Vercel 413 Request Entity Too Large error. The 4.5MB payload limit proved to be an insurmountable wall for raw 3D data.

Trial 3

Client-side Draco WASM Compression

Approach

Integrating Google鈥檚 Draco encoder on the client side via CDN.

Pivot

Draco only compresses geometry (meshes). Since 90% of our file size comes from Raw Bitmaps (textures), the reduction was negligible, while CPU usage spiked significantly.

1.4 Future Roadmap

To overcome the current 4.5MB barrier:

Our next architectural evolution involves migrating to a Dedicated VPS Environment. By maintaining a persistent Node.js environment, we can implement real-time server-side texture transcoding (to WebP or KTX2) and Draco mesh compression, serving optimized, ready-to-render assets that significantly reduce mobile memory overhead.

2. Location Asset Expansion

2.1 User-Interest-Led Content Scaling

Next step: scale places based on real user interest

Based on survey findings, our next content iteration will prioritize expanding location assets for the places users are most interested in exploring. We will preserve a unified visual language across all new spots, including composition logic, mascot interaction patterns, material quality, and color tuning, so that every new location feels consistent with the existing Campass world while still introducing fresh context and discovery value.

2.2 Style Governance for New Location Assets

To keep expansion sustainable, we will establish a lightweight asset governance checklist before introducing new spots into production. This includes a shared art-direction baseline (camera framing, mascot scale ratio, color harmony, and texture sharpness), reusable interaction templates for key touchpoints, and a final consistency review against existing landmark scenes. With this process, we can keep the world visually coherent while increasing content breadth based on measurable user demand.

2.3 Future Iteration Plan

In the next iteration cycle, we will rank candidate locations by survey preference, engagement potential, and production complexity, then release them in phased batches. This phased rollout allows us to validate whether newly added locations improve session duration, revisit rate, and AR interaction completion, while still controlling memory footprint and maintaining stable performance on mobile devices.