2xMSAA As per: Not Found | Oculus this is a must have. No user let alone Oculus submission review will allow a game through without it. I know we have the workaround source code hack that works for exynos chipset devices - however this breaks the app on Snapdragon devices - and this should be inbuilt to the engine as an option
Difficult to test but I assume not working (and also MUST HAVE):
Distribution build: this did not work in 4.7.4 and when I test in 4.8 and run the app via a shortcut maker (since the app icon is not visible in the launcher) the app crashes. I assume it’s more than just the OSIG file being obfuscated since then we would see the normal security exception message.
We should be able to trigger the Confirmation Universal Menu which is different from the long press Universal Menu. I have not seen this documented anywhere how to do this.
Almost Must Have:
Oculus Audio SDK documentation for the GearVR: We sorely need spatialized audio - I see there is a new Oculus Audio SDK plugin in 4.8 however I’m unsure how to use it exactly and unsure if it even works for the GearVR?!? I know there is a way to hack a FMOD plugin with the Oculus audio plugin within it into the engine (and even tried it) - however it seems to eat alot of CPU power in my project causing frame rate drops every time a sound is played The default UE4 engine audio does not sound spatialized to me on my GearVR - especially when I compare it to the FMOD plugin I tried (which did a pretty good job sound wise just a pity about the performance I just mentioned) …
Additional nice-to-have feature still missing:
Blueprints for the touchpad: There are some controls that can be worked out but good luck for example figuring out a swipe up or swipe down - Would be great if they were all exposed to an easy to use blueprint
Ideally the engine should do this for us if gearvr and volume buttons pressed.
General observation comparison between 4.7.4 & 4.8:
7. Much lower performance in 4.8 - by about 5 - 10FPS. I have set the same GearVR.Settings in the engine.ini with gpu=3 that worked great in 4.7.4 but it almost seems like it’s not working in 4.8 and that’s without any 2xMSAA in 4.8!!
I hate to end on a negative note of feedback since I really like this engine but if you really want more people to use the Engine you need to at least keep up with Unity when it comes to the latest new VR technologies. Unity guides exist on oculus itself: Not Found | Oculus and has none of the blocking issues listed above - which is why there are already Unity apps in the Oculus store and no UE4 apps. There are many of us that would love to submit something to the Oculus store already month(s) ago like our Unity counterparts …
Another must have feature is the Samsung Gamepad EI-GP20 support! Im many countries the Gear VR is sold with this as a bundle…
In the meantime I have created my own hacky solutions for
Touchpad gesture recognition as ActorComponent (all gestures reported as delegates to the Blueprint)
Volume changes going trough jni to FAndroidMisc and reporting to an ActorComponent that controls an Actor with UMG Widget, holding the original Oculus Images for the Volume Widget composition; still might be not the best performing solution atm - where is UMG Atlas?? =)
Back Button as ActorComponent (easy one)
BackButton Longpress Progress as individual ActorComponent (since I use it in an child actor, I need an extra component for this)
EI-GP20 recognition via Android InputManager.InputDeviceListener going trough jni and FAndroidMisc to set a bool, that is used in AndroidIputInterface.cpp to switch the behavior for the right thumb stick and the EI-GP20 analog DPAD input
Streaming Live Video from Android Java to a MediaTexture (atm with some crazy hacking and a lot of uncommenting in the Media Related Engine code, breaking file Video Playback, but works g)
You can easily use some #if PLATFORM_ANDROID == 1 compiler directives to emulate this stuff for editor testing, so no Blueprints need to be changed and you can even test gestures with the cursor keys and so on.
I do not know why you do not just implement this. It took like 2-3 weeks for me (weeks that I lost for the rest of my master thesis, but nevermind). To make it cleaner than I have done it, maybe put it in another Gear VR Input Plugin that compiles for Win Mac Linux and Android, this way Blueprint Components can be used and the Editor is a working testing tool for mocked up input.
Too bad I can not put my solutions as sourcecode into the public right now, but I can and will after my master thesis is over (middle of October), if you guys have no solutions in the Engine until then. But with the tips above, everybody might be able to do it. Just make good use of jni and use FAndroidMisc as a relay station and you can accomplish everything you need, even with full editor Blueprint capabilities if you use the PLATFROM_ANDROID as described above in the ActorCompnents or wherever you need to mock GearVR input with e.g. cursor or +/- keys.
BUT regarding the Distribution Build and MSAA issues - Epic please deliver cry
From the commit history in github I see that the devs that worked on GearVR, now work mostly on SteamVR with a focus. I understand that from a business 5% revenue point of view. But please, you promised us Gear VR guys to get us production ready at least. We will have sales too as soon as the Gear VR consumer edition hits the market - most likely this winter holidays.
As little goodie that I can release right now, here is the Oculus Progress Material as implemented in the SDK, just use the textures in ovr_mobile_sdk_0.5.1\VRLib\res\raw gaze_cursor_timer.tga and color_ramp_timer.tga. Hope it maybe helps someone.
Absolutely agree. MSAA and Oculus Audio SDK documentation for the GearVR in particular are really important to everybody developing for GearVR. Any timeline for these?
MarcelBlanck thanks for your feedback - you are right about the volume UI so I edited my first post moving that bullet point into ‘nice to have’.
I’m still not sure about your other points though:
The back button to the confirmation global menu is still something I have not seen in UE4! I am not talking about the long back button press to the menu with the passthrough camera - but rather the text saying -> are you sure you want to return to Oculus home: Yes / No -> if the user selects No the game resumes
Would love to see your blueprint for swipe up, down, forward, back - have not been able to work that out with the current engine and BPs (but I assume you modified the source code to get that?)
This loading graphic you provided is nice but no idea where we could use it since UE4 still does not support a loading screen on Android
As much as we all love hacky solutions, something that works in the Engine, at least being able to get something to production would be great! Without that you can really label it as being ‘supported’ can you?
I’m pretty much at the point where I’m ready to start porting our projects over to Unity since that seems to be the only viable way to get content on the market for GearVR. I was confident that the 4.8 release would at least have enough of the defect backlog addressed to move forward but that clearly wasn’t the case. Does anyone know of a good 4.8 fork to use for GearVR projects?
I’ve been wondering if some sort of rift, excuse the pun, has started to develop between Oculus and Epic. At least with respect to GearVR. Seemed like there was lots of love a few months back, but things have slowed down and gone so quiet that it leads me to think that Epic are now focussing their energies elsewhere in the VR space. Probably just paranoia on my part - at least I hope it is.
/rant on
That said, and whatever the reason for the recent silence and lack of progress with respect GearVR, I think Epic staff need to throw us GearVR developers a bone. A lot of us here have invested a huge amount of time in our GearVR and UE4 projects and it feels like we are just being left hanging, even despite multiple posts, supporting replies and thread bumps from interested parties. My own post included. My post has gone unanswered for over a month now and the issues described within it have damaged my ability to take advantage of the post Jam marketing buzz by distributing a working copy of my demo. They have also stopped/restricted my ability to demo my app to potential investors who have show interest in moving my project forward via seed funding. I can’t run my Mini-Museum on Lollipop because my Note 4 continually force updates itself to Lollipop. JJ said the AA issue was a top priority for 4.8 and it seems we still don’t have a solution.
If GearVR is no longer a priority then that is fair enough, just let us know so that we can move forward with our projects and make the correct business decisions. There’s a limited window of opportunity for developers to position themselves to benefit from first mover advantage within the mobile VR space. Personally I think opportunities like the one about to present itself, with mass availability of VR devices just around the corner, only come around about once every 20 years or so. I desperately do not want to have to start learning another engine in order to take advantage of this opportunity. I think the biggest market in VR is going to be mobile in the short term and so I feel it has to be a big part of my release strategy. I’ve been reluctant to do much in-engine development since the Jam because it’s not clear whether I’m going to have to jump ship. This is not good because I’ve got so much to do - my Jam submission represents about 5% of my vision for my V1 release app. A lot of us who started development of GearVR projects chose Epic because it seemed like UE4 was the best foundation for us to move forward on, I really still hope it is.
/rant off
I should say that I still love you guys for everything else you are doing. The engine in general is just getting better and better all the time and I’ll be glad of support for Sony Morpheus and the HTC Vive once I finally get hold of my dev kits. It’d just be great if you could give us some rough ETA’s for fixes on these critical issues that continue to hamstring us UE4 mobile developers. If the root of these unresolved issues lies with Oculus then let us know! We’ll all go and hound them instead!
The situation has kind of knocked the wind out of my sails regarding UE4 to be honest. While I admire and respect what Epic is doing overall, it seems like I have no choice but to either migrate my project to another engine or accept not releasing my app this year. In hindsight I now recognize that choosing UE4 for my Mobile VR Jam entry was kind of a foolish decision as the technical hurdles were too much for me. Now I’m feeling that way about my release project. And at this point, considering that I went all in with UE4 this last year, migrating everything into Unity means pushing my release into next spring, at the least. However at least I will feel some confidence and hope that it actually will be released.
It’s actually a colossal bummer as I really, really love Epic and UE4. But all I keep hearing in my mind is, “the right tool for the right job.” It just feels like UE4 does not really work with Android or mobile VR and that Epic just doesn’t want to let the cat out of the bag. Or maybe there actually is some bad blood between Epic and Oculus (it sure feels that way from the outside looking in), or a partnership happening with HTC/Steam/Sony behind the scenes. Plus the way that Epic handled the community who chose to go forward and submit their entries to the Mobile VR Jam, both towards the end of the contest and afterwards, was just poor form. And surprising, as I genuinely felt like they had our backs for a time there. But in the harsh light of reality, UE4 does not work with nor support the GearVR in any meaningful interpretation of “work with” or support, and hasn’t for many, many months.
And don’t even mention Google Cardboard… I sometimes feel like Epic sees all of these “Mobile VR” topics and just rolls their eyes, hoping to wait it out so that maybe this will all blow over and we will all get the hint and just go away. That’s how it feels to me, anyway.
They were there for us at the Jam but it felt like it was a small team working on the side while the rest of the company was busy with GDC. Honestly in terms of VR’s direction I completely agree with . With the rate in which technology is evolving the computers required to run all these new headsets is going to be affordable for the masses, however computers have been around for about 53 years now and to this day most people still struggle to effectively use them. It’s my opinion that the VR mainstream PERSONAL USE boom is going to start on the mobile platform, and I want a head start on that vision.
Also well said and exactly how I feel and I guess everyone who was hopeful to release something for GearVR using UE4
Surprised Epic did not at least say something about issue #2: Distribution build not working - or maybe they know without issue #1 (MSAA) no one will want to try distribution anyway (did anyone else try to confirm that?) Time is gradually running out here for those of us that wanted to get in early …
Thanks for underlining these issues again, aussieburger and everyone else. We feel exactly the same. We’re a two man team trying to get our vr jam entry into the store, but with the current issues (and lack of communication) we’re also seriously considering migrating to Unity. Having more than 8 years of Unreal Engine experience, that’s really a step I’d rather not take. It’s a tough call to make. If Epic wants to have UE4 titles in the store by the time the Gear will do its mass consumer launch, they’ll really have to step up their game, time is running out.
I attended Unite Europe last week and there was a talk dedicated to Gear VR development, how-to’s, best practices and Unity’s efforts to support it. The speaker, Unity’s Carl Calleweart, was extremely enthusiastic about the Gear. He made it very clear that Unity is really committing seriously to supporting the Gear VR, now and in the future.
Speaking of issues, another “almost must have” is Mobile HDR. As discussed here. I’d even say it’s must have. Not because of the effects per se, but more with how post processing can significantly help with optimization. For example in the form of masking distance culling, with fog, significantly reducing the amount of drawcalls.
It would be great if Epic could comment on all these matters and give us some peace of mind.
I just sent a PM to , JJ and Dieter directing them to this thread as I’m guessing it may have slipped under their radar. Fingers crossed we get some news on progress soon…
I still haven’t downloaded Unity 5 and am hoping beyond hope that I don’t have to.
The default UE4 engine audio does not sound spatialized to me on my GearVR - especially when I compare it to the FMOD plugin I tried (which did a pretty good job sound wise just a pity about the performance I just mentioned) …
