Ever since I stared to develop Firedrake , almost 11 months ago now, I have been constantly plagued by an odd display problem. All of the dark colors in my environments would show a bit of “ghosting” when I played the levels in the actual GearVR. This ghosting never showed in the unity editor and would not really affect the framerates, but it was an odd distraction. It was a strange shadow-like flicker, which showed around the edges of the dark shadows in my lighting… as if a candle or fire was burning and casting slight dancing shadows throughout the room. When the camera moved, then the flicker would happen as the shadow edges seemed to “reset” each frame or two, with the moving camera. It was almost like there was a low level “Bloom optimized” effect on the cameras.
Since Firedrake, uses a full throttle first person, free roaming, movement schema,
movement schemea that causes a lot of VR sickness in general among players, any type of peripheral “ghosting” in the VR images, started to lend itself to creating more of a VR sickness type of equation in the overall gameplay. So this was an issue I really wanted to fix.
I used the RealisticFPS asset from the store, to do a lot of my prototyping and building on for Firedrake, It’s a great asset and I figured there must be something buried in the code or set up on the prefab’s cameras, so I spent countless hours, trying almost every variation of camera setting and Unity quality settings, trying to find the magic mix of check boxes that would change this effect…. All for not….. I did learn a lot about how these sub systems worked in Unity, but never found anything remotely like a solution.
Next, I repeatedly searched Google, Bing and Gogoduck with terms like “Unity, Shadow dancing”, or “Unity frame ghosting, Gearvr” and would spend hours tracking back on the forum reading any and all threads for a hint of a solution to this problem. Unfortunately, I never found much concrete information about this phenomenon, but again, learned lots of periphery information on how Unity works in general.
Next, I started experimenting with different versions of the OVR toolset and the different versions of Unity. I installed and tried almost every combination of version from Unity 5.2, up through Unity 5.6.5. and no luck. On every version combination, I would build out a level and check it on the Gearvr and … there was my old friend, dancing, laughing, just at the edge….
Then, just recently I was looking on the Unity Forums for some info on some other issue I was facing (Some info on how to effectively use the Dynamic Batching capability in Unity, for performance) and came across the term, “Black Smear” Ah ha! That suddenly clicked…. I would never have thought to search with this term, but it explains exactly what I have been seeing in my VR imagery. A black “smear” around the edges of the really dark shadow areas and the brighter, light, areas on my 3d levels.
I stared reading, digging down in the various forum threads and…. Yup, this was it… and it seemed other folks, many other folks had experienced this same issue. In fact, it’s even an acknowledged bug from Oculus and not only does the GearVR suffer from this issue, the Rift also has this issue.
So what to do about it? Well, come to find out, not much. There is actually no real fix for this issue, but the best advice, from Oculus themselves, is to “design your vr environments with this issue in mind and use it as design criteria” and “use adjustments within your Chroma settings to alleviate radical changes from dark to light areas in your environments”
This basically means; “ramp up your lighting so you don’t have super darks or blown out white”. And this was a big problem for me and my level designs.
The world of firedrake is set in dark dungeons and dank crypts. Which by default, tend to traditionally be dark and barely lightup places. I had designed almost all of my environments and levels to be fairly dark and spooky, so I had LOTS of these dark/light zones spread throughout my levels that were causing these types of display problems.
…”make is a design criteria…” Ok…. Sure… My solution here was to set up a series of “torches” made up of a static “magic light crystal” and a baked point light, instead of a Unity based particle emitter traditionally used to make a fire effect of a burning torch. Then use these to light the corridors and rooms of the dungeon levels. Not using the particle emitter and using a static 40 vertex 3d model of a light crystal, allowed me to have a traditional fire torch on the wall type of effect, without the performance overhead of a particle emitter. The baked point light then acted like the fall off light from the torch/crystal prefab, and since the light effect/bug was “dancing and flickering shadows like a candle was burning” this kinda worked… making the bug into the “shadows of a burning torch”. But it still was a distraction from gameplay and overall not that effective.
Ultimately though, I had to bump up the overall ambient lighting from dark to semi dark. This cut down the overall range from the dark to light and frankly, fixed the smear problem but at another cost. This really lightened up the darker, spookier areas and corners of my levels and changed the overall feel of the game. In the end it’s a workaround that I am not totally happy with, it changed the overall darker, more photorealistic feel of the game, of which I was really striving for to a more open, cartoony feel, but the game does run much smoother now. And in the end, this is a prime example of the trade-off between what we hope to create as artists and designers, and what we can actually pull off technically with the tools at hand, as developers of VR.
The old smear, with dark lighting
The new smear, with new litup lighting.
