• CanadaPlus@lemmy.sdf.org
    link
    fedilink
    arrow-up
    0
    ·
    5 months ago

    Yeah, that’s pretty typical for a lot of computing these days. People are talking about exotic things like in-memory processing as a way forward because of that.

    Is that the whole thing, or is there something more specific to VR? You can make a smartphone no problem, but portable goggles end up with an ungodly short battery life.

    • Elise@beehaw.org
      link
      fedilink
      arrow-up
      0
      ·
      5 months ago

      The battery life is actually one of the downsides of accessing a lot of memory. A typical way to solve this is to do a depth draw first and then another one that actually samples textures. Textures and even meshes use a lot of bandwidth. But that won’t work for all devices because many use their own special ways to solve this by using a screen grid with buckets and depth sorting the tris.

      A unique issue for vr is that you have to render for two eyes and at a high frequency. A typical mobile game might target 30 fps instead of the typical 60 when running on battery. On the contrary, if a vr game would run at 60 fps you’d get nauseated pretty easily. A low end device will run at 100, and in an overly simplified sense that means you’re actually doing 200 fps because of the two eyes. Further, you have to consider the tracking cameras. I am not knowledgeable about those but it’s safe to assume they need to send a lot of data around.