Written: January 2017


Walk through the history of Washington State's Columbia River Valley wine region in virtual reality to uncover the story of the region and the craft of winemaking.

Here's a video of the demo taken during the first phase of early prototype user testing.

Figure 0: A shot from user testing with the Oculus Rift


Read on for the full process.

The Problem

As covered in The UX of Wine, wine retailers and producers don’t give consumers the information and tools they need to make purchase decisions.

When we left off, I was preparing to build a virtual environment to test prototypes of physical spaces, such as a better way to organize and display wine in liquor stores. This is an appealing concept, but it’s a two-part process: identifying the best store design, then implementing that design to see if real-world improvements match up to the VR improvements.

I needed something testable, but building a wine store to test VR findings wasn’t in the three-week scope of the project. Prototype, pivot!

The Solution

I had a few distinct ideas for VR prototypes which I pitched to mentors at Fresh Tilled Soil. After my presentation, Trish pulled me aside and articulated the idea that was staring me in the face but I couldn’t see: just build a virtual vineyard tour. Thanks Trish.

Figure 1: Product matrix for possible VR prototypes taken from a product roadmapping exercise

Lesson: it’s easy to get caught up in the avant-garde ideas, but sometimes the best solutions are the most simple.

Why Virtual Reality

One of the best ways to fall in love with a wine is to walk through the vineyards and wineries from which it is produced while soaking up the sights, sounds, and smells associated with the process of creating the wine.

Although there are no smells or tactile sensations involved in virtual reality (yet), my guess was that being immersed in a virtual vineyard could be an engaging and educational experience.

Let’s test it! I had three weeks until my deliverables deadline.

The core concept is to show the history of the Columbia River Valley over the last 10,000 years, then how the wine is produced in the region today.


After using the demo, users would rather buy Columbia Valley wine than California wine and would associate the virtual experience of the valley with wine in stores.

In retrospect, this is a bad hypothesis because it requires users’ wine preferences to exist as a tabula rasa. A better version would compare users’ preferences before and after experiencing the demo without comparing another wine region. Regardless, it narrowed the scope of the prototype and gave me test requirements from which to design.


Day one began with exploration of the technology and by modifying Unity example projects. With that out of the way, I spent the rest of the week storyboarding and synthesizing scene requirements based on the information I wanted to portray to users.

Weeks two and three were spent in Unity.

Cleaned-up, the process looks like this:

Week 1


Requirements -> SDK -> Storyboards & Scenes -> Concept Art ->

Week 2


Textures -> Terrain -> Placeholder Objects -> Content -> Lighting ->

Week 3


Audio-> Testing -> Fixes -> Testing -> Deliver

Week 3+


Revising Content and Terrain -> Demos ->

Why Unity

Unity was unfamiliar to me, although I chose to use it for the prototype due to easy VR support and extensive documentation. Although the UI isn’t the greatest, Unity ended up being a good fit for the scope and requirements of the project.

Figure 2: Unity + Visual Studio UIs

I briefly explored using Valve’s Destinations software with photogrammetry, but the fact that it was December in Boston meant that finding a vineyard to tour and photograph would be a challenge (and likely unsuitable).

As I write this (early 2017) much of my VR prototyping is now done in A-Frame. For a run-down of the most popular VR-compatible SDKs and headsets, check out this document.

Asset Pipelines

I have no formal training in game development, so I improvised my pipelines based on what seemed logical. In the future, I would spend more time on concept art and make more use of placeholder meshes early on in the process.

However, I did a good job of translating lighting concepts into Unity. Toot toot.



Concept Art in Photoshop -> Textures in Photoshop -> Terrain and Lighting in Unity



Concept Art in Photoshop-> Scene Requirements in Docs -> Meshes in Blender -> Textures in Photoshop -> Assembly in Unity



Scene Requirements in Docs -> Sound design and composition in Bitwig -> Implementation and mixing in Unity

Environment Design

After familiarizing myself with the toolset, I began storyboarding and collecting information on the Columbia River Valley. Instead of recreating a real winery, I took influence from several locations to make an environment that was suggestive of a vineyard in the valley.

Figure 3: Clips from storyboards and concept thumbnails (I am an artist in my dreams)

Next, I painted up a few thumbnails to explore lighting and color concepts for the environment. Using shots of the Hood River Valley and the Columbia River Valley as reference, I settled on a sunset mood.

Finally, I went heads-down in Unity for two weeks and built a virtual vineyard. That’s a bit “draw the rest of the owl”, but instead of walking through the process linearly, I’m going to cover key points (and mistakes) in the sections below.

Showing vs. Telling

Scattered through each scene of the tour are plaques telling the history of the Columbia River Valley, spanning from 10,000 years ago to modern day. As the user progresses through the valley, they “walk” through time past the ice age, through Native American civilization, white settlers and pioneers, and into modern vineyards, ending with a wine display overlooking the setting sun across the river.

Figure 4: Informational plaques clipped from history books, Wikipedia, and a NOVA documentary

Given more time, most of the plaques could be switched from “tell” to “show,” using character interactions, real-time geological animations of receding ice, population changes, pioneer lifestyles, and vineyard cultivation. The drawback is that production is expensive and requires multi-disciplinary teams or a talented multi-faceted 3D artist/developer/designer individual with a lot of time.


Scale and distance is a big deal in games and even more so in VR. Being too close to an object in VR (especially if it is lifelike or dynamic) is a bit viscerally terrifying and claustrophobic–you feel the presence in the back of your throat and chest. Additionally, player height is tricky when placing teleport nodes (more on that later) and composing scenes.

Many of my placeholder objects and terrain details were off-scale, leading to a very surreal vineyard experience in the beginning. I went back and fixed the biggest problems using playerheight as a reference, although I’m sure there is a better way to handle scale in Unity. Next time.

Lighting & Post-Processing

See Unity’s post-processing stack quick-start guide on Github. Everything is more vivid in VR, making tweaking post processing settings slow. Hopefully this is resolved now that we can build while in the headset.

Figure 5: An early title shot, later scrapped. The sun sets after 80,000 frames.


Fun stuff, physics. I modeled lights on a scaffold that I wanted to string along a la hipster “Edison” string lights. The idea was to use configurable joints to make a string of long, thin rectangles into ropes, from which the lights would hang.

Instead, I spent several days fiddling with configurable joints, prefabs, and different meshes, and ended up with spectacularly exploding chains of string lights, probably due to using the wrong kinds of meshes, that I didn't have time to troubleshoot. Perhaps another iteration of the vineyard tours will have real-time string light physics. Either way, configurable joints are cool. This is a good write-up if you’re using them.


Locomotion is everyone’s big question with VR. I went with teleportation because it’s more accessible than gamepad or WASD free-roam (which many people can’t stomach) and allows you to compose tight scenes without having to account for much range of movement.

Figure 6: A top-down map of all teleport nodes in the prototype's final version.

Restricted vantage points also allow you to cleverly wind your map around by blocking viewing angles using objects or effects, saving resources and distance.


Due to the novelty of VR, users spent the majority of their time in the first 15% of the experience. They were soaking in the view, looking at the grass, marveling at the light filtering through tree leaves. I assumed incorrectly that people would breeze through the initial few teleport points to get to the good stuff, when the valley opened up in front of them and the plaques shared rich historical anecdotes.

Instead, the simple fact that they were in VR and seeing grass sway in the wind was so engaging that everyone spent their time looking around the dullest first three locations, then breezed through the vineyard and settlement because the sun had set after 80,000 frames.

After my initial tests, I smoothed out the pacing by clipping unnecessary scenes and condensing others. I also placed more signals in the environment like old wood signs pointing down the path and vineyard rows and terrain contours that encouraged the player to look towards the next teleport point. These changes smoothed out the experience significantly for other testers.


Lindsay Burke has a good writeup about the different kinds of UX testing: user testing and usability testing. This applies to VR as much as it does to flat product design.

My initial tests allowed me to fix player teleport orientation, a confusing audio bug, move text further away from the user for readability (with the exact distance depending on the length of the paragraph), and understand where pacing was broken.

To record user tests and take more notes, I used Open Broadcaster Software. If you’re looking to cross-reference notes with recordings, set a timer when you start recording before the test and timestamp notes as you write them to avoid labelling each note with context prefixes.

After delivering the prototype on deadline, I went back to run a few more casual tests on tweaks I had made.


VR experiences are nothing if not engaging. Even at low levels of fidelity, your brain quickly goes “oh yep, I’m here. This is the world where I am” and discards reality, causing you to shuffle around and bump into things in the real world.

Figure 7: a wine display

Due to time constraints, I wasn’t able to compare users’ attitudes about wine from the Columbia River Valley region before and after the experience.

However, walking through the prototype generated a huge amount of enthusiastic discussion about wine, favorite vineyards, past experiences, and preferences. It’s no doubt that the prototype makes people excited about wine, far more so than the 2D application prototype I built previously.

If I were to do it again, I would administer a handful of more formal tests interviewing users about their attitudes towards Washington wine and vineyard tours before and after the experience to collect higher-quality qualitative information.

If you haven't yet, check out a video of the demo taken during user testing.

What’s Next?

Mobile prototypes! Although Unity on a PC is great, virtual vineyard tours will shine in wine bars, tasting events, retail locations, and industry shows. All of these are places where it’s inconvenient and expensive to roll up an Oculus or Vive rig. Mobile VR is cheap and, well, mobile.

Read another case study ->

Trevor Jon Waldorf

VR & Product