Blender → Next.js in 7 days
The Herbacare brief landed on a Monday with a Friday-the-week-after deadline. The client wanted a VR walkthrough for an exhibition floor and a companion website that could survive after the exhibition ended. The brief was vague on technical specifics and firm on the public date. I had seven working days.
This is the pipeline that survived the deadline, the parts that held, and the parts I'd cut if I had to do it again.
context
Herbacare was a UGM herbal-medicine research project. The exhibition floor was a public-facing showcase — visitors would put on a headset, walk through a virtual representation of the plants and their compounds, and pull off the headset wanting to know more. The companion website was the more: a place where the exhibition could live online after the booth came down.
The two real constraints:
- Visitors don't read. Information panels next to a glass case are the medium they're competing with. VR can be better than panels but only if the affordances are immediate.
- One week. No iteration cycles. Everything had to ship at v1 or it wasn't shipping.
the pipeline
The path the project took, with timing:
- Day 1 (Monday): brief synthesis, scope cuts, model list. Decided to cut three of the original eight plant scenes. Three working scenes shipped > eight broken ones.
- Days 2-3: Blender modeling. Two plant-room scenes, one transition space. Baked all lighting; no real-time GI. Poly budget set hard at 80k per scene.
- Day 4: glTF export, runtime integration with the VR headset (Meta Quest). Most of the day was format gotchas — texture baking, normal-map conventions, scale factors.
- Day 5: Next.js companion site. Same hero imagery from the VR scenes, exhibition copy, post-event lead-capture form.
- Day 6: integration testing on the actual headset hardware at the venue. Found three model issues I'd missed in desktop preview.
- Day 7: rehearsal, queue management for the booth, final polish on the companion site.
the web side — what next.js was for
The companion site had three jobs:
- Before the exhibition: marketing surface for the event itself. SEO, social cards, event details.
- At the exhibition: QR-code landing page visitors hit after taking off the headset. Carries the more — the science, the citations, the way to follow the research.
- After the exhibition: archived experience. Static, low-maintenance, lives indefinitely.
Next.js was the right call for job 3. Static export, host on Vercel, the site stays free to serve in perpetuity. Two years after the exhibition the site is still online, still costing nothing, still occasionally referenced by people who'd missed the booth.
The wrong tool for job 3 would have been any framework that required active hosting infrastructure — a Rails app, a Django site, anything with a server process. The exhibition would have ended, the budget would have lapsed, the site would have rotted. Static export was the no-maintenance posture.
what shipped + what i'd keep
Outcomes:
- The VR experience ran on the exhibition floor for three days. Roughly 200 visitors put on the headset over those three days; informal observation says ~85% of them stayed for the full 4-minute walkthrough. The exhibition staff said visitors lined up twice — once for the headset, again for the conversation afterwards.
- The companion site captured 80-something email signups during the event window. The research team used the list for follow-up content.
- The site is still live in 2026 with no maintenance. Static export was correct.
What I'd keep from the pipeline:
- Baked lighting in Blender, exported via glTF. The single most defensible technical decision.
- The "cut three scenes" call on day one. The instinct to scope-cut early is the only reason the project shipped.
- Static-export Next.js for the companion site. Zero-maintenance was the right brief for the after-life of an exhibition.
What I'd swap:
- The VR runtime itself. I used a stack that worked but was finicky around export quirks. If I were doing this in 2026, I'd use React Three Fiber + WebXR; the browser-based path has matured enough to compete with native VR runtime on basic walkthroughs, and the build / iterate loop is significantly tighter.
- Texture baking workflow. I did it ad-hoc; I'd write a script next time. Two of the three model issues I caught on day 6 were texture problems that would have been caught by a deterministic bake pipeline.
the meta-lesson — the brief is the architecture
The thing the seven-day deadline taught me, that no longer-timeline project ever has:
The brief itself is most of the design. By the time I'd cut from eight scenes to three on day one, the project's shape was 80% decided. The remaining six days were execution. The decisions I'd otherwise have agonized over — should the transition space have ambient sound; should the lab call-out appear on the companion site; should there be a printed handout — were forced by the timeline into clean cut or keep decisions, made fast.
I don't think every project should be a seven-day deadline. I do think every project would benefit from running its scope through the what would I cut if this had to ship in seven days filter. The filter forces decisions that infinite timelines hide.
The Herbacare VR pipeline isn't reusable wholesale. The instinct it taught — the brief is the architecture; cut early, ship straight — has been my single most useful project habit since.
