
Blossom Yard 2.0
An AR/VR-based museum exhibition innovation project, originating from the Architecture Department's Museum Renovation Project. Through immersive digital technology, display undisplayed artifacts, preserve original artifacts, and provide innovative interactive display methods for architecture department exhibitions.

25.10-11 Individual work
TYPE: Individual project — Personal
ADVISOR: Min Ter Lim
KEYWORDS: Interactive installation; physical computing; embodied interaction; prototyping; user testing; storytelling
TOOLS:
Spatial / Visualization: Rhino; Grasshopper; AutoCAD; Lumion; Blender
Interactive / Build: Unity; Arduino; Xcode (iOS)
Project Origin & Problem
During a field visit to the NCKU Museum for an architectural renovation studio, I noticed an exhibition gap: many artifacts are preserved but rarely displayed, and architectural proposals are mostly communicated through drawings, renderings, and protected physical models. This format is static and often requires professional knowledge, leaving visitors with limited interaction and understanding. To bridge this gap, I like to try something new in terms of architectural exhibition, so I designed a mobile AR/VR app and an exhibition-mode trigger: an FSR embedded in a physical model that advances the VR scene through Stage 1 → 2 → 3.

Research
1-1
Taiwan University Museum Challenges
Taiwan's university museums often have a dual identity—research-oriented yet expected to serve public education. In this project, these conditions are treated as constraints: limited visibility, low student participation, and mostly static displays suggest the need for a lightweight, plug-in digital layer that can increase engagement without changing the existing exhibition infrastructure.
1-2
Visitor Motivations & Barriers
These patterns translate into three design requirements: fast entry (short sessions), guided storytelling (reduce cognitive load), and shareable moments (increase perceived value).
1-3
NCKU Exhibition Types Distribution
These findings narrow the deployment scenario to department-led special/temporary exhibitions, where content is modular and proposal narratives are frequent.
1-4
Positioning & Constraints
A Single-Station Exhibition Module
I scoped this project as a single-station exhibition module, not a museum-scale redesign. It is designed as a replicable, low-setup interaction unit that departments can plug into special/temporary exhibitions, especially those involving campus history and proposal comparison.
Reality Check: Budget & Feasibility This scope reflects real constraints.
A funded AR/VR exhibition case operated around NTD 400,000, while large-scale student showcases (e.g., 5th-year graduation exhibitions) can reach ~NTD 1,000,000+ and typically require institutional support. Rather than scaling to a full AR/VR exhibition, I focused on a high-impact unit that delivers narrative and interaction with minimal space and staffing.
COVID Context: Digital Was Necessary
During COVID, exhibitions shifted to online formats and remote critiques, showing that digital publishing can keep work visible when physical venues are unavailable. This project extends that lesson by designing an experience that can operate as a lightweight exhibition layer, rather than relying on large-scale physical setups.
Design Implications
The module is designed to be fast to deploy, easy to understand, and scalable across department
1-5
Case Study:
Large-Scale AR/VR Exhibition → Lightweight Adaptation
NCKU's 1643 Zeelandia VR shows how immersive media can communicate atmosphere and historical context, but it also requires training and on-site support. I adopted the storytelling principle while re-scoping the delivery format into a single-station module suitable for department-led exhibitions.
Key takeaway: atmosphere-driven storytelling is effective, but full-scale VR requires training and on-site support—so this project translates the idea into a deployable single-station unit.
Target Visitors & Personas
NCKU Museum is not a default destination for most visitors. In practice, people arrive on campus for other reasons—passing routes, Rongyuan’s trees, or a quick “check-in” tour—then decide within minutes whether to engage. Therefore, I defined three personas around real campus behavior and designed the experience to work as a low-effort, high-clarity interaction: short, guided, and easy to share.
2-1
Persona
Persona 1:
These are NCKU students from non-history majors who often pass the museum area but rarely enter. They know the museum exists, yet they do not know what they will “get” from it—and they rarely hear about any activities. For this persona, the key is low entry cost: a clear payoff within a few minutes and a guided flow that does not require staff explanation.
Persona 2:
Families visit NCKU mainly for Rongyuan and a campus stroll. The museum is recognized as “there,” but the exhibition content is often perceived as too quiet or too adult for kids. For this persona, the experience should feel hands-on and story-like, ending with a simple, child-friendly takeaway (a photo moment or a small card).
Persona 3:
Many out-of-town visitors come to NCKU as a landmark—big trees, photos, picnic—while museums in the city center remain their main cultural choice. The museum is often off the route and lacks a visible reason to enter. For this persona, the most realistic strategy is not large-scale promotion but shareable output: a quick “I was here” moment generated by the app (photo/video overlay, digital postcard, or a small printed card).
Across all three personas, the interaction must be:
1. Fast to start (one obvious entry point),
2. Short and guided (no open-ended wandering),
3. Easy to understand (one-sentence promise),
4. Easy to share (digital output + optional small takeaway card).
Experience Design(Scenario & Flow)
This chapter translates the architectural renovation proposal into a staged, mobile AR/FPV experience. Instead of asking visitors to read drawings and models, the app guides them through Stage 1 → Stage 2 → Stage 3 to feel the atmosphere shift (from the past to the renovation proposal) and compare design intentions.
The chapter starts with a scenario-based user flow, then breaks down the stage logic, scene transitions, and the FSR-triggered interaction.
Early scenario sketch (exhibition + outdoor extension)
3-1
Visitor Scenarios
These scenarios let visitors compare the renovation proposal with the existing courtyard, both indoors (model station) and outdoors (on-site points).
Indoor: model-based station (postcard/floorplan)
Exhibition: multiple models / public setup
Outdoor: scan + visit real courtyard points
3-2
User journey
3-3
Highlight-Stage logic(From past to Renovation Proposal)
The three stages are derived directly from the renovation proposal, designed to reveal atmosphere differences step by step. Each stage reveals distinct design intentions—spatial mood, material/lighting cues, and the overall courtyard narrative—so the comparison remains readable. This staging avoids open-ended wandering and keeps the experience short, guided, and repeatable.
Top: Existing courtyard (archival photo) → Proposal rendering Bottom: Stage 1 → 2 → 3 (guided comparison in FPV)
3-4
Before&After-How Our proposal works in spatial context
The “backyard” is not a metaphor—it is the renovation proposal’s core narrative: turning the museum's leftover open ground into a calm, garden-like everyday space. We referenced the idea of a “Blossom Spring”—a quiet refuge discovered step by step—so the experience is designed to ''gradually'' soften from a museum-like viewing mode into a garden atmosphere. This is why Stage 1→2→3 is a transition, not a hard switch: each stage adds spatial mood cues that reflect the proposal's intended backyard comfort.
The transition is implemented as a soft fade with timed environmental cues—vegetation density, ground texture, and lighting warmth—so visitors feel the courtyard becoming a “backyard.”
System Design & Implementation(Logic & Build)
This chapter translates the architectural renovation proposal into a staged, mobile AR/FPV experience. Instead of asking visitors to read drawings and models, the app guides them through Stage 1 → Stage 2 → Stage 3 to feel the atmosphere shift (from the past to the renovation proposal) and compare design intentions.
The chapter starts with a scenario-based user flow, then breaks down the stage logic, scene transitions, and the FSR-triggered interaction.
4-0
App Flow & Module Overview
End-to-end flow from mode selection to stage control (UI + FSR), and AR image-target pipeline.
4-1
Technical Configuration
System overview: content pipeline, mobile AR/VR(FPV) stack, and FSR-triggered stage control.
4-2
VR Mode - Stage Control Logic (State + Timeline)
The stage system is implemented as a repeatable state machine (Stage 1 → Stage 2 → Stage 3) triggered by either UI buttons or FSR inputs. Instead of switching scenes, each stage activates a curated set of objects and runs a timed sequence (coroutine) to control visibility, particle effects, and atmosphere cues. A unified timeline is used to keep transitions predictable and comparable across visitors, while key parameters (rise height, fade duration, and animation timing) remain tunable in the SceneStateController for fast iteration during on-site setup.
4-2.1 Stage triggering
UI/FSR-triggered state machine with a unified timeline for Stage 1→2→3
4-2.2 Unified Timeline Visualization + Unity Inspector
Unified timeline + tunable parameters — stage durations and object states are executed as timed coroutines, with key parameters exposed in Inspector for fast on-site tuning.
4-3
Stage Transition & Atmosphere Design
4-3.1 Transition Cues Between Stages (Narrative + Mood)
“Here, backyard is not a leftover space behind a museum—it is a Peach Blossom Spring (桃花源) metaphor: calm, enclosed, and quietly alive.”The stage transitions are not treated as hard scene switches. Instead, I use a set of consistent atmosphere cues—fog, rain, and fireflies (built-in particle systems), together with two key spatial anchors: the courtyard trees and the pavilion. These elements are designed to connect the “existing baseline” to the “proposal space” while keeping the experience calm, readable, and emotionally coherent.
Trees + Pavilion — a blurred boundary between nature and architecture (Stage 1-2)
The pavilion is not only a new object; it reshapes how the courtyard is experienced. Together with the existing trees, it creates a space where visitors can move between nature and architecture without a strict boundary. This “blurred zone” is the core of the backyard narrative: not a leftover green area behind a museum, but an inhabitable field with comfort and depth.
Dissolve shader → tree + pavilion reveal language
Fog + Newsettings Rise — proposal “arrives” (Stage 2)
When fog appears, the proposal is introduced as a physical change rather than a visual overlay: the extension gallery / pavilion gradually rises during the mist phase. This links the “Peach Blossom Spring” mood to an architectural action—an arrival that feels calm and intentional.
Rain + revival — turning the proposal into a living garden (Stage 3)
In Stage 3, rain functions as the main revival cue: the garden gradually grows in after the rain starts, shifting the courtyard from a leftover open ground into a livable resting landscape. Fireflies and people are added as secondary cues to reinforce that the space is now active and inhabited—not just visually greener.
Rain (particle) + Garden rise (animation) → revival + liveliness
Fireflies/people → supporting atmosphere
4-3.2 Dissolve shader breakdown
Stage 2 “proposal emergence” uses a shared dissolve-reveal material system across trees, newsettings, and the pavilion, so the shift reads as one continuous spatial mood change rather than a hard scene swap.
Mask + Noise drive the reveal threshold (dissolve progression).
The shader exposes per-object inputs (Base / Normal / Mask) and shared controls (Cutoff / Edge Width / Edge Intensity), so it can be reused consistently across assets.
Alpha Clip / Alpha performs progressive pixel “cut”, enabling a controlled reveal that is easy to tune on-site via the Inspector.
Reusable URP Lit dissolve shader (mask + noise) with Inspector-exposed controls for consistent stage-to-stage reveals.
4-4
FSR Trigger (Exhibition Settings)
To support a staff-free exhibition setup, the experience can be triggered through three FSR pressure sensors hidden under physical display points. Each sensor maps to a stage (A → Stage 1, B → Stage 2, C → Stage 3), allowing visitors to “press the model” and immediately see the corresponding courtyard atmosphere transition on their own phones.
During prototyping, the system ran on a single-phone hotspot for quick iteration. For exhibition deployment, the ESP32 can send UDP broadcast over the venue WiFi so that all devices on the same network receive the same trigger simultaneously—no pairing required.
To keep the interaction stable, the ESP32 applies lightweight signal smoothing + hysteresis, and the Unity stage controller ignores repeated triggers while a stage transition is already running (state guard / cooldown aligned with the transition timeline).
Test video captures the full loop: pressing an FSR sensor generates real-time debug output (Xcode console) while the mobile Unity scene updates its stage transition simultaneously.
Hardware setup
Hardware mapping for stage triggers. Three FSR sensors (A/B/C) are placed under different physical touchpoints and mapped to Stage 1/2/3. The ESP32 reads sensor pressure and sends trigger packets over WiFi to the mobile Unity app.
FSR Broadcast System Architecture
FSR-to-stage pipeline with UDP broadcast. Pressure signals are normalized and smoothed on the ESP32, broadcast as lightweight UDP packets (A,B,C,mask), and received by any mobile Unity client on the same network. The parsed trigger calls OnFSRStageTriggered(stageIndex) to update UI feedback and run the Stage 1→2→3 transition logic.
4-5
AR Mode (Image-Target Preview)
AR Mode is designed as a lightweight, phone-based entry point for the exhibition.
This AR layer functions as a quick “proposal-in-place” preview: visitors can immediately understand different phases of architectural drawings' spatial intent by directly referring to the pop-up 3D models and how the pavilion reshapes the backyard experience and how the new architecture negotiates a blurred boundary with existing nature—without requiring a headset or staff guidance.
AR preview on printed plan/postcard(site plan). Pavilion and courtyard trees are anchored by a Vuforia Image Target for stable scale/alignment in exhibition settings.
Instead of relying on plane detection, the system uses Vuforia Image Targets to anchor the proposal onto a printed site plan/model board, so scale and alignment remain stable under exhibition conditions. Once the target is detected, all digital elements (pavilion, courtyard trees, and optional atmosphere cues) are spawned under a single ARContentRoot, making it easy to iterate and debug as the on-site setup changes.
To keep behavior consistent across VR and AR, AR Mode reuses the same Stage 1→2→3 state logic (visibility + effects sequencing), but simplifies interaction for mobile use. In exhibition setup, this becomes a self-guided preview that requires no staff instruction and works on any device connected to the local WiFi.

Phone View: Image Target detected → AR content aligned to the printed plan.
Unity Scene/Hierarchy: ARContentRoot groups all spawned assets for fast iteration on-site.
Vuforia Configuration: Image database + tracking settings for stable recognition.
iOS Build Settings: ARKit enabled + iOS permissions configured for deployment.
4-6
UI Layering (What users see vs What dev uses)
Entry:Intro → Mode Panel(VR / AR)
Triggers(2 ways):Mobile UI Button / Physical FSR(UDP)
VR path:Model Panel → Menu/Stage Panel → Stage 1/2/3
AR path:AR Scene → Image Target → Pop-up model/layers
Early UI iteration sketches: mapping the VR/AR entry flow, stage controls (1/2/3 + restart), and feedback cues before implementing the panel-based controller system.
VR/AR UI flow: From Intro → Mode selection, users progress through Stage 1–3 in VR, or scan an Image Target to preview layered design elements in AR—both driven by the same stage/state logic.

































