Frustrated. Position Tracking in UE 4.4

Same issue. I've been googling for answers without any luck.

My XYZ head position does not update UE4 visuals at all. Basic C++ config. No code, just for substances. Latest Oculus SDK and UE4 4.4.1 Hotfixpreview.

I'm wondering if I have a scale issue (although I shouldn't) and no matter how far I move the DK2, I don't notice any XYZ movement in the UE4.

Also, I thought the tracking of the DK2 was optical, but when I covered the IR sensor with my hand, rotational head tracking still worked. Does this indicate that my DK2 camera is the issue? I do get positional and rotational head tracking in Elite (or at least I did last I checked) and in the demo.

Thanks
Mark

Positional tracking is optical. Rotational tracking is still using gyros and magnetometers, and is supposed to keep working even if the IR camera is occluded. I just opened up OculusRiftHMD.cpp and rewrote it to my own needs, its easier for me than trying to make Oculus' code work. I facepalm nearly everytime I look at their code. I can only go for about 4 lines without an audible, "Why?..." They keep shoving in things that simply aren't necessary and are only going to work for people making "Generic FPS 17".

Code-wise Oculus' role is to give us a quaternion, a vector, and make the game render in stereo with HMD warp and chromatic aberration correction. Instead, they want to jam in all sorts of nonsense to interfere with player cameras and the like.

Are you using PlayerController or PlayerCameraManager? For PlayerController positional tracking should work automatically, for PlayerCameraManager you should enable tracking by setting bFollowHmdOrientation to true.
Is there any way for me to repro the issue?

I think this problem may be fixed in the 4.4.1 Hotfix *release* (not the hotfix *preview* - they're separate...confusing, I know).

Could be wrong though.

"artyom17" wrote:
For PlayerController positional tracking should work automatically, for PlayerCameraManager you should enable tracking by setting bFollowHmdOrientation to true.

I think this quote really exemplifies everything wrong with what Oculus does code wise. I dont want a single ******* thing to happen automatically. When you put in these "features" that cause things to happen automatically, you are doing them based on assumptions which will only be correct for a small set of developers. Basically, you are adding in more work for me because I have to go back through OculusRiftHMD.cpp and guess at what everything was intended to do, and hollow out the functions accordingly.

So this time, I had to go through and gut every function that could potentially interfere with my camera placement because there is no built in way to keep the IR tracker on and stop your automatic camera hijacking.

If it is insisted that the Oculus plugin be done like this, could you also offer an Oculus-Lite plugin that features quaternion, vector, stereo with HMD war and chrom. ab. correction, and NOTHING ELSE?

Sorry if I sound rude, but this has been a very frustrating process for me.

I dont want a single ******* thing to happen automatically.

THIS. The whole plugin is "optimized" for some kind of FPS functionality.

I work on a project based on a pawn with the VehicleMovement component.

The OculusHMD Plugin treads this setup as if my Camera in that car has to be located at 0,0,baseeyehight - ok no problem, lets overwrite the pawns GetPawnViewLocation() to return the actual position of the players eyes in the vehicle.

Ok this problem solved the next is even more problematic: The stereo camaras in my setup are always moved as if yaw was 0 deg. That means if the vehicle's yaw is 180 deg and I move my head forward to the camera, in the game it moves backward. Feeding the Pawns ViewRotation into the Controllers ControlRotation does not help, but it should if I read the Plugin's code right. --- :idea: Edit: Found a fix and posted it in my next post down below.

Next, the Blueprint code in the Couch Knights code is hell of a mess with very little example character. It's BP scripting looks like just hacked together for an exhibition in an overnight shift and then released and never touched again. With no best practices to learn from it at all.

Anyway, please Oculus, do not tread us UE4 guys as second class. We need a Blueprint component, that we can position ourself inside a blueprint and we need the option of doing all the camera movement manually without hacking into the plugin. A FPS Pawn delivered with the Plugin would be fully sufficient to enable quick FPS demonstrating. But for more, we need full camera control.

"BlackFang" wrote:

"artyom17" wrote:
For PlayerController positional tracking should work automatically, for PlayerCameraManager you should enable tracking by setting bFollowHmdOrientation to true.

I think this quote really exemplifies everything wrong with what Oculus does code wise.

After a frustrating day of trying to get rotational and positional tracking to work on a camera placed in the scene using PlayerCameraManager in 4.4.1, I have to say I share the sentiments to some extent. What bothers me most is that responses tend to be along the lines of assuming it does work, you're just doing something wrong or unusual. Problems with Direct to Rift? Must be your config. Problems with judder? Must be your FPS. Problems with tracking? It should just work.

No offense intended guys, but I think taking a long look at how Epic handles developer interaction on their forums and streams, and how Epic handles feedback and transparency with the editor, could both go a long way.

Ok at least for my vehicle application I made my peace with the DK2 positional tracking.

I just added these few lines to the PlayerController and the automatic behavior becomes just what I want (stripped everything that is not relevant in that snippet):

#pragma once

#include "GameFramework/PlayerController.h"
#include "TankPC.generated.h"

UCLASS()
class VITREOUSTANKVR_API ATankPC : public APlayerController
{
	GENERATED_UCLASS_BODY()
protected:
	virtual void BeginPlay() override;
};

#include "VitreousTankVR.h"
#include "TankPC.h"
#include "Camera/PlayerCameraManager.h"

ATankPC::ATankPC (const class FPostConstructInitializeProperties& PCIP)	: Super(PCIP)
{
	PlayerCameraManagerClass = APlayerCameraManager::StaticClass();
}

void ATankPC::BeginPlay()
{
	Super::BeginPlay();
	PlayerCameraManager->bFollowHmdOrientation = true;
}

And for the Pawn you need to override GetPawnViewLocation to get rid of the FVector(0,0,baseEyeHight) camera offset - of course you can make the + FVector a UPROPERTY() and set it in the Blueprint. Overriding might not make sense for a FPS, but it does for my vehicle game where the camera is offset from the vehicle center.

FVector ATankPawn::GetPawnViewLocation() const
{
	return GetActorLocation() + FVector(167.5, 40.f, 180.f);
}

I'm glad to see I'm not the only one frustrated by the insistence on a code model that only accommodates the most generic of FPS setups. I haven't had time to do much lately, but when UE 4.5 comes out I plan on doing a massive rewrite of engine and oculus stuff before I begin to port my project over from 4.4.

"MarcelBlanck" wrote:
Ok at least for my vehicle application I made my peace with the DK2 positional tracking.

I just added these few lines to the PlayerController and the automatic behavior becomes just what I want (stripped everything that is not relevant in that snippet):

#pragma once

#include "GameFramework/PlayerController.h"
#include "TankPC.generated.h"

UCLASS()
class VITREOUSTANKVR_API ATankPC : public APlayerController
{
	GENERATED_UCLASS_BODY()
protected:
	virtual void BeginPlay() override;
};

#include "VitreousTankVR.h"
#include "TankPC.h"
#include "Camera/PlayerCameraManager.h"

ATankPC::ATankPC (const class FPostConstructInitializeProperties& PCIP)	: Super(PCIP)
{
	PlayerCameraManagerClass = APlayerCameraManager::StaticClass();
}

void ATankPC::BeginPlay()
{
	Super::BeginPlay();
	PlayerCameraManager->bFollowHmdOrientation = true;
}

And for the Pawn you need to override GetPawnViewLocation to get rid of the FVector(0,0,baseEyeHight) camera offset - of course you can make the + FVector a UPROPERTY() and set it in the Blueprint. Overriding might not make sense for a FPS, but it does for my vehicle game where the camera is offset from the vehicle center.

FVector ATankPawn::GetPawnViewLocation() const
{
	return GetActorLocation() + FVector(167.5, 40.f, 180.f);
}

This Right here fixed all of the crap I was experiencing, and I can now move forward with my project. I cannot thank you enough! For anyone interested I was having an issue supporting both VR and non VR gamemodes. It seemed I could only get one mode to be right at a time. I had followed the "detached camera" wiki article. That left me with a bit of code that I did not fully understand (also did not work so well). This code right here is simple, like it should be, and works.

*Virtual Fist Bump* YOU ARE THE MAN!