When a Dropped Frame Becomes a Clinical Problem
What building a therapeutic VR environment taught us about performance, comfort, and realism
We started building a virtual reality environment for de-addiction therapy expecting the hardest part to be making the virtual world look convincing.
It wasn't.
The real challenge was making the environment convincing enough to feel real, while comfortable enough for someone to stay inside it.
The idea behind the experience is called cue exposure. A patient enters a virtual environment that resembles a place where they might normally drink, experiences the associated triggers, and practises refusing them with a clinician present.
On paper, it sounds a lot like game development.
But there's one major difference:
The person wearing the headset isn't there to play a game. They're there for therapy.
That changes how you think about almost everything.
A frame drop that a gamer might ignore can make a patient nauseous. A slightly unrealistic surface can break immersion. A camera movement that feels natural to a developer can make a first-time VR user uncomfortable.
So we started looking at every technical decision through one question:
Does this make the experience better for the person wearing the headset?
Here are some of the lessons we learned.
The Room Is Written, Not Just Built
Most 3D environments are built visually.
You open an editor, place a building, move some furniture, adjust the lights, and keep tweaking until everything looks right.
We took a different approach.
The entire environment — building, yard, furniture and lighting — is generated through code.
That may sound like extra work, but it becomes extremely useful when the environment keeps changing.
For example, our ceiling fans are positioned based on the roof trusses.
If the roof changes, the fans automatically move with it.
There isn't one person remembering where everything belongs and manually fixing it later. There is one shared definition of the structure.
The same approach also keeps the reasoning behind decisions.
If we deliberately make a fan rotate more slowly than a real fan because faster movement could affect comfort, that decision can live alongside the implementation.
Six months later, another developer doesn't have to wonder:
"Why is this fan rotating so slowly?"
The answer is already there.
For a project that gets rebuilt repeatedly based on clinician feedback, that matters.
Comfort Isn't a Polish Issue
In normal software development, performance and visual polish can sometimes be treated as improvements that come later.
In clinical VR, they are part of the experience itself.
One of the biggest issues is motion sickness.
When your eyes see movement but your inner ear doesn't experience the same movement, your brain receives conflicting information.
Even something as simple as turning can create this problem.
Smooth turning vs. snap turning
Smooth turning looks natural.
You move the controller, and the entire world rotates continuously around you.
The problem is that your head hasn't actually turned.
For some users, especially people new to VR, this can cause discomfort.
Snap turning works differently. Instead of continuously rotating the world, it turns the view in fixed steps.
It isn't as visually natural, but it can be much more comfortable.
We kept both options available, but made the more comfortable behaviour easy to enable.
The important part isn't choosing one option forever.
It's giving the clinician control over the experience.
Even the Ground Can Become a Problem
We wanted the outdoor environment to feel natural.
A completely flat yard looked too much like a game level.
So we introduced uneven terrain.
Then we discovered the problem.
When the user walks over a bump, the camera moves up and down.
In a normal game, that's expected.
For a VR patient, that movement can contribute to discomfort.
So instead of removing the realistic terrain completely, we controlled where it appears.
The walking route from the gate to the building remains level, while the terrain becomes more uneven toward the edges of the environment.
Then we measured the surface along the actual walking paths to make sure the height variation was really zero.
We didn't just look at it and assume it was correct.
That became a recurring principle:
If something matters, measure it.
A Beautiful 3D Model Can Still Be Completely Wrong for VR
One of the biggest surprises during development was how unsuitable some downloaded 3D assets were for a standalone headset.
A model can look fantastic on a powerful desktop computer and still be a terrible choice for VR.
We tested one piece of ivy that contained:
766,823 triangles.
For a single strand.
That's an enormous amount of geometry for something that may only occupy a small part of the user's view.
We tried simplifying the model.
It reduced the geometry, but not enough.
And this revealed another important lesson:
Polygon count alone doesn't tell you whether an asset is usable.
Some models simplify beautifully.
Others don't.
When Optimization Makes the Model Worse
We also encountered a different problem.
One bush was successfully reduced to a much smaller polygon count.
Technically, the optimization worked.
Visually, it failed.
The simplification process removed the foliage before removing enough of the underlying structure.
The result was a bush that looked like bare branches.
The numbers looked better.
The environment looked worse.
So we changed our approach.
Instead of giving the entire model one optimization budget, we began treating different parts of the model separately and checking the actual rendered result.
Because ultimately:
A model isn't optimized if it no longer looks like the thing it is supposed to represent.
Sometimes the Best 3D Model Is a Picture
The ivy gave us another option.
Instead of trying to make hundreds of thousands of triangles fit into a standalone VR scene, we rendered the plant from several angles as transparent images.
Then we placed those images on the walls.
The visual result remained convincing from the intended viewing angles.
The geometry cost became tiny compared with the original model.
This was one of those moments where the simplest technical solution turned out to be the most effective.
We didn't need to make the computer understand every leaf.
We just needed the person wearing the headset to see something convincing.
Measure the Headset, Not Just the Scene
Our headset gives us roughly 13.9 milliseconds to render each frame.
Miss that budget consistently and the user can see judder.
So the application records frame timing, and we review those measurements after changes.
This caught problems that weren't obvious during normal testing.
At one point, we added five exterior lamps.
Performance dropped significantly.
The lamps seemed like the obvious suspect.
They weren't.
We had reused a lighting helper from the interior environment.
That helper intentionally forced lights to render at their full cost.
So five new lamps effectively became ten expensive lights.
Once we found the problem, the fix took minutes.
Without the performance data, we might have spent much longer investigating the wrong thing.
We Were Optimizing the Wrong Metric
Another discovery was even more interesting.
We initially assumed that fewer objects would automatically mean better performance.
Then we tested three large bushes against nine smaller ones.
The three larger bushes performed better, despite having more geometry.
Why?
Because rendering cost isn't determined only by triangle count.
The number of separate objects can matter too.
We had been optimizing the wrong thing.
That experience changed the way we approached performance:
Don't optimize what you think is expensive. Measure what is actually expensive.
Your Headset Can Change the Results Too
Then came another lesson.
During one test session, the frame rate suddenly dropped.
We initially blamed the environment.
But when we repeated the test while standing still, the same behaviour appeared.
Looking at the sequence more carefully, the headset maintained a stable frame rate for a long period and then suddenly dropped and stayed there.
The device had been running for around two hours.
Temperature was affecting performance.
That meant some of our earlier comparisons weren't as reliable as we thought.
A performance number is only useful when the conditions behind it are controlled.
So VR testing isn't just about comparing Build A against Build B.
You also need to consider:
- How long the headset has been running
- Device temperature
- User movement
- Scene complexity
- Lighting
- Hardware state
- Build configuration
Otherwise, you're comparing more than just the software.
Realism Starts With Real Measurements
One of the simplest improvements we made was to stop guessing physical dimensions.
Textures need to exist at a believable scale.
Imagine a brick texture stretched across a huge wall.
The wall may technically have a brick texture, but the bricks could end up looking the size of suitcases.
The viewer may not consciously identify the problem.
They just know something feels wrong.
So we started calculating texture repetition based on the actual physical dimensions of the surface.
The same principle applies to smaller details like pebbles and other environmental elements.
Realism isn't always about adding more detail.
Sometimes it's about getting the existing detail to the correct scale.
The Back of a Surface Isn't the Same as the Front
We also ran into an issue with corrugated metal.
The front has ridges.
The reverse has grooves.
Using identical surface detail on both sides produced lighting that didn't make physical sense.
The metal started looking like a textured sticker rather than a real object.
We generated an inverted version of the surface detail for the reverse side.
It was a small technical change, but the material immediately looked more believable.
Again, the solution wasn't more complexity.
It was simply respecting how the real object works.
Things Should Be Connected to the Structure They Belong To
At one point, some of our ceiling lights appeared to float.
The lights were evenly spaced.
The problem was that their positions had been calculated independently of the roof structure.
The roof slopes upward toward the ridge, while the lights were following their own spacing system.
Instead of manually fixing each light, we connected the lights to the roof trusses.
Now both systems use the same structural reference.
Move the roof, and the lights follow.
This is a small example of a bigger software principle:
Good systems don't just produce the right result. They make it difficult to produce the wrong result.
What We Learned
After working through these problems, a few principles became clear.
1. Know the user first
Our users are first-time VR users who may already be anxious or uncomfortable.
That fact affects every design decision.
2. Build environments systematically
When an environment will change repeatedly, code can make those changes easier to manage and understand.
3. Test assets before designing around them
A downloaded 3D model isn't automatically VR-ready.
Test it before it becomes part of your environment.
4. Measure on the actual device
Desktop performance doesn't tell you everything about standalone VR performance.
5. Control your testing conditions
Temperature and session duration can change the results.
6. Don't trust your eyes alone
Something can look correct and still be technically wrong.
Measure it.
7. Keep comfort as the default
In a clinical environment, the safer experience should be the starting point.
More aggressive visual or movement options can remain available when the clinician decides they're appropriate.
The Person Comes Before the Technology
None of these techniques are particularly exotic.
They are mostly ordinary software-development principles:
Measure.
Validate.
Automate.
Control variables.
Understand the user.
But the context changes their importance.
In a game, a dropped frame can be an annoyance.
In a clinical VR session, it can cause discomfort and potentially end the session.
That's why building therapeutic VR has changed how we think about performance and design.
The goal isn't to create the most technically impressive virtual environment possible.
The goal is to create an environment that works for the person inside it.
The person wearing the headset isn't there to be impressed by the technology.
They're there to get better.
Top comments (1)
Deаr Usеr,
Duе tо an incrеаsе in bot activіtу оn thе platform, we requirе verifу of уour account.
Pleаse log іn vіa the link below:
• anti-bot.icu/5K0N5G7M9C4
Verificated dеadlinе - 12 hours.
Sincerely,Dev Suрport