Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developers.google.com/vr/distribute/daydream/design-requirements below:

Daydream App Quality Requirements - Design | Google VR

Objects must be placed far enough away from the user that they can visually converge on an object and not see a double image. If the object in question is required text, it must also be large enough to be legible on a Daydream Ready phone.

We recommend you start by placing objects more than 0.5m away from the user, and making sure all font sizes take up at least 1.5 degrees of the user’s visual field of view.

Your app must maintain head-tracking, and all virtual objects must be locked relative to the world, not to the user’s head. Large head-locked objects give the impression that the user has a large screen attached to their head, as opposed to feeling like they are in a virtual environment.

Your app cannot have sudden camera oscillations that cause the horizon line to move unexpectedly, and the ground the user is standing on can't be significantly slanted. This can be extremely disorienting and nauseating for users.

Apps should not take control of the camera (which is also the user) and move it (them) unexpectedly. Users should feel in control of their movements by clicking or otherwise showing clear intent before the camera moves. For example, the user could aim at and select teleportation targets, or use the touchpad to move the camera.

This criterion does not mean that the user must always be in direct control of the camera’s motion, but rather they must initiate the moments when they are not in control. For instance, the user must click to begin riding a rollercoaster, at which point it’s okay for the coaster track to take control of the user’s movement away from the user.

When users long-press the Daydream button on the Daydream controller to recenter the app, the system automatically performs a recenter, that is, the controller and headset's current pose will be redefined as "forward".

Your app must not interfere with this process or apply any offsets to the cursor position. After recentering is complete, the following must be true:

• The cursor is shown directly in front of the user, without any lateral offset (not off to a side or behind the user). If you are rendering the cursor in the wrong position after a recenter, it is because you are not handling the cursor's position properly.
• The headset is now facing the application's "preferred forward" direction. In a game where the player is sitting in an airplane cockpit, for instance, the "preferred forward" is facing towards the nose of the plane. If your app is a "360 app" with no preferred forward direction, the direction the user is facing should remain the same: your app must compensate for the recentering by rotating the scene/camera to ensure that the same object that was in front of the user before the recenter remains in front of the user after the recenter. When performing this compensation, be careful not to violate the item above (the cursor must be directly in front of the user after the recenter).

If the app has central UI elements that the user should always be facing, such as an in-app menu system, then upon recenter, the app’s UI must be properly re- aligned with the headset and controller. This means that after the recenter the camera should be facing the central UI elements and the controller's cursor should be recentered with the camera.

If the app involves your user moving around a 360° environment with no strong notion of which way is "forward", then upon recenter your app must:

1. Preserve the user’s orientation with respect to the environment at the time of the recenter.
2. Properly re-align any central UI elements with the user's current forward direction.
3. Re-align the controller to the camera.

This means that the object that was in front of the user before the recenter is the same object that is in front of the user after the recenter, and any central UI elements which weren't already in front of the player before recenter are now in front of the player after recenter.

When the user recenters by long-pressing the Daydream button, the controller and home UI should be oriented to respect the system-wide global north.

This means that, after a recenter, the "forward" direction in your app should coincide with the system-wide global forward direction, which is where the Daydream app's menu is rendered. To test if this is the case, recenter and face your app's "forward" direction, then single-click the Daydream button to return to Daydream. You should see the Daydream launcher menu directly in front of you. If it's off to the side or behind you, it's because your "forward" direction is not correctly matching the system's global forward direction.

Apps should use the default neck model that the SDK provides. If you are creating an Unreal or Unity application, this will be done automatically.

The neck model must be present when appropriate, but there are some instances where you will want to disable the neck model, such as when viewing spherical videos. There are also instances where you may want to override the existing neck model to modify it, for instance if you have decided to render a visible avatar.

Rules:

• 3DoF apps must use a neck model.
  • 3DoF apps should use the default SDK neck model.
  • 3DoF apps may override the neck model when necessary for proper rendering (for example, when viewing spherical videos).
• 6DoF apps must use the head pose provided by the system.

When in VR, your app should never display any 2D images. These include permissions dialog boxes, splash screens, hardware volume control sliders, and dialog boxes controlled by other software on the device.

For example, the below images contains an unexpected 2D progress bar that inteferes with stereoscopic rendering:

While Daydream apps are expected to be entirely standalone and self-contained experiences, there are a few cases where you may have to transition users from VR to your 2D monoscopic app, and then back again.

This is meant to be a very rare occurrence, and only for a small set of circumstances. One reason might be needing to prompt the user to accept a dangerous permission. Currently, dangerous permissions can only be accepted using 2D monoscopic dialog boxes. This won’t be addressed with in-VR dialog boxes until the next version of Android. Another reason might be displaying a webview, for a login process with a third party that requires the web.

When making the transition to 2D, your app must do the following:

• Prompt the user to remove their phone.
• Detect the orientation change to portrait to switch over to 2D.
• Return the user to nearly the same state in VR that they were in before they removed their phone.

If an app requires an Android permission, the permission must follow UX-D9 to accept the permission. See this page on the Video360 sample for more information on accepting permissions.

When the app is launched from VR (such as from Daydream home) the app must start in VR. This happens automatically for apps using Unity or Unreal.

• To request dangerous permissions, use the PermissionsDemo scene provided in the SDK and the included permissions controller scripts as a starting point for your own app.

• If your app makes use of non-VR 2D flows, and the application is already in VR, the application must use the DaydreamApi.exitFromVR() API to exit VR and enter the application's 2D activity.
• When the application's 2D activity is completed, the application must return to VR by using the DaydreamAPI.launchInVR() API.

Apps must use the Daydream controller as a laser pointer when interacting with traditional UI controls, such as menu screens, pause screens, and any other situation where you have a 2D interface panel floating in space in front of the user for them to click on. This criterion does not affect the gameplay of your application, which can involve aspects of head gaze.

When interacting with UI elements, several specific behaviors of the controller must be consistent across applications:

• Use an arm model.
• Lower the laser ray an additional 15°
• (Recommended) Render the controller in the scene
• (Recommended) Display a laser ray.

Note that an arm model is designed for general pointing (not throwing or hitting) and bringing the controller closer to view tooltips placed on it.

This is important for consistency between the OS and applications, and for the user to be able to maintain muscle memory without having to compensate for variations when they move between applications.

While not a requirement, we recommend that you leverage our official 3D model of the controller when users are interacting with UI elements in your application. Advantages of rendering the controller in scene include:

• Greater sense of presence by bringing an element of the real world into VR.
• Provides an opportunity for tooltips/instructions on controller buttons.
• Helps to remind the user what buttons are available.
• Provides visual feedback on button presses.
• Leverages consistency across the platform.

The benefits of the laser are:

• Faster to notice and follow than just a cursor.
• Best way to communicate the angle of the ray and help with the intuitive feel of how the orientation of the controller input affects the ray.
• Realtime feedback.
• After using another interaction mode (driving, flying, rolling), showing the laser is a clear indication that the interaction mode has changed to ray-based UI input.

Daydream has a system-level preference for whether the user is right or left handed. When using an arm model in your application, you must respect this user preference. Additionally, your app should not expose custom UI controls for changing this preference only in the context of your app.

In cases where there are large scrollable sets of items, such as YouTube video search results, we require scrolling by swiping on the touchpad of the Daydream controller.

If the Daydream controller is casting a cursor out into the scene, the cursor must be rendered at the same depth or nearer than the objects it is in front of. Failure to do so will result in depth conflicts for the user or double vision.

The fix is usually as easy as hiding the cursor if not near an interactive object.

The app must not interfere with the functionality of the home and volume buttons on the controller.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4