Is UE4 always going to be a second class citizen for Oculus?

I am using a windows 8.1 pc, x64, Intel i7 950, 12gb ram, nVidia 770 GTX with 4gb memory.

Lucky you. I've never once been able to get direct mode to work at all. However, the biggest issue for me is lack of flexibility in the plugin.

"BlackFang" wrote:
Lucky you. I've never once been able to get direct mode to work at all. However, the biggest issue for me is lack of flexibility in the plugin.

I already explained you in that another topic that there are objective difficulties in giving you full freedom and flexibility. Our objective is to provide generic support that would satisfy 99% of our customers and won't sacrifice VR experience in a sake of that flexibility (latency in particular). There always will be uncovered particular cases, so - Oculus plugin and whole UE4 is distributed as source code. Having said that, I want to reassure you that we continue to work on improving Oculus support for UE4. If you have a case that you think is not possible to implement using current Oculus plugin I would be glad to have a look on it and fix the plugin, if possible. Just send a sample map + description of what you are trying to achieve to support@oculus.com and mark it 'For artyom17'.

As to mobile UE4: it is in development by both Oculus & Epic (mostly Epic) and should be available soon.

PS. For some reasons I don't receive notifications on new replies in this forum, so apologize for lack of communication (I'll ping our web guru).

@artyom17 You can still get that same latency and expose ways in which you can allow for some much needed customizability i.e. view/control decoupling, feeding separate images to each eye, exposing accelerometer values etc. Our approaches to decoupling camera from control currently work without latency impact, but they are a work around. Its a matter of exposing the desired options, which will apply the required changes at the correct render order. We would still have the options to change these things, and the latency isn't impacted. Consider how usable the rift is in unity, try to achieve the same level of consistency.

I personally consider that the rift abstraction should be two sets of cameras (locked together) which we can apply post process to (separately), move around or attach to vehicles/etc. These cameras would change their position based on the positional tracking as well, but it would not be something bound firmly to character control. This is an intuitive abstraction, one where it would be trivial to get the current default behavior, but with the added flexibility of being able to use it in any number of other ways.

The plugin does need to have a re-work of how it exposes those controls to the developers.

Ok, let me see what I can do in this matter. Can't promise any quick results though, but seems like the demand to better camera controls is high, so the task is prioritized.

"artyom17" wrote:
Ok, let me see what I can do in this matter. Can't promise any quick results though, but seems like the demand to better camera controls is high, so the task is prioritized.

Thank you for taking the time to address the concerns mentioned. It is really appreciated. I did hope this would prove to be productive and was certainly not meant to attack Oculus. Thank you again for taking concerns under consideration and I appreciate you working to improve the UE4 plugin.