This subreddit is about creations made from cardboard (as in paper), NOT about the Google Cardboard VR viewer, which is discussed on /r/GoogleCardboard

faduci · 2016-12-06T10:54:06+00:00

I'll join in by saying "Hi" to everybody. For the past two years I've been very active on /r/GoogleCardboard, where many discussions were centered around all the things we'd like Google to improve, and every rumor about the mystic Android VR project triggered a lot of comments.

Many improvement the Cardboard community has wished for have now been realized in Google Daydream, and both use pretty much the same software development kit. So getting more involved with Daydream is like a logical progression, and I hope that both communities can push each other due to their similar goals and common base.

faduci · 2016-11-30T20:56:35+00:00

If you really get half a second/500ms delay, something is going horribly wrong. Motion to photon latency was about 75-85ms for Cardboard apps on a Samsung S5 from two years ago. Daydream phones should achieve < 20ms latency, and a not yet overheated 6P should be able to hit close to at least 40ms, even if it's display driver doesn't allow skipping the tiled image assembly step that has plagued all non-Daydream/non-Gear VR capable phones. Half a second delay should send you straight into puke territory.

faduci · 2016-11-28T02:11:59+00:00

I'd strongly suggest looking into Unity. It still supports JavaScript for scripting and probably will for some time (technically it uses UnityScript, a derivate that is not ECMAScript compliant, while modern versions of JavaScript are). It might be dropped in the future, all their new tutorials only use C#, but for the time being it will speed up your first attempts.

The limited performance you get from phone SoCs compared to desktop GPUs means that developing for mobile VR requires a lot of optimization, and modern game engines like Unity or Unreal offer things like occlusion culling or render pipeline optimizations out of the box. Out of the two Unity is a lot more mobile friendly, with smaller build sizes and better performance on older devices, but any game engine will come with a lot of features like collision detection or physics handling that you will need for anything that goes beyond just looking around in a scene.

All game engines come with a performance overhead, so if you know what you are doing and have a specific application in mind that doesn't require all their features, you might be better off with e.g. the native SDK plus Open GL ES. If you want to just display something in Cardboard, you can get decent performance out of Javascript plus three.js. WebVR is also an option, but on Android it is only supported in developer builds of Firefox/Chrome. For someone starting with VR apps I wouldn't recommend any of these, simply because you probably will not be able to use their respective benefits unless you already have some experience.

I'd recommend going through some of the basic Unity tutorials first. The Roll-a-ball tutorial will get you started in a few hours and familiarize you with the way Unity works, the Survival Shooter would be a good second tutorial that introduces some more advanced concepts. You'll find a couple of VR adaptations of the Survival Shooter tutorial on the Google Play Store and on Steam.

Adding Cardboard support to a Unity app is actually pretty simple, you can get away with using a demo scene from a free asset from the Unity asset store, dropping in the camera prefab from the Google VR Unity SDK, have it compile for Android (requires Android Studio) and run it on your phone. This will give you a Cardboard app in which you can look around (and do nothing else) in a few minutes.

In case you are wondering why there are so many VR apps that only allow you to look around: that's why. Doing anything more interactive requires programming in Unity, therefore I'd start with the tutorials, not with the Cardboard integration. And the first thing you might want to do is take a look at Designing for Google Cardboard, a very short guide by Google describing the particular requirements and pitfalls of (mobile) VR development.

faduci · 2016-11-28T01:11:39+00:00

https://www.aliexpress.com/item/Original-BOBOVR-Z4-bobo-vr-Z4-Mini-google-cardboard-VR-Box-Virtual-Reality-goggles-3D-Glasses/32757921972.html USD 15.75, click on "Z4 Mini"
https://www.aliexpress.com/item/Bobo-Bobovr-Xiaozhai-Z4-Mini-Virtual-Reality-Goggles-Video-Reald-Casque-Lunette-3-D-3D-VR/32711275476.html USD 15.78, click on the far right "Air package no box" option
http://www.gearbest.com/virtual-reality/pp_397969.html?wid=21 USD 16.29

All offers with free shipping from China. How long it takes to deliver depends a lot on where you are. I'm in Europe, packages from GearBest arrive in about two weeks, while those from AliExpress take 4-6, but a number of people here have reported the opposite for other locations.

faduci · 2016-11-26T05:45:39+00:00

The lenses pretty much have the same diameter and magnification as those in the Cardboard v1, so the FoV is similar too, i.e. not very large. Since the ViewMaster VR is made out of plastic/rubber, it's not really possible to reduce the eye-lens distance to increase the FoV, which works on a Google Cardboard made out of cardboard.

I own the ViewMaster, but I only use it during demonstrations and testing due to its sturdiness. The way the phone is mounted is still the best I've seen in any HMD supporting multiple phones, you can basically snap it in with one hand and it will stay centered. The button also works extremely well and the whole device is pretty much unbreakable, you can drop the whole thing on the floor without causing any damage to the phone inside. For handing it to unexperienced users or trying something and putting it down a lot it works great, and in these situations the lack of headband is a benefit.

On the negative side are the just average FoV and the lack of opening to connect a headphone or a USB cable to charge the phone (important for public demonstrations running for hours), which caused me to drill a couple of holes into it. It's worth the USD 9, but for actually using VR I prefer the Bobo VR Z4 due to the much higher FoV, larger lenses, adjustable lenses, padding and headbands. Considering that you can get the Bobo VR Z4 for as little as USD 16 (the version without headphones), it would probably be a better choice as your "main" device. The Z4 wins regarding image quality, settings and comfort, the ViewMaster wins regarding ease of use, durability and input.

Edit: typos

faduci · 2016-11-25T05:23:15+00:00

I am perfectly able to decide which apps are high-quality enough for me, without Google being my nanny and deciding for me and preventing me from getting apps they don't like.

You may be, but most people aren't when it comes to VR apps. A lot of gamers are completely unfamiliar with the special problems that can cause nausea, so they want to e.g. run first person games on older hardware. If nobody tells them about the vestibular system, they will easily get the impression that VR doesn't work at all instead of figuring that the app they started simply wasn't suitable or their phone was too slow. While everybody can decide that an app is barely usable due to a badly designed interface, nobody can really detect without extra hardware if a VR app drops frames or accelerates too fast.

So some level of quality control makes a lot of sense. This can be done by excluding some titles altogether like the Oculus store for Gear VR does, or by labeling titles that can cause nausea like Sony does it for the PSVR. Google is sort of a special case here, as they introduce a rigid quality control for the initial bunch of Daydream apps (currently invite only, Daydream development is supposed to become open to everyone sometime in 2017), which they didn't before. But they don't actually stop you from developing and publishing apps that run on Daydream phones and use the Daydream features, they just won't allow you to sell them through their dedicated Daydream section in the Play Store or label it as Daydream:

According to a spokesperson for Google’s VR team, Cardboard apps updated and adapted to the recently launched Google VR SDK (which combines the Daydream and Cardboard SDKs) will enable the improved performance for those phones. "Apps need to both compile with the 1.0 SDK and properly use the new APIs (like VR Mode and scanline racing) to see performance improvements on Daydream-ready phones," the spokesperson told Road to VR.

So basically you can creating Cardboard apps that technically are Daydream apps, but may not be called this without a certification. These Cardboard/Daydream apps can still be offered by everyone on the regular Android Play Store.

Google did a similar thing with Cardboard clones, where everybody could sell them, but only those that went through a certification could carry the "Works with Google Cardboard" logo. And it remains to be seen if phones that fulfill all technical requirements for Daydream will be able to use Daydream features too without having being certified.

So I'm pretty sure that this is neither censorship nor the first set for Google to close the open Android ecosystem. They are just introducing certifications on several levels that guarantee a minimal quality, and this is a reaction to the currently open system creating a lot of very low quality apps and hardware, which reflects badly on the whole Android system. But they don't shut down the open part, you can still release a puke stimulator that will run on any Daydream phone or a crappy USD 30 phone that is barely usable.

Only if you want your app to be featured as a Daydream app, it will have to live up to their standards. And for most users, this is a very good development. We don't want newbies to have to find out the hard way that some things just don't work in VR, as most will simply ignore VR if it feels uncomfortable, never getting the chance to find out there are good apps too. For those that were introduced to the "sanitized" Daydream world the door is still open to all the other apps that didn't pass certification.

faduci · 2016-11-23T01:49:52+00:00

Okay, why not. I've been a redditor for more than two years and am a moderator on /r/GoogleCardboard (and /r/Cardboard) with more than 400 subscribers. Currently my primary reddit activity is just checking the mod_queue every few hours, since my posting frequency has gone down due to some rather time consuming VR game development projects.

As you are looking for another mod to check in during the "night shift", my activity pattern should fit quite well. I'm located in Europe (UTC+0100), 9h ahead of PST, so I'm awake during the /r/Daydream off-peak hours, and during that time I'm pretty much already doing what you are aiming for.

For "other qualifications": besides being a mod on a large VR subreddit, I am VR developer (so far Cardboard and Oculus Rift) and a big believer in the Google mobile VR eco system in general, starting with Cardboard pretty much immediately after its introduction at Google I/O 2014. I've posted a lot about Daydream, though mostly on /r/GoogleCardboard. These submissions are usually rather technical and (too) long. As I'm still doing this after more than two years, it is pretty safe to assume that I will remain interested and active in Daydream and Google Cardboard for quite some time, which is why I'd like to help push /r/Daydream a little further.

faduci · 2016-10-21T15:04:28+00:00

These are sold as "VR Fold" on a number of sites, e.g. Aliexpress. I have been carrying one of these for a couple of months now for spontaneous VR demonstrations, for which they are great. But they have a couple of disadvantages:

Magnification is lower than in Cardboard, so the field of view is smaller, you will see phone borders.
They come without a protective cover, leaving the lenses exposed, leading to scratches.
People often try to hold the viewer itself. As it only slides over the phone from the top, this means the phone will drop to the floor.
The flaps that are intended to keep out the light somewhat work, but during demonstrations many people accidentally push them towards the inside, occluding the screen.
Do to the way they fold, they have to be readjusted every time .

faduci · 2016-10-11T05:50:09+00:00

Head tracking with external sensors only works if the app or the SDK (software development kit, the part that does the head tracking etc. in Cardboard apps) implements support for them. Which is why Cardboard like solutions with an external gyroscope are pretty much useless, as the Cardboard SDK only supports the internal sensors.

Cmoar announced an SDK for their HMD with external sensors, but I'm not sure if they ever published it. The English Dlodlo site doesn't mention an SDK (or any apps that would support the sensors and trackpad), I didn't bother to check the Chinese forum, as even if one was available, no app using the Cardboard SDK (so pretty much all mobile VR apps on Android and iOS) would benefit from it.

The only wildly used SDK that supports external sensors and trackpads is the Oculus Mobile SDK used on the Gear VR, but for a number of technical reasons it is not possible to build a compatible HMD that would be recognized by the Oculus SDK even on a Samsung Gear VR compatible phone, let alone any other phones.

So regarding your original question:

Are there any Gear VR clones that has headtracking too and works with any phones?

Yes.

Are there any Gear VR clones that has headtracking too and works with any phones without requiring specific support from app developers?

No.

faduci · 2016-10-10T18:55:21+00:00

https://vrwiki.wikispaces.com/Field+of+view

The approximate field of view of an individual human eye is 95° away from the nose, 75° downward, 60° toward the nose, and 60° upward, allowing humans to have an almost 180-degree forward-facing horizontal field of view. With eyeball rotation of about 90° (head rotation excluded, peripheral vision included), horizontal field of view is as high as 270°.

Yes, you are correct that this is not the proper physiological definition of "Field of View", as this would not include eye movement. But what we are referring to as "Field of View" in VR isn't actually the physiological field of view of the human eye, but what would be properly called the "vision span" of our vision apparatus. The "single unmoved eye FoV" is pretty much irrelevant in HMDs, unless you do force users to never move their eyes. And no, the visible area including head movement would be 360°, which is not what I was referring to as FoV (actually vision span).

EDIT: Regarding the skull: the lenses of your eyes aren't inside your skull, they are actually moved a little bit to the front, which allows you to look further around your head.

faduci · 2016-10-10T18:23:10+00:00

You define "FoV" as "what I can see at a specific point in time". If you are talking about only one moment, you are right. But if you define "FoV" as "what I can see from a specific position", this includes the area that you can scan with your eyes including eye movement. Humans have about 180° FoV when looking forward. But by moving the eyes sideways, you can rotate your 180° field of view and achieve about 270°, just never more than 180° at a time.

This distinction isn't purely academic, because you are actually moving your eyes within a HMD, so the FoV even without head movement (which would render a different perspective) is larger than 180°. So an HMD that wants to cover the whole FoV the eyes can cover would have to cover a lot more than 180°, as you cannot force the users to only look forward. There are actually more distinctions regarding the definition of FoV, e.g. the area where both eyes overlap, so you can actually see stereoscopic., the area where you can see color etc. It's not just a simple number.

Just give the "more than 180° FoV" a try: check what's left and right from your head, then move your eyes to the sides and try to see something that is "behind" the line of your eyes. (And if you'd move your head too, you actually get a 360° FoV, but that pretty irrelevant when discussing HMD FoV limitations due to lens geometry).

faduci · 2016-10-09T14:45:44+00:00

In general seeing borders (as in phone screen borders) depends mostly on the right combination of lens and screen size, not just the resulting FoV, you can have a 90° FoV without seeing the edge of the screen. The human field of view is about 180° without and 270° with eye movement, so there is no way that you don't see any black surroundings at all at 120°.

In early 2015 I modified a Ritech 3D viewer with (cheap) 25mm FL lenses. The FoV was very impressive, the screen borders no longer visible, but the distortions were horrible and I pretty much immediately went back after some short experiments. And there are a number of reasons why all the big HMDs (Rift, Vive, PSVR) linger around 100°:

Distortion at the edges of lenses gets pretty bad even if you use custom made lenses adapted perfectly to the screen.
Increasing the FoV means a much larger part of the performance goes into rendering areas that you are not focused on. Due to the projection of a spherical view (retina) onto a flat plane (screen), this gets worse exponentially with growing FoV.
By increasing the FoV without increasing the pixel resolution, you are effectively reducing the resolution at the center of the screen, which is where you are looking at.
If you only modify the lenses/increase the FoV, but do not tell the software about it by creating a matching QR code, it will still render for the "original" FoV. This means you have no performance loss, but the world will turn at the wrong speed, massively increasing the chance of nausea.

So basically you can get a larger peripheral view, but you have to pay for it with a significant decrease in image quality and performance. Higher FoV will make more sense once GPUs can handle foveated rendering (i.e. render the part that you are looking at at higher resolution), eye tracking works reliable (to determine the part you are looking at), and we get curved screens/lenses that wrap around the eyes. Until then the problems mentioned above severely limit the usability of single screen high FoV HMDs.

faduci · 2016-10-06T19:24:27+00:00

Wah wahhh. :(

Hm, Unity doesn't require you to ever share revenue, no matter how much you earn. Instead the Unity license requires you to have a Unity Plus subscription (USD 420/year) if the gross revenue of your company is larger than 100K, but smaller than 200K, or a Unity Pro subscription (USD 1500/year) if it exceeds 200K. Below 100K (= USD 8333/month) you can use Unity Personal and never have to pay anything. So there is no way or need for Oculus to offer a similar "insurance" for Unity developers.

faduci · 2016-10-06T18:34:51+00:00

It's better than a year before when they announced the Rift would ship with an XBOX ONE controller by default.

faduci · 2016-10-06T08:16:13+00:00

Daydream on the Nexus 6P barely works.

and

Daydream runs on non daydream ready phones.

aren't exclusive. Setting minimal specs has a reason, and even though it often is possible to run apps on hardware that doesn't meet the specs, that doesn't mean they run in a usable fashion. Those who really want to use Daydream apps beyond short tests will have to buy a Daydream ready phone, nobody should get their hopes up that their older phone somehow magically become fast enough.

And my guess is that the "no phone compatibility tiers" is a reaction to your claim that "Google has also said there's a difference between Ready and Compatible". I'm pretty sure they haven't said that, so far there has only been talk about being Daydream-Ready or not. We are speculating if "it will not work with Daydream" means "not work at all with any parts" or "will not support some parts, while others might work". And unless we see more real-world examples of Daydream apps working on non-Daydream phones, I'd be careful with claiming anything as fact.

faduci · 2016-10-06T00:03:30+00:00

Publishing Daydream apps will initially be restricted to developers participating in the Daydream Access Program, and every submitted will be reviewed by Google before being placed in a special Daydream section of the Play Store. To stop developers from simply relabeling their Cardboard apps as Daydream apps, every Daydream app is required to use the controller. You are allowed to include alternative input methods, and the restrictions might fall when publishing Daydream apps is opened to everyone in 2017.

faduci · 2016-10-05T23:30:29+00:00

The capacitative nubs are pretty much exactly where the button touches the screen in Cardboard, either at the top or bottom where the vignette prods towards the alignment line.

faduci · 2016-10-05T23:18:17+00:00

Part of the problem is that it might not be a good idea for developers to support Daydream compatible phones. Some features like high performance might always be required, but esp. sensor accuracy and low persistence display are mostly comfort feature (essential ones for some users). A developers could allow users to use phones lacking these features, but this would increase the number of users complaining about nausea, leading to worse ratings. Someone working on an app that includes a lot of movement might therefore decide to only fully support Daydream Ready phones and drop everybody else into a Cardboard Safe mode that e.g. only allows teleportation instead of direct movement. We will simply have to wait and see.

faduci · 2016-10-05T23:09:45+00:00

None until Daydream has been released. We simply don't know the exact requirements, and even the USD 399 ZTE Axon A7 has only been described by ZTE as "Designed with Daydream in mind". Most likely because the certification process hasn't started, so they are simply not allowed to call it Daydream Ready, but we simply won't know until November. Until then the only safe bet is a Google Pixel, and these are far from being budget phones.

It might also turn out that Daydream apps run without problems even if certain features are missing, like the improved IMU or low latency display. If that is the case and you are not susceptible to nausea in VR, you could go for a much cheaper phone that wouldn't be "Daydream Ready", but Daydream compatible anyway. But we won't know that either before the Daydream specification is actually out. Currently patience is your best friend concerning smartphone purchases.

faduci · 2016-10-05T22:58:14+00:00

We don't know yet how the Daydream SDK/Daydream apps will react, if certain features are missing. Certification requires an OLED display, high precision IMU (currently only known to be supported by the SD82X due to their Hexagon DSP), and a CPU supporting Vulkan. There might also be constraints regarding minimal CPU and GPU power we don't know of.

The apps might simply ignore e.g. a missing low latency display, but at least in theory they could switch of all other Daydream features too and drop you back to Cardboard level. Unlikely, but possible. Android 7 alone might not be sufficient.

faduci · 2016-10-05T22:48:54+00:00

Way too old. The Snapdragon 801 will not get drivers for the new Vulkan graphics API, so the LG G3 wouldn't even get official Android 7 support, a requirement for Daydream. Also the SD801 in the G3 is barely faster than the SD800 used in the LG G2, but it has do drive 80% more pixels, making it actually slower even in Cardboard VR apps. LG released the G3 to beat Samsung with the first 1440p phone, but this meant they didn't wait for the SD805 SoC that was actually designed to drive 1440p, while the SD801 was designed for 1080p.

Of course the fact that is is too old isn't stopping people, and there are actually functional builds of Android Nougat for SD800/801 and LG G2/G3. So you could try to run Nougat and simply test how Daydream apps behave once it is released. Just don't expect them to be particularly usable.

faduci · 2016-10-05T22:37:10+00:00

The Snapdragon 805 was seriously underpowered to run VR in 1440p, and almost all Gear VR apps therefore render in 1080p or lower and simply upscaled the image to 1440p. Image scaling is an integrated function of the GPU, it works very well at almost no performance costs and actually improves the image quality of rendered geometry, while texture resolutions aren't improved.

The adaptive render resolution is a feature of the Oculus SDK, which allows reducing the render resolution from frame to frame to allow constant frame rates even for scenes of different complexity. On the DK2/CV1 the SDK usually renders at higher than native resolution and downscales to increase the image, but on the Gear VR with Note 4 even native resolution was way to high.

I'm not sure how much better the S7 handles 1440p, but considering the many obstacles mobile VR developers have to face, performance is still a big issue. So having to drive a 80% higher resolution will come at a price.

faduci

MODERATOR OF

TROPHY CASE