Epic's low priority on GearVR and VR in general makes me sad

Hi Epic,

I am a big fan of UE4, I had a great time since last spring. I already had the opportunity to teach UE4 to a game design class at university, I created a small UE4 demo project in context of my studies (Vitreous Tank) and now I started my GearVR centered master thesis project.

I wanted to focus on GearVR Development over the year and here comes what saddens me: Gear VR support seems to be really very low priority and it is far from production ready, additionally there is no time frame or transparent communication on further development - some Trello Buzzwords with not committed delivery dates are not enough.

I’d like to point you on a few things that would make it production ready if you would fix or implement them:

  • The rendering support is still rudimentary. It looks very bad, and anti-aliasing seems to have no effect.
  • Some parts look done, but are not. Like there is no way to change screen percentage on the GearVR it always stays 100
  • There is no guide for recommended graphic settings. I have been experimenting a lot, but recommended Android settings look bad in VR and I really found no settings that looked/performed as good as the same scene in another engine I tried.
  • Even with very basic shaders and only a little low poly geometry I cannot hit 60fps - If I missed something, well there is no documentation for UE4 GearVR.
  • The Samsung Gamepad EI-GP20 is not supported (dpad and right thumb stick do not work). I submitted a patch at GitHub, but then the Moga Pro support was broken so I canceled it myself, the Moga Pro really uses LZ and RZ axis to indicate right thumbstick… So maybe just allow RX RY RZ an LX LY LZ and let the Developer decide what to use instead of forcing the Z axis to RX and RY output
  • I ported my 4.7 Preview 8 game to 4.7 and now my builds render both eyes on the left half of the landscape screen. I cannot find the reason, nor a fix - nothing has changed on my side. So having working builds is kind of random or the way something has changed or could cause this is not documented officially.
  • To sum it up: official documentation on GearVR is missing. Community documentation is often outdated or not 100% correct like your oculus Wiki page proves.
  • The AndroidManifest cannot be changed by hand, somehow you think configuring it via Settings is enough. What if I want vr_dual, what if I want other native activities? Of course I could work with a custom engine where I change the templates and some code, but having a custom manifest is pretty much standard, and it will be standard for UE4 Android devs too, they know what they are doing (and there is still UE4 documentation right?), so trust them - still there could be an alternative non-technical artist-dev mode with simple manifest mode or something.
  • Calling intends is not possible via the android jni interface. Again I could include it for my personal engine build, but I expected it to be delivered by you because this is basic.
  • Without intends I can not call the oculsu home activity. So you artist devs are unable to get marketplace ready GearVR apps.
  • Same for volume - no way to adjust Android system volume.
  • A Gear VR Template could provide the volume and back button longpress and the “Back to Oculus Home?” functionality, again with optimal graphic settings.
  • When we are talking graphic settings. In the oculus docs you should basically decide the depth buffer 16bit or 24 bit time warp thread’s multisampling 1x 2x or 4x. The rest are recommended defaults PixelLightCount Low, AntiAliasing Disabled, Shadows off, VSync off, Physics time interval. It should be that easy or at least well documented for UE4 too.
  • Having UI on Android is hard, since UMG is still experimental. UMG Crashes the editor what really is bad for mood and workflow.
  • UMG 3D Widgets on android render with DX UV coordinates and not with GL. So the UMG UI is mirrored.
  • UMG 3D Widgets are lot of pain if you want to control the UI with the gamepad or let’s say with mouse swipes (like the Gear VR touchpad provides). It is not even possible to highlight anything without a mouse, you need to work around with active deactivated states and manually controlled focus. Android devs expect DPAD controls for UI with automatic focus according to widget layout, including jumping in lists and out and scrolling lists. That all is missing in UMG.

I am sure I have forgotten some points and maybe in some cases I am just well informed or too stupid. Maybe some other devs want to share their complaints and experiences too?

Of course some of the issues could be fixed by my own work or by community work, like documentation, Samsung Gamepad or Android intends. But I really believe Epic has to deliver if they want to be a respected VR game engine. VR Projects for GearVR, GearVR2 and CV1 have their roots now. Devs that go to elsewhere for an easier live might never come back (promised, I will).

For my part I worked one year with UE4 and now I have to look for alternatives, because it is impossible to create something for the GearVR jam at the moment. Also I started my Gear VR related master thesis and spend a whole month only to find out UE4 is might be not usable for GearVR in it’s current state. And worse, we do not have a time frame for fixes. In fact there is almost no transparent communication about what is planned on VR. A small Trello Entry “Gear VR optimization” is not enough if you want to start production, only to find out UE4 is still not capable of good quality, painless mobile VR development when your time schedule is over already.

@Epic: Please do not get me wrong. I love UE4. Release 4.7 was awesome, on every other aspect, but VR issues and/or documentation have not been addressed enough maybe.

If I am all wrong with my complaints please just point me the right direction, I would be happy.


Marcel Blanck

P.S. If low performance cost 3d world space UI with DPAD controls is really such a hard problem, maybe you should break the link to Slate. Slate is too complex for the things needed there. The required features and stability might be hard to archive with it. Code reuse is cool, but not at the expense of too many compromises.

P.P.S. I am not a native speaker so please do not hang me for my grammar :wink:

P.P.P.S. I deleted my “now going to another engine statements” since the support came so quick and extensively. Thanks!

I’m with you Marcel. While I’m not developing for mobile, I’ve never really forgotten this twitch stream, where Martin Mittring basically tells us that stereo rendering is not their priority (around 46min they are responding to my question about the new rendering features not working in VR). While I totally understand this from their point of view; VR folks are a much smaller subset of their customer-base. It still bothers me to this day, and that was back in October, and has not yet been fixed. That isn’t even what really bothers me either. It’s the lack of transparency in where these fixes are in their priority list… but I suppose they won’t mention that because it’s generally bad news… very low-priority.

I’m not going to say switch to Unity. You may have to just for time’s sake. I trust Epic will take on these issues as VR becomes bigger and bigger. But as for when, that is certainly up-in-the-air.

I’ll add, it also seems very antithetical to what Tim Sweeney has recently said about “VR being the future.” But that’s just my jealousy talking;) If I didn’t freaking love working with their tools, I’d throw a tantrum and go learn Unity myself. But I’ll be damned, they are too good to put down!

I’ll also add, that they HAVE been paying quite a bit of attention to VR. While not everything works, they have fantastic support for the rift, and do keep adding features. The gearVR support is brand new, so it’s going to have bugs. I WOULD LOVE to see a twitch stream devoted to VR and optimization though. They haven’t really been all that helpful in supporting VR developers with information.


Thanks for the feedback, and sorry you’ve had a rough start with the Gear VR support!

As you mentioned, it is brand new, and aside from our test content, we really haven’t stretched the legs on what the device can do in the engine. With that in mind, it sounds like there’s a few things we can do in order to help things out.

First, we need to get the setup and quick start guide more visible. This doc exists, but the fact that you guys haven’t been able to find it, or didn’t find it useful is a sign we need to improve that. So, we’ll be doing that!

Secondly, it sounds like you’re having trouble getting performance up on the device. With the UE4 mobile renderer, there’s a bit you have to strip out in order to make things performant. So, I’m going to have a quick sample project made that can serve as a plain base, which will run great on the Gear VR. Then you can take that and build upon it, choosing which features you want to turn on in order to add visuals to your scene. Obviously, because it’s a mobile platform, it’s not going to look quite as shiny as on the PC, but it should certainly let you do some interesting things.

As for the Twitch stream, let me see what we can do! Until then though, we did a talk at Oculus Connect about optimization in VR. You can see it here: , and download the slides here:

Hope that helps!

The GearVR template would be amazing, thank you Nick.

Hi Nick,

Thanks for speaking up. I just listened to your interview on" voices of vr"! That was awesome! I also had a look at your talk at Oculus Connect, and yes, that information helps a lot! But it would be nice to have some starting content, as you mentioned… and more in the docs.

“First, we need to get the setup and quick start guide more visible. This doc exists, but the fact that you guys haven’t been able to find it, or didn’t find it useful is a sign we need to improve that. So, we’ll be doing that!”

Are you saying there is a gearVR quickstart guide somewhere? Or are you referring to the Oculus Rift guide that’s been around for a while? Personally, I’m not having trouble getting performance going. For me, it’s more about lack of communication on issues that remain a problem. I’ve really heard nothing since October-ish about getting rendering features running in stereo, like subsurfaceProfile, LPV, distanceFieldShadowing, and decals.

I’m sure none of those are trivial. Well, I’m not sure, Martin seemed to think subsurfaceProfile in stereo could be trivial, but who knows. I just wish for as much information on these issues as I can get, and over the last 5 months, I haven’t seen much.

Thanks again for your amazing work on getting Unreal Engine where it is for VR!


I have to say I feel the same. I love UE4 and I am very thankful for the various options that have been made available for us small-team indie devs, but the lack of transparency regarding VR support and Epic’s seemingly casual stance towards it make me I can’t help but wonder if I’m not making the wrong choice; but I don’t want to switch!

Yup! There’s a specific Gear VR quickstart guide, which I’ve got a few emails out to track down why it hasn’t made it to the docs yet. There was a lot of shifting of the deployment at the end of 4.7, so it underwent a lot of revision in the last few weeks, but I’ll make sure it gets up ASAP.

Let’s fix that then! Next week is super-busy for us, because of GDC, but the following week, I’ll personally go through and update the list of known rendering features that are currently broken in stereo (e.g. LPV, certain particle emitters, DFS, etc), and make that list public for you guys on the trello, and tie them to Jira tasks in our bug list, so you guys can stay up to date.

Regarding the priority of some of those, I don’t want to appear as if we’re casually disregarding those features. We don’t have a very large team, and in the past few months, there’s been a lot of exciting things happening in VR, which we can talk about soon. Up to this point, the priority has been getting coverage on platforms, and trying to stay ahead of the game on that. We’ve tackled some high-value targets that have been often requested (Gear VR, Leap Motion, and a few others we’ll talk about soon), but with each of those, one of our primary considerations was efficient use of resources to get maximum benefit.

The reason we haven’t put a lot of focus on some of the other rendering features working is because in many cases, but not all, in addition to getting them functionally working, we need to adapt them to VR in a very efficient manner. For features that take a lot of rendering time, those are lower value targets to us, because when we’re going for 75 and 90+ Hz on PC, and 60 on mobile, it’s an exceedingly large chunk of the frame budget. For example, in Showdown, we didn’t use dynamic shadows at all, because the frame budget wasn’t there. The distance field shadows are great, but they’re also not super-cheap in terms of rendering. That’s not to say we’re not going to get them working, but when the choice is between that, or broader platform support, our priority thus far has been towards platform support.

So, all that said, I hope that at least shines some light on why we have the goals that we do, but we’ll work on getting more transparent about the status of the rendering features that we do. Our approach to VR is anything but casual, as you’ll see at GDC this year, but I can certainly appreciate how our lack of updates can make it appear so! Thanks for the feedback, and let me make it better for you!

Everything Nick said, plus:

MSAA is fairly easy to add with a simple patch if you’re building from source (which currently, you are, but that’s another topic). I’ll get that simple workaround out to you ASAP, and we’ll work to get a proper fix into mainline soon. There is a slight perf hit, but the visual improvement is almost always worth it.

Screenpercentage is tricky on GearVR. Ideally you just hit your perf targets on the 1024x1024 default eye resolutions. Rendering with higher Screenpercentages is just going to cause performance issues, and rendering with lower screenpercentages is just going to look bad (and also still likely cause perf issues). So Screenpercentage is not something that should be relied on for GearVR at this time.

Turning all post and mobile HDR off is the best place to start. We’re already talking internally about how to make settings that work well with mobile VR more obvious, and enhancing some post process effects to possibly be more mobile/mobile VR friendly.

We’ve hit 60 with a simplified version of StrategyGame, so it should be possible. In that case, turning off all post, HDR, and removing most of the translucent environment effects was what it took. At that point we were left with some relatively high poly lightmapped geometry that looked quite nice on the GearVR while maintaining 60. We’ll work on a best practices doc.

Right, I still have that patch in my queue. As you pointed out, it caused incompatibility with other gamepads. What we need is better gamepad recognition and mapping on Android. I’ll make my patch for the GP20 available as soon as I clean it up a bit, but we still need to work on better gamepad support. It was already on the list, but now it has a star next to it. Scratch that, now it has two stars next to it.

That usually happens when Mobile HDR has been enabled. Can you please verify if that’s the case? If not, then something changed between preview 8 and final, and I’ll have to take a look.

The manifest was completely editable pre-4.7, but that wasn’t user friendly for other cases. We need to balance ease of use vs. flexibility. Have you checked the Android Packaging project settings in 4.7? You can definitely add to some sections of the manifest. The ‘vr_dual’ is not editable via the editor, but I’ve also been told that that path has performance issues and isn’t fully supported, which is the primary reason that I didn’t present it as an option. If you need that option, then I would recommend opening UEDeployAndroid.cs and editing GenerateManifest(). If you need any help with that, please let me know.

Yes, we should add this.

This is accessible via an Exec command.

I’ll look into this. The volume controls currently work, so what specifically are you looking to have work differently? UI?

Yes, we should do this.

Also, please note that we currently default to CPU 2, GPU 2 for the Oculus mobile SDK perf settings. If you feel that you’re more GPU limited than CPU limited, you can edit the engine config.ini to specify CPU 1, GPU 3.

[FONT=Courier New][GearVR.Settings]

I’m also going to repost the steps for getting running on GearVR here. I’m sure that Marcel is well past these steps, but hopefully this can help others. We’re working on streamlining a bunch of these steps, especially the parts about requiring source in order to get the plugin to compile into the android executable.


  • Have a Note 4 and GearVR kit, and already be set up with the ability to build and deploy Android UE4 projects to your device
  • Grab 4.7.1 from GitHub and run the Setup.bat in order to get the latest binaries. Please make sure to re-run Setup.bat if you have already run it, because there are new libraries for GearVR support
  • Get an osig file for your device from Oculus Developer Dashboard
  • Create an ‘assets’ directory within Engine/Build/Android/Java, and place your osig file in this assets directory. Your project will not run on device without this osig present in this directory at packaging time

Build and Run the editor:

  • Run GenerateProjectFiles.bat to update your solution
  • Open ue4.sln in visual studio, and build and run the UE4 project in ‘Development Editor - Win64’ configuration

Create your project:

  • Select the ‘New Project’ tab
  • Select the ‘C++’ tab (currently GearVR support requires a C++ project since plugins are not built into the default executables, alternatively create a blueprint project and add a blank c++ class to it in order to kickstart a compile/link stage into the build)
  • Select the ‘First Person’ template
  • Change the options to ‘Mobile / Tablet’, ‘Scalable 2D / 3D’, ‘No Starter Content’
  • Name your project something like ‘MyGearVR’
  • When visual studio opens up again, compile and run the MyGearVR project

Configure and package your project for GearVR:

  • Go to the ‘Windows/Plugins’ menu item, and go to the Head Mounted Displays page - disable Oculus (optional) and enable GearVR, click ‘Restart Now’
  • Select the ‘Edit/Project Settings…’ menu item
  • In the Android section, scroll to the top and click the ‘Configure Now’ button for Android support
    Set the Minimum SDK version to 19 or higher
    Select the ‘Configure the AndroidManifest for deployment to GearVR’ checkbox
  • In the Packaging section, optionally click the advanced down arrow in Project and disable ‘Full Rebuild’ in order to speed iteration times
  • Select the ‘File/Package Project/Android/Android (ETC2)’ menu item and package your project to a directory of your choosing

Install and Run:

  • Connect your device and have it able to accept adb sessions. Please see the normal UE4 Android documentation for details if you’re not familiar with this process
  • Run the installation script from within the directory you packaged to
  • On device, find your application icon, click it, and then attach the GearVR headset to the phone

Wow, due to time offset here in Germany I have been off for the last 12 hrs and you already provided a lot of support in the meantime. Awesome you guys are doing work on sunday only to make me happy, thanks! =)

I have some non development related stuff to do first but this evening I will definitely try UE4 again with the info provided by you and give feedback!


A lot of people don’t know about this, and I’d like to mention it so people feel more comforted about Epic’s support for VR in general.

I used to live in Cary, NC (where Epic HQ is located) for 2012-2014 before moving back to OH. In early 2014 a VR enthusiast named Henry took it upon himself to start an VR group through that would allow anyone in the area to come experience VR for the first time and just come chat about this awesome future.

Several Epic employees joined the group and actually attended the first meetup in a small bar. For the second meeting…this happened:

4ca6e61f65cb353e6f403a786627bc16c9709a77.jpeg says 140 group members attended, that number was easily over 200 from people bringing friends and a large number of Epic employees joined since it took place in their own office. Epic had two DK2’s setup with a Couch Knight demo, several group members brought their DK1 and their own VR demos for others to try, and in general it was a pretty awesome time to just get that many people super excited and curious about VR in one space. We also had numerous researchers and one Oculus employee attend. I manned one of the DK1 stations for over an hour showing Blocked In to about 50 people. Every single person told me they had never used VR before, and every single one of them walked away smiling.

Photos from event:

I guess in conclusion we can all be a little bummed that the GearVR implementation isn’t perfect in 4.7, but to think that Epic is ignoring VR is completely false and you can sleep peacefully knowing that it will be fixed.

Thanks for the feedback! However could you please look into this as many people are stuck exactly here (see the last posts in: Gear VR support? - VR and AR Development - Unreal Engine Forums )

Following your instructions to the letter means mobile HDR is indeed already disabled (since we select “scalable mobile”). I’ve tested both with Mobile HDR on and off and get the following results with following your steps exactly except using 4.7.1 binary (also had the same with 4.7 Preview 8 binary):

Mobile HDR Off:

Mobile HDR On:

What is the command exactly??

Looking forward to your feedback :wink:

EDIT I’m wondering now if this might be Note 4 model related? - I’m testing with my Exynos model which has a different GPU from the Snapdragon model …

Hi Sanborn,

thanks for giving me that insight, that’s really promising.

I do not have the feeling Epic ignores VR, actually I am very happy with the VR implementation so far. I only had the impression that GearVR and maybe worldspace GUI, if we count that to a general VR requirement, is on a lower priority than I hoped.

Nick and JJ, Thanks a Ton!

It helps to have some info, and I’m sure GDC has kept you busy with a number of “unmentionable” priorities.

I’m aware there are some rendering features that might not work well in VR in their current state, but I’ll make an argument to include them anyway. VR is in a very experimental mode right now. One could (and I would personally like) to build vr experiences that leverage a specific rendering feature, which is optimized to reduce usage on other rendering features in order to enable it.

As an example, I built a vr blood vessel. I have only a single dynamic light (headlight), and have other things highly optimized to run very fast on the rift. I have some headroom for a potentially expensive feature. LPV might be very cool in this instance. It’s not a full game, so it doesn’t require as many features, drawCalls, or other things that slow things down.
I’m also interested in working with digital humans, so I’ve held off some of that work in order to have sssProfile working. The scenes would be entirely based on characters, so the scene itself would be almost nil other than the character/s. This is an example where all the gpu horsepower could be focused on one expensive rendering feature, and shave away all the rest.

VR, for the time being, is full of small demos that could make good use of “targeted” advanced features. I could be wrong, and performance may be so bad that your devs are totally correct in keeping them out of my virtual hands… but I won’t really know until they can be seen.

Thanks again for the updates!


Ok I’m back with some feedback!

@Nick Whiting

A Quickstart Guide, a GearVR Template and better communication. That all sonds great!

@JJ Hoesing

  1. I would be interested in your MSAA patch! Thanks!

  2. Ok now I understand the screen percentage issue, of course we only need 2 1k textures, nothing more nothing less. The graphics just looked like the could need some sp, but maybe the 2x msaa will fix it (see picture below). Maybe the exec command should answer something like “The GearVR plugin only allows 100sp, this command has no effect.” - Only to avoid the question comming up again and again ^^

  3. Turning mobile HDR off fixed the “game only on the left half of the screen” issue. Thanks for that hint! So this is a temporary bug or will mobile HDR not be available for GearVR? Since I am doing some kind of first person Space RTS, I planned to use “Full HDR Lighting with per-pixel lighting from the Sun” but without shadows or post processing. Will that be possible at some point? Also regarding performance?

  4. Compiling works like you described, thanks for the official advice. Anyways that was the way I was doing it already. So compiling and executing works for 4.7.1 confirmed.

  5. Oh good that you are aware of the EI-GP20 issue. I thought that went completely unnoticed. This gamepad is really not that good, but since Samsung sells it in a bundle in some countries, it’s kind of mandatory to support it.

  6. You are right about the vr_dual. I made some tests and there is bad jitter. Same if you run stuff in Oculus Developer mode. So yes a dev that is serious about Android development and needs a special Manifest could hack GenerateManifest() if he needs to, it’s easy. Thanks for pointing me to it.

  7. Good that you are aware of the Intend problem.

  8. If you mean the exec command “hmd ovrglobalmenu”, it crashes for me (trace see below). After the crash I land in oculus home if I started on top of it via “adb shell am start” yes, but that was not the expectation I guess. Additional there is the required OVR Platform menu with the passtrough and brightness adjusting etc. Since there are no assets included for it maybe that was not the globalmenu you mean or did you? Basically providing a “Would you like to go to Oculsu Home?” activity, available by intend or if you like exec, and a OVR Platform activity available the would be a nice idea.

  9. Volume keys work! But for the required volume overlay at least current and max volume values needs to be exposed somewhere. Maybe that data is available but i do not know where to get it.

  10. Cool that you are going to make a template, I am looking forward to it!

  11. Gpu level 3 might be worth a test, but it will get hot. Hope you figure out how to render low poly stuf fnice and fast without the need for GPU3.

Anyways I stay patient now. I wish you a good time at GDC! Hopefully GearVr will still be some priority after that and the new revealings will not make it irrelevant, otherwise I better get another project xD

Attachment 1: Full resolution, uncompressed png screenshot of the FPS template compiled with the above instructions after clean checkout. vr_only set and dev mode is off

Attachment 2: Crash after using the console command “hmd ovrglobalmenu” - I tried starting from the launcher icon and also starting over oculus home via Wifi connected adb

W/VrApi (24135): ovr_StartPackageActivity( com.oculusvr.vrlib.PlatformActivity, globalMenu )
W/VrApi (24135): ---------- ovr_LeaveVrMode ----------
W/VrApi (24135): ovr_LeaveVrMode: Called with tid 24149 instead of 24731
F/libc (24135): Fatal signal 6 (SIGABRT) at 0x00005e47 (code=-6), thread 24149 (orks.testgearvr)
I/DEBUG (18327): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG (18327): Build fingerprint: ‘samsung/trltexx/trlte:4.4.4/KTU84P/N910FXXU1ANK4:user/release-keys’
I/DEBUG (18327): Revision: ‘12’
I/DEBUG (18327): pid: 24135, tid: 24149, name: orks.testgearvr >>> com.pyritesoftworks.testgearvr <<<
I/DEBUG (18327): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
I/OVR (23118): DeviceManagerThread - event 89 (499Hz) (Tid=23866)
I/DEBUG (18327): r0 00000000 r1 00005e55 r2 00000006 r3 00000000
I/DEBUG (18327): r4 00000006 r5 00000016 r6 00005e55 r7 0000010c
I/DEBUG (18327): r8 7d0e5e48 r9 8044fd00 sl 7f4b9240 fp 7d0e54b0
I/DEBUG (18327): ip 00a92db4 sp 7d0e4cb0 lr 400a81b5 pc 400b715c cpsr 000f0010
I/DEBUG (18327): d0 7661654c5f72766f d1 3a65646f4d725665
I/DEBUG (18327): d2 2064656c6c614320 d3 6469742068746977
I/DEBUG (18327): d4 000000650000006d d5 000000200000003e
I/DEBUG (18327): d6 000000500000003c d7 0000006f00000072
I/DEBUG (18327): d8 41d53ce63f800000 d9 0000000000000000
I/DEBUG (18327): d10 0000000000000000 d11 0000000000000000
I/DEBUG (18327): d12 0000000000000000 d13 0000000000000000
I/DEBUG (18327): d14 0000000000000000 d15 0000000000000000
I/DEBUG (18327): d16 726174535f72766f d17 6567616b63615074
I/DEBUG (18327): d18 0000006d00000068 d19 0000002000000064
I/DEBUG (18327): d20 000000760000006f d21 0000006700000072
I/DEBUG (18327): d22 0000006f0000006c d23 0000006100000062
I/DEBUG (18327): d24 bfc79895d4d660fa d25 bff0000000000000
I/DEBUG (18327): d26 3ff000000ff2fb16 d27 3fdf315d21392240
I/DEBUG (18327): d28 3f991df3908c33ce d29 3fb12ffd2aa4632e
I/DEBUG (18327): d30 3fb4b124594d3205 d31 3fd97e7c38f8287a
I/DEBUG (18327): scr 8000001f
I/DEBUG (18327):
I/DEBUG (18327): backtrace:
I/DEBUG (18327): #00 pc 0002215c /system/lib/ (tgkill+12)
I/DEBUG (18327): #01 pc 000131b1 /system/lib/ (pthread_kill+48)
I/DEBUG (18327): #02 pc 000133c5 /system/lib/ (raise+10)
I/DEBUG (18327): #03 pc 000120fb /system/lib/
I/DEBUG (18327): #04 pc 00021a10 /system/lib/ (abort+4)
I/DEBUG (18327): #05 pc 041365a4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (ovr_LeaveVrMode+1052)
I/DEBUG (18327): #06 pc 04136690 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (ovr_StartPackageActivity+60)
I/DEBUG (18327): #07 pc 03d328cc /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FGearVR::Exec(UWorld*, wchar_t const*, FOutputDevice&)+3088)
I/DEBUG (18327): #08 pc 02a948a8 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UEngine::Exec(UWorld*, wchar_t const*, FOutputDevice&)+380)
I/DEBUG (18327): #09 pc 02607ffc /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UGameEngine::Exec(UWorld*, wchar_t const*, FOutputDevice&)+808)
I/DEBUG (18327): #10 pc 0264a274 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UGameViewportClient::Exec(UWorld*, wchar_t const*, FOutputDevice&)+1744)
I/DEBUG (18327): #11 pc 0276c95c /data/app-lib/com.pyritesoftworks.testgearvr-1/ (ULocalPlayer::Exec(UWorld*, wchar_t const*, FOutputDevice&)+2576)
I/DEBUG (18327): #12 pc 02818dc4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (APlayerController::ConsoleCommand(FString const&, bool)+704)
I/DEBUG (18327): #13 pc 02f02ce8 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UConsole::ConsoleCommand(FString const&)+940)
I/DEBUG (18327): #14 pc 02f04ca4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UConsole::InputKey_InputLine(int, FKey, EInputEvent, float, bool)+1792)
I/DEBUG (18327): #15 pc 02f07db8 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UConsole::InputKey(int, FKey, EInputEvent, float, bool)+104)
I/DEBUG (18327): #16 pc 026403a4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (UGameViewportClient::InputKey(FViewport*, int, FKey, EInputEvent, float, bool)+240)
I/DEBUG (18327): #17 pc 02640628 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (non-virtual thunk to UGameViewportClient::InputKey(FViewport*, int, FKey, EInputEvent, float, bool)+40)
I/DEBUG (18327): #18 pc 02ebc440 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FSceneViewport::OnKeyUp(FGeometry const&, FKeyEvent const&)+460)
I/DEBUG (18327): #19 pc 02ebc578 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (non-virtual thunk to FSceneViewport::OnKeyUp(FGeometry const&, FKeyEvent const&)+12)
I/DEBUG (18327): #20 pc 01759b0c /data/app-lib/com.pyritesoftworks.testgearvr-1/ (SViewport::OnKeyUp(FGeometry const&, FKeyEvent const&)+152)
I/DEBUG (18327): #21 pc 016616f0 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FSlateApplication::ProcessKeyUpEvent(FKeyEvent&)+896)
I/DEBUG (18327): #22 pc 0166129c /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FSlateApplication::OnKeyUp(int, unsigned int, bool)+452)
I/DEBUG (18327): #23 pc 01661a34 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (non-virtual thunk to FSlateApplication::OnKeyUp(int, unsigned int, bool)+12)
I/DEBUG (18327): #24 pc 0111d8e0 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FAndroidInputInterface::SendControllerEvents()+1784)
I/DEBUG (18327): #25 pc 0111d1c4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FAndroidApplication::PollGameDeviceState(float)+108)
I/DEBUG (18327): #26 pc 0164ce58 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FSlateApplication::PollGameDeviceState()+144)
I/DEBUG (18327): #27 pc 010e7524 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (FEngineLoop::Tick()+6884)
I/DEBUG (18327): #28 pc 010f07e4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (AndroidMain(android_app*)+3164)
I/DEBUG (18327): #29 pc 010f0aa4 /data/app-lib/com.pyritesoftworks.testgearvr-1/ (android_main+184)
I/DEBUG (18327): #30 pc 010fbde8 /data/app-lib/com.pyritesoftworks.testgearvr-1/
I/DEBUG (18327): #31 pc 0000d2a0 /system/lib/ (__thread_entry+72)

I couldn’t agree more! We’re definitely going to fix them up so you guys can experiment with them. I’m personally very curious about pushing the digital human interaction, which you really need those features for. Now that things have settled down a bit on the platform work, we’ll start getting these things fixed up for you guys to play around with. Performance was the reason for the priority being lower on fixing those up than new platform support, but definitely not a reason to stop us from doing it! As you say, VR is all about experimentation, and now we can focus on fleshing out the toolkit a bit more for you guys.

Can’t wait to see what you guys end up doing!

A quick tip for anyone getting the “only rendering in left eye despite Mobile HDR being turned off” bug, check to see that you have static lighting turned on under Project Settings -> Engine -> Rendering -> Allow Static Lighting. Also make sure the checkbox is NOT checked at World Settings-> Lightmass -> Advanced -> Force No Precomputed Lighting.

I was getting that problem with static lighting completely disabled. My guess is the renderer has no idea what to do in this situation and craps out. Be sure to restart the editor after changing these settings. Running fine now with Mobile HDR off! I’m on a build compiled from source at the 4.7.1 tag.

Many thanks for this info sinoth - unfortunately when doing JJ’s instructions above, this step:

  • Change the options to ‘Mobile / Tablet’, ‘Scalable 2D / 3D’, ‘No Starter Content’

already has those settings (allow static lighting ON and Force no Precomputed Lighting OFF). Anything else that needs tweaking to get the FPS template working?? Frustrated at not being able to play around with some ideas on the gearVr :frowning:

PS: which Note 4 model do you have? Snapdragon or Exynos ?

EDIT: ah I just read:

So this means it’s still not working on the Binary 4.7.1 release? the release notes are a bit misleading then :frowning:

"New: Android builds can now target GearVR by enabling the GearVR plugin, and selecting the GearVR in the Android packaging project settings. "

Hey I really appreciate your assistance Mr Hoesing but there was a few questions I had about a couple of the steps listed here. At the moment I have done everything except for these two steps and I have gotten to the point in which it will launch to my Gear but it always ends up with my project saying it has to close and then the standard Oculus home menu opens up.

Now I have extremely little C++ experience so I was wondering if the current launchers 4.7.2 version works properly. Basically can I run it with what the launcher downloads by default or do I need to download that specific version from the github?

The second part that I am confused about is the blueprint blank c++ class you mention to kickstart the gear plugin. As it stands I am a one man operation and 100% of my “coding” comes from blueprints and I am having trouble trying to figure out how to create some sort of blueprint / blank C++ hybrid to get this thing running correctly so I can at least get it function within the headset.

Is there an update on this coming soon? I’d prefer to use Unreal for the mobile VR jam, but it’s just impossible currently. Even the Epic member I met at GDC couldn’t get a basic demo running at 60fps on the Gear.

Having a template to work off of would be amazing.