this post was submitted on 24 Jun 2024
82 points (97.7% liked)
Asklemmy
43336 readers
820 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- [email protected]: a community for finding communities
~Icon~ ~by~ ~@Double_[email protected]~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Alright then. Thanks for the info!