So I went ahead and branched/merged this in to see it firsthand and at first could not tell the difference, went back and forth between the two versions a few times, but now I see it. It’s a really subtle difference, where rolling the head creates a slight perspective shift on the objects in the center of view, shifting the angle back and forth a few degrees, best way that I can describe it. Without the change, the image at the center of view stays at the same perspective when rolling the head side to side.
Have to admit that at first glance (ba-doom crash) I kind of prefer the first version unchanged, however can see how the perspective shift could be more comfortable or natural for most people. Herobound is one of the better VR games that I’ve experienced on the GearVR as it just feels different than the others somehow and is one of the only ones that I can spend enough time in to get the overheat warning - maybe this is in part why it feels that way to me.
In any event, thank you for integrating it into your branch and hosting it for everyone.
Hey Everyone!
If anyone is using a merged 4.7.5 version with JJ’s fixes or 's awesome public merged 4.7.5 and may be having trouble with a OVRGLOBALMENU blueprint, here’s the one I put together from their information in this thread. Hope it’s useful. I assume there is better ways to do it but that’s what I put together just to make sure I have the functionality until I progress further on my project.
I’ve pulled the Head Tracking patch in and for me it’s working oddly. The head movement feels very exaggerated despite the measurements looking like the correct defaults. Also, it adds its position to my Pawn Camera, which differs from the DK2 behavior. I have my Pawn camera fixed at 160cm height. If I unplug the tracking camera, then I get the head model on the DK2 and the camera stays at 160cm height. On the Gear VR without changes to the scene, the camera moves up to 177cm or so. Also the effect of the head model in the Gear seems about double compared to the DK2. The DK2 feels correct, whereas in the Gear it feels like things are no longer anchored in space. I set the values to half of what they were and now it feels much better. TotalOffset += FVector(0.06f, 0.0f, 0.085f);
a.carter1182, this is a little cleaner, it doesn’t have a Tick. I also thought .75s was too short. Does anyone know what the official word is on the delay for this?
For those that are wondering what a Virtual Head Model is here is something you could try. Look straight ahead and place a finger at the bridge of your nose, between your eyes. Now move your hand slightly away from your face and while keeping it at that position, roll your head so that your ear touches your shoulder (and don’t move your hand with your head). Notice how your eyes haven’t simply rotated about your hand but have physically moved away from it? It is this physical position change that we’re modeling when all we’re doing is rotating our head. You can try the same thing but this time looking to the right. Your eyes move in an arc away from your hand.
Nearly all FPS-based cameras in games rotate about their center. So a roll or yaw change with a FPS camera would be the equivalent of your head rotating about that finger you had between your eyes, rather than rotating about the base of your neck/skull. In a monitor-based FPS that’s not an issue. But in VR, rotating about a point that doesn’t match where your head actually rotates can cause discomfort. It can appear that the world is moving with your head, rather than your head moving in the world. A virtual head model simulates this correct motion.
Of course, the best solution to all this is to just have position tracking built into the HMD, like with the DK2. Everything with a VHM is just an approximation, and doesn’t conform to the specific user’s head (without allowing for custom values).
@jstarrdewar:
The offset from UE4’s camera makes sense as the view matrix is indeed being offset when in VR with this change. The correct thing to do would be to first move the origin of the camera and then apply the virtual head model’s offsets. This would place the virtual eye at the same location as UE4’s camera when the user is looking straight ahead. Of course, this is a quick hack to implement a VHM so it may not be perfect.
If someone wanted to try and correct for this, in glancing at the code I suspect you could subtract the FVector(0.12f, 0.0f, 0.17f) from the ViewLocation, after converting the vector to UE4 units of course. Unfortunately, I don’t have time to try this out, and my own Jam project doesn’t rely on an exact camera position. But if someone else figures this out it would be great if they could share it.
Thank you all for the fork and the patches! , did you already tried to patch in also the commits regarding the Oculus Audio SDK integration currently available on master?
Also, in the twitch if I’m not wrong was mentioned the possibility to deploy on the device only the resource files that have been modified instead of the whole package when launching the app. Anyone knows how to achieve that? I’d love to be able to test my app through wifi (in order to avoid connecting and disconnecting HMD and device every time), but deploying each time all the package through wifi takes forever… is this something available only in 4.8, is it already possible in 4.7 or do I remember it wrong?
Awesome!! What shall I recompile after applying this patch? Is it sufficient to rebuild the editor?
When launching I keep seeing all the dab push commands (although it feels a faster). Is that normal?
Umh… just playing around with 's 4.7.5+patches, whenever the GearVR plugin is enabled I only get a black screen :-/
Packaging without the plugin works, so maps are loaded correctly, and the project works in gear VR with stock 4.7.5
When running the app with the plugin enabled in the logcat I don’t see particular problems, TimeWarp is running, but those “Changing vsync” messages sound a bit weird to me… anyone else experiencing the same problem?
JJ, I’m using a lollipop device, is this the issue you were randomly experiencing with the MSAA patch?
Edit: Ok, it definitely was an issue related to the MSAA patch and Lollipop, disabling it solved the issue. Really looking forward a Lollipop compatible implementation!
Just above, devel.bmad mentions that the MSAA patch didn’t work on Lollipop (5.x). I only have a Kitkat (4.4.4) phone here to test on. Has anyone else tried out my VRJam_4.7 branch on a Lollipop phone and can confirm that it works or doesn’t work?
It would be very disappointing to find out that the judges can’t try out my (or anyone else’s) project due to this.
I vaguely recall reading on the Oculus forums that the Judges will have access to both. I’ll be putting down which version I have. I’m in Australia and I get even get the update, so just 4.4.4 for me.
Yeah, over in the VR Jam FAQ they recommend upgrading to Lollipop yet say that the judges will have KitKat available to them.
According to Oculus, the UE4 Oculus Audio SDK integration only works with Windows and XAudio2. That quote is from a thread where Bino went for it and tried getting the integration in the master branch to work and encountered difficulties. As far as anyone has discovered so far, the only way to get the Oculus plugin working on the GearVR with UE4 is by running it inside FMOD Studio in a hacked source branch of 4.7. That thread explains the details.
Yes, I agree. Haven’t tried the FMOD solution on android yet but I’m glad to hear that is working for you.
As concerns the patch for iterative deploy for Android: I’ve integrated it in 's fork (it’s just a couple of file) but I’m not sure how to compile it, just rebuilding the editor does not seem to have any effect. Is there any script I’m supposed to relaunch? I’ve tried adding Logs inside these class but it seems that they never get recompiled.
The possibility to update on the device only the modified files would be great to accelerate the deployment times, it would also make dab over wifi much more appealing…
I’m running lollipop and 's branch fine with ETC2. However I’ve a Exynos chipset Note4 which did not run well at all on kitkat (ie: freezes after one or two frames). Perhaps lollipop fixes Exynos devices and cripples those with Snapdragons? Wondering how my app runs on Snapdragon and lollipop now :S
Thanks, I have figured it out now; I have a snapdragon. Not sure how I missed this
I can compile with the " version" ; it takes forever and I have a logfile full of issues (but I am new to the engine in general) and somehow I think the MSAA is not working. However the light-example from Epic is looking very nice.
