Forum Discussion

🚨 This forum is archived and read-only. To submit a forum post, please visit our new Developer Forum. 🚨
SvenViking's avatar
SvenViking
Expert Protege
11 years ago

Ways to avoid tearing on Gear VR?

In his Mobile SDK talk, Johannes explains quite a bit about screen tearing on Gear VR, but I didn't really understand how it should be avoided. I'm seeing reasonably frequent tearing in my game while maintaining 60fps, and I'm guessing it may be related to certain screen tiles taking much longer to render than others, but that's not really avoidable in my case since almost all the graphical detail needs to be spent on objects on a table in front of the player, with very little detail needed above the table.

9 Replies

Replies have been turned off for this discussion
  • Sorry but you probably need to reduce the complexity of the objects on the table. As an experiment, you could try to spread the work across more tiles using a multi-pass approach. You would have to render the complex objects to a texture with a narrower FOV and then sample it in the final pass. But my guess is that the overhead of the extra pass would outweigh any speedup here.
  • Thanks for the information :/. Is tearing something that's affected much by higher or lower throttling settings, by the way?
  • Yes. If content in any tile is too complex, the same optimization rules apply. Try to reduce the pixel density, shader complexity (simple lookups over complex specular/parallax/interpolation math), texture bandwidth (use mipmaps, ASTC compression and GLES 3.0). You can learn a lot about the complexity of your content in Unity's Scene view drop-down http://docs.unity3d.com/Manual/ViewModes.html.
  • Also, make sure your GPU level isn't too low or power save is active. You can look at the logcat or use OVRModeParams to detect if you're in power saving mode.
  • Thanks again. I think I'm doing most of that (shaders are vertexlit or unlit with lightmaps, textures have mipmaps and ASTC compression, GLES 3.0 is used). I am using blended textures on the terrain, but the tearing was occurring before I added that. Eye texture resolution is the Unity default.

    Thanks also about the Scene view modes -- I hadn't thought of checking those. I don't notice anything obvious other than the tiling wallpaper texture being higher-res than necessary (is that likely to pose a problem? Note that it's the correct resolution when looking at the wall behind the player, but I could arrange something to deal with that), and that all the game objects are necessarily concentrated on the table where gameplay occurs. There are a couple of things I can still do to reduce draw calls, though. If necessary I can reduce the number of trees, just unfortunate since the game runs smoothly overall (and ran even faster with past Unity/SDK versions).

    Edit: Sorry, missed your second message. I'll double-check that. Throttling levels were at 2,2 last I checked.

    OverdrawView.jpg
    RenderPathsView.jpg
    mipmapsview.jpg
  • That all looks pretty reasonable. Another consequence of tiled rendering is that draw calls get duplicated between tiles. That means you should aggressively minimize the number of vertices and batches. 100k total verts/tris and 100 total batches is a good target. I see you're within that range, but the complexity seems to be concentrated in the lower half of the screen like you said. So you probably need to bring down the number of verts/batches in that area.
  • OK, thanks again, will see what I can do.

    By the way, I don't know if this matters, but the GetComponent calls in OVRManager.Update() are allocating 0.6KB of garbage per frame which seems to be causing a garbage collection every few seconds (in the editor at least).
  • I see 0B/frame. Can you provide a callstack or minimal project that reproduces the issue?
  • Ah, interesting -- will send via PM. For whatever reason, for me it's been like that since the previous Oculus Utilities version or earlier.

    Edit: Seems like it happens when the OVRManager script is attached to a GameObject without an OVRCameraRig. I have it on a separate GameObject because I switch between two OVRCameraRigs.