Few questions/issues. about gvr-ios-sdk HOT 36 CLOSED

Thanks for the feedback. We're going to add an official API so that you can remove the info UIButton. It's going to be available in our next release.

from gvr-ios-sdk.

We're developing a 360 degree video app. We use the cardboard SDK for Unity and have had great success with it and now we're trying a native iOS implementation. I initially got the impression from VRView that it was supposed to act like the SDK to get most of the VR work done for us and then we can build the rest of the app around it. The (i) is in the way of one of our buttons that comes up with on-screen playback controls. Additionally we don't need our users to go to the google VRView page, we provide our own instructions and help information.

I guess I'm a little confused why VRView for the web, and Cardboard SDK for unity provide such customization and unrestricted access (source code, etc) where as this VRView for iOS seems locked down and branded and not intended to be used by developers? Am I missing the intention of VRView? Perhaps I should skip over VRView and just use the Cardboard SDK for iOS by itself and develop my own video implementation? Just feels like reinventing the wheel..

from gvr-ios-sdk.

@nathanmartz
We're developing a VR video application using the Cardboard iOS SDK at the moment and in our case we would like to let the user choose to enable VR mode before launching the video player. A good example is this screenshot from the NYT VR app:

All the other points in this thread applies to our indended use case as well so I hope it's something that might make the next release.

from gvr-ios-sdk.

The problem with using Unity to embed a 360 video player is that it inflates the size of the binary. Adding Unity to an iOS project adds an additional 20 MB of bloat to the binary. We need a thinner solution.

The mix of closed and open source is fine as long as adequate customization is available. The ability to control video playback and implement your own video playback UI is there, but then you can't even customize the fullscreen or VR mode switching.

In my opinion there is two main usage cases for a closed source lib like VRView:

1. For testing Google Cardboard across various devices with various videos. Then I'd ask why aren't playback controls implemented for us?
2. To give developers an easy start point for developing their own 360 video player implementations. Then I'd ask why its restricted for fullscreen, VR, and the (i) button.

It seems to miss the mark on either target. Anyway, I've began rolling our own 360 player implementation on top of CardboardSDK and it's working quite well. I'd normally close the issue at this point but I'll leave it up to you to close in case you want to keep it around to keep the discussion open.

from gvr-ios-sdk.

The exact swift version to remove only info button:

                    for v: UIView in self.imageVRView.subviews {
                        if (v is UIButton) {
                            let className = String(v.dynamicType)
                            if className == "QTMButton" {
                                v.removeFromSuperview()
                            }
                        }
                    }

The only issue left is to remove it from fullScreen mode...

from gvr-ios-sdk.

@oliverwh you saved my day. Thank you, it works!

from gvr-ios-sdk.

No problem. We really do listen :)

from gvr-ios-sdk.

Hi. The (i) is intentional and designed to let users and other developers
understand the feature. It links to a Google help center article. We do not
currently allow developers to disable it. Can you give more context on why
you want to disable it?

We do not currently expose these functions. More context on your use case
would help inform future API decisions.

We don't currently allow a custom transition screen but we have considered
it. The screen goes away when you turn the phone landscape or press back.

On Tue, Apr 12, 2016, 9:18 AM Andrew Mac [email protected] wrote:

1. Is the (i) icon in the bottom left hand corner intentional? Is there a
   way to get rid of it? Here's a screenshot to show what I'm talking about:
   http://i.imgur.com/vWBLMkw.jpg

2. Are there any functions/flags that I can set to switch to
   fullscreen/non-fullscreen and turn VR on/off other than the buttons
   included in the player which can be enabled/disabled? In other words, how
   can I implement a custom fullscreen and VR button? I haven't been able to
   find them but maybe I'm missing something?

3. Is there anyway to disable or implement a custom Insert Into Viewer
   screen? Also, what is the intended functionality to hide said screen when a
   user is presented with it? I've found sometimes it never goes away,
   sometimes it goes away rather quickly. Motion of the device seems to
   possibly impact it? Is it on a timer?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9

from gvr-ios-sdk.

Thanks for the context. If you are using Unity already, have you considered using that for iOS? It actually sits on top of the native iOS SDK.

VR View is designed to make it really easy for people to add 360 content to traditional sites and apps. We've tried to emphasize simplicity over total customizability. I'll discuss this use case with the team.

Regarding VR View on the web, it's open source because there's not really any alternative on the web. It's also better to host it yourself. The CardboardSDK for Unity is actually a mix of open and closed source, with much of the actual guts in the closed source native SDK layer.

from gvr-ios-sdk.

Ugh. Why does Android's CardboardView have setAlignmentMarkerEnabled, and setSettingsButtonEnabled, etc and iOS GCSCardboardView doesn't? The APIs don't even match between iOS and Android releases of the CardboardSDK. So what I can do on Android I can't do on iOS? That completely shoots me in the foot for trying to achieve visual parity between Android and iOS versions of my app.

This has been an extremely poor experience thus far :(

from gvr-ios-sdk.

We intentionally wanted to launch with a streamlined API for iOS and see which APIs people actually used. The Java SDK has become sprawling over time, which people also complain about. We plan to better align these APIs in our next release, and feedback like this is valuable.

Regarding disabling the alignment marker, settings button, etc. are you replacing them with your own equivalents or are you just removing them?

from gvr-ios-sdk.

Thanks for the reply, and sorry for my increasingly negative tone, I'm just getting frustrated. We use the alignment marker supplied by the SDK but disable the settings button and back button. We present the user with a choice of magic window, cardboard, etc before launching the video so having those controls present during playback is unnecessary for us.

So, on our unity and android players there is no back button or settings button visible. I'm a little stuck at the moment since I can't disable those on iOS. Do you have any kind of ballpark timeline for when a new iOS SDK could be released? If not I may have to look into using something like this: https://github.com/rsanchezsaez/CardboardSDK-iOS instead, though I'd really rather stick with the official up to date SDK.

from gvr-ios-sdk.

Frustration is understandable, and we genuinely appreciate your feedback. I can't give exact timings on the next SDK update but before the end of May is a reasonable ballpark.

Regarding the back button and the settings gear, we discourage devs from hiding them unless they are replacing them with equivalent functionality.

With the back button, we find that many users don't understand how to "get out of VR" if there isn't an on-screen affordance, especially in android where you may have to swipe down from the top to get a home or back button.

The settings button is the only way viewers can switch viewers or pair the right one (which they may not have done). Our help center articles refer to this affordance and it can give users a bad experience if they have the wrong viewer and can't change it.

Lastly, I do not recommend you use the non-official iOS SDK. Other developers have reported issues with memory leaks and we can't guarantee compatibility, usable features, etc.

from gvr-ios-sdk.

We have our own back button as part of the playback UI to exit the video. We don't currently allow transitioning from stereo to mono mid-video. Its expected instead that the choice was made and the device configuration loaded right before the video was launched. We've found this is a better experience than starting the video having made an assumption of either stereo or mono. We want the user to be settled and comfortable at the beginning of the video so they can enjoy the whole thing, not promote making adjustments mid-video.

Ideally the API would expose just about everything. I can't recall a time I've complained about an SDK having too many options, only too few. That is of course as long as they come with good default values so I don't have to touch them until I want to. The android and unity SDKs do a fine job of this in my opinion.

from gvr-ios-sdk.

Thanks for all of the feedback. When building VR View, our goal was to make it easy for traditional app developers to embed these elements. For developers who want full control, there is the CardboardView, in which you can do anything you want (assuming you write the GL). What could we do to make that approach easier for the folks on this thread?

from gvr-ios-sdk.

@nathanmartz can you add any functions/flags that I can set to switch to fullscreen/non-fullscreen and turn VR on/off other than the buttons included in the player which can be enabled/disabled (in GCSWidgetView)? It's make easier to develop

from gvr-ios-sdk.

@nathanmartz what @never58 said, just add functions and flags so none of your UI/design decisions are forced on us. Divider line? Optional. (i) Icon? Optional. Switching to/from stereo/mono? Optional. Just make everything optional and no one can complain 😄

from gvr-ios-sdk.

@nathanmartz any changes?

from gvr-ios-sdk.

We are unlikely to allow developers to disable essential UI elements like the divider or the gear. We are discussing allowing programatic control of the transitions between modes, but don't have any hard dates yet.

from gvr-ios-sdk.

Apologies if this is not the right place for feature requests. However, I would like to share some feedback for this particular SDK.

I also do not feel that adding Unity to my project would bring anything of significance, except for a bigger executable size and code complexity. Is it feasible to include into the SDK for iOS the required support for native Metal apps? I would like to bring the much touted power of Metal into my VR-enabled project with no extra dependencies (save for GVRSDK itself).

from gvr-ios-sdk.

@andr3wmac @never58, v 0.9.0 adds an API to change the display mode.
You still can't disable divider line or tip icon though.

@Izhido please file a separate request.

from gvr-ios-sdk.

@dav-cz can you explain me how install v 0.9.0, pod update do nothing.

from gvr-ios-sdk.

@nathanmartz you say
"We are unlikely to allow developers to disable essential UI elements like the divider or the gear. We are discussing allowing programatic control of the transitions between modes, but don't have any hard dates yet."

After spending considerable time trying to hide the back and settings buttons I find this thread, which answers a lot for me.

I'm using Unity to port to iOS and Android. I see you disallow the disabling of essential UI elements which I understand, however I previously had a cardboard icon on a canvas bottom right which when tapped toggled between VREnabled=true / VREnabled = false but now I find that this button does not respond to input at all and presume it is the GoogleVR canvas layer stopping it?

I'm happy to leave all the essential ui controls in in place but cant see why adding another canvas with this button on should not work?

Can you advise please? For reference if you look at the Jaunt app you will see the button to which I am trying to replicate.

from gvr-ios-sdk.

@nathanmartz We're trying to use the SDK for a fullscreen splash page, and the info icon is cluttering the view. It should be the developer's responsibility to inform the user how to use VR apps. There are too many types of SDK implementations to justify the info icon. I'm fine with it being on by default, but the developer should be able to control this functionality.

from gvr-ios-sdk.

Hi, Evan. If you don't want the info icon, you can build your own pano
viewer using the lower level GVRView APIs.

On Sun, Aug 21, 2016, 7:54 PM Evan Bovie [email protected] wrote:

@nathanmartz https://github.com/nathanmartz We're trying to use the SDK
for a fullscreen splash page, and the info icon is cluttering the view. It
should be the developer's responsibility to inform the user how to use VR
apps. There are too many types of SDK implementations to justify the info
icon. I'm fine with it being on by default, but the developer should be
able to control this functionality.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANamfgZC18CYZmht5P0oSkn50fFE2qtZks5qiQ9IgaJpZM4IFj5Y
.

from gvr-ios-sdk.

@nathanmartz can you advise on my issue please? Thanks

from gvr-ios-sdk.

@nathanmartz What do you mean, GVRView APIs ? I can't find such a thing in the iOS SDK. Can you please point me to it?

from gvr-ios-sdk.

@lzhido, I meant to say you can use the GVRCardboardView (plus your own OpenGL) to implement your own 360 stuff.

pinghat@, please don't fork threads. Feel free to open a new thread with your issue.

from gvr-ios-sdk.

you can hide the info button. I have done this in one of my app. even you can call your own button action on info button ;)

from gvr-ios-sdk.

Starting to work on the iOS side of things, coming from now extensively working with the android sdk and wanted to weigh in. Having replaced VrWidgetView in the Android sdk with my own copy, the SDK is super powerful for 360 photos and video, but limited in what it exposes to the client.

By no fault of the GVR team, Unity is pretty bad to work with and its native 2D UI controls are quite slow and unresponsive (scroll delay of > 60ms even on S7, I think because of raycasting), so doing a mixed 2D/VR app with Unity is fine if you can accept that delay.

The native sdks are really close to being great. Echoing a couple issues mentioned in the root of this thread. As an app developer, I don't want Google linking to a Google web page from within my app or flashing a screen in the user's face every time when VR mode is triggered. Imagine if in every Android app using the Android sdk, there was a mandatory information button floating above your app that linked to an About Android page. Or if every time you used an app, the tutorial would pop up. Both are less than ideal user experiences.

People tend to build apps with a very specific visual style in mind so to have a mandatory and conspicuous ( i ) over every instance of the widget or have that transition screen pop up every time you enter vr mode is a non-starter, making the sdk much less useful (have to write pano viewer from scratch, a significant undertaking).

The ideal sdk would have the widget with no buttons enabled, and then as the consumer of the sdk, I add buttons on my app that on click, I call a function on the widget to change modes. In regards to "traditional app developers", I think this is something they're fully capable of.

Thanks for the SDK. It really is so close to primetime. Just a little more flexibility would be appreciated. I look forward to the next release.

from gvr-ios-sdk.

Agreed with @ryango - presumably the GVRVideoView and GVRPanoramaView have been built by google with best practices in mind and optimised already. Building a custom OpenGL implementation purely to hide the ( i ) icon is a very awkward way of going about things.

It would make it easier to build applications that included these 'simplest' uses of Cardboard, if this small amount of flexibility was added to those 'simple' use cases. On iOS Apple is making a push for Swift which is easier for new and old developers to learn - requiring OpenGL knowledge to implement simple cardboard uses will just push some developers away.

from gvr-ios-sdk.

Faced the same issue, the interesting thing, that Google Android SDK has such feature of hiding "info" button.

from gvr-ios-sdk.

you can iterate through all subviews and remove any UIButton

        for (UIView *v in self.videoView.subviews) {
            if ([v isKindOfClass:[UIButton class]]) {
                [v removeFromSuperview];
            }
        }

from gvr-ios-sdk.

GVRVideoView *videoView = [[GVRVideoView alloc] initWithFrame:CGRectMake(0, 0, [[UIScreen mainScreen] bounds].size.width, [[UIScreen mainScreen] bounds].size.height)];

for (UIView *view in videoView.subviews) {
if ([view isKindOfClass:[UIButton class]] ) {
if ([NSStringFromClass([view class]) isEqualToString:@"QTMButton"] ) {
[view removeFromSuperview];
}
}
}

from gvr-ios-sdk.

shout out to @nathanmartz for bringing our requests into the sdk with 1.10.0!

from gvr-ios-sdk.

hola quería hacer una pregunta sobre la Realidad Virtual.
como puedo incluir imagenes tipo (.obj) en la realidad Virtual, estoy trabajando un proyecto de curso y necesito implementar un objeto (Un cuerpo Humano) y visualizar en VR pero no encuentro la manera !. no se si existe alguna api o desde ahi trabajare (Soy Nuevo), entorno de trabajo: android Studio (java
)

from gvr-ios-sdk.