DepthPriorityGroups for 3D widgets

It looks like DepthPriorityGroups was removed from the engine due to shading issues, shadows, transparency etc.

However now that 3D widgets are becoming necessary to accomplish VR menus I would like to achieve a similar effect.

I can’t move the menu closer to the camera to avoid clipping because the inter-ocular distance will change and you will end up going cross-eyed. Does anyone know of a way I can cheat this to always render the widget in the foreground?

I don’t mind digging into the engine code if you have any suggestions on what I might be able to tweak.

I think I can help…

is this for GearVR for one…

and is your menu UMG mouse center interactable or line trace… cause I need help there…

Ill share what i know anyway but I came here looking for an answer for my problem.

but let me know if GearVR before I go on…

No I’m not using the GearVR. Oculus DK2.

I’m using mouse center interactable on mine, which I imagine wouldn’t work on GearVR.

I investigated the line trace technique but decided against it because from what I saw I would have to set up hit boxes for every button. I decided that mouse center was a more versatile hack, and that with the possibility of the interaction method having an official fix soon that fewer moving parts would make the transition easier.

Ok share your secret I’ll share mine…

I’ll Go first…
3 settings is all ya need…
Assuming that you character uses the Add Component Widget attached to Character, and calls your other widget thru the Widget Class this works in GearVR and I dont know why it wouldnt in Occulus.

Does not fully work in PIE But In PIE you will not get clipping but popping, and then at least on my end it then works in GearVR.

So, go to the Engine Materials, find the Widget3DPassThrough Material. Open it. In Details Panel go down and check the Disable Depth Test option. And since this is transparent material allready your set for part one. save close.
you dont need to make new material and do c++ changing. Just this.

Now note this affects all the widget main materials. But if not associated with characters camera will not have any Depth effect visible. So great for HUDs and in Game World Widgets.

Second part.
In your characters BP, i am assuming you added widgets here and set distance then called other widgets into play, yes… if so, now is where you set your depth… go down into widget details in character and find…
Render Custom Depth Pass , check this.
Then Translucency Sort Priority, set distance . here. 0 is distant, 300 is close, 1000 is closer… you’ll get it.

Save all then test man…

I am hoping this helps ya and you share that great info of your line trace with me…

all the best man.

BTW I think the mouse center will work on GearVR I’m half way there but cant get the last interaction part working.
And the more I think about it I am guessing it will not work since it’s using PC to send data, and that will most likely work like in PIE and pop.

Fingers crossed it does.

So this is working great for the rendering of my umg menu. I’m still using a custom stencil pass to correct color as i described [here][1]. I had to modify my post process material to use multiple stencil values though, so that I could overlay the motion controller and laser beam on top of the menu.

While this covers the majority of my rendering issues, I found this isn’t working with my current mouse cursor hack that I described [here][3]. What happens is that even though the menu renders in front of everything else, as far as the collision detection is concerned the menu is still clipping through the geometry. So the buttons stop working while the menu’s geometry is clipped behind something.

I have not yet tried the new [VR UMG Compatibility Plugin][4] though, which I’m hoping will solve this issue.

Ok… if ya can like i was told, wait for 4.13… and just keep doing what your doing… and it solves alot of things.

for one, that WidgetPassThrough material is now exposed in deatils/material so you can now make a duplicate and set one for disable depth and one without, and not have to settle for the world widget to inherit your HUD disable depth settings which forces use of world to be set to masked and kills transparency.

Ok for clipping… I encountered this as well… based off linetrace interaction… which will need to be altered somewhat for 4.13 I am sensing now… for your menu / inventory taht clips, and its buttons or objects in/on it. You’ll need to create a custom trace channel to use that ignores everything else in the world, so it will pass thru and hit your buttons…

Edit> Project Settings> Engine / Collison you can play around in there… and make a custom object or channel trace.

You’ll see it appear in Details> Collision> Collision Responses / Trace /Object just choose it and ignore all else or combine to work. Hope it helps…

Following up on this. I made the jump to 4.13 and now I’m using Widget Interaction Components to do all of my interaction. New WidgetPassThrough material option worked great. Thanks for that tip.

The problem I ran into with the Widget Interaction Components is that they do their own line tracing.

I had already set up a custom collision channel, and placed my Widget Component in that channel, per your suggestion.



Then I simply made a new c++ class from WidgetInteractionComponent.cpp and overrided its PerformTrace function with my own.

#include “UnifiedPlatform.h”
#include “MyWidgetInteractionComponent.h”

bool UMyWidgetInteractionComponent::PerformTrace(FHitResult& HitResult)
	switch (InteractionSource)
	case EWidgetInteractionSource::World:
		const FVector WorldLocation = GetComponentLocation();
		const FTransform WorldTransform = GetComponentTransform();
		const FVector Direction = WorldTransform.GetUnitAxis(EAxis::X);

		TArray<UPrimitiveComponent*> PrimitiveChildren;

		FCollisionQueryParams Params = FCollisionQueryParams::DefaultQueryParam;

		FCollisionObjectQueryParams Everything(FCollisionObjectQueryParams::AllObjects);
		return GetWorld()->LineTraceSingleByObjectType(HitResult, WorldLocation, WorldLocation + (Direction * InteractionDistance), FCollisionObjectQueryParams(ECollisionChannel::ECC_GameTraceChannel2), Params);
	case EWidgetInteractionSource::Mouse:
	case EWidgetInteractionSource::CenterScreen:
		TArray<UPrimitiveComponent*> PrimitiveChildren;

		FCollisionQueryParams Params = FCollisionQueryParams::DefaultQueryParam;

		APlayerController* PlayerController = GetWorld()->GetFirstPlayerController();

		ULocalPlayer* LocalPlayer = PlayerController->GetLocalPlayer();
		bool bHit = false;
		if (LocalPlayer && LocalPlayer->ViewportClient)
			if (InteractionSource == EWidgetInteractionSource::Mouse)
				FVector2D MousePosition;
				if (LocalPlayer->ViewportClient->GetMousePosition(MousePosition))
					bHit = PlayerController->GetHitResultAtScreenPosition(MousePosition, ECC_Visibility, Params, HitResult);
			else if (InteractionSource == EWidgetInteractionSource::CenterScreen)
				FVector2D ViewportSize;

				bHit = PlayerController->GetHitResultAtScreenPosition(ViewportSize * 0.5f, ECC_Visibility, Params, HitResult);

			// Don't allow infinite distance hit testing.
			if (bHit)
				if (HitResult.Distance > InteractionDistance)
					HitResult = FHitResult();
					bHit = false;

		return bHit;
	case EWidgetInteractionSource::Custom:
		HitResult = CustomHitResult;
		return HitResult.bBlockingHit;

	return false;

#pragma once

#include "Components/WidgetInteractionComponent.h"
#include "MyWidgetInteractionComponent.generated.h"

UCLASS(ClassGroup = Experimental, meta = (BlueprintSpawnableComponent, DevelopmentStatus = Experimental))
class UNIFIEDPLATFORM_API UMyWidgetInteractionComponent : public UWidgetInteractionComponent

	/** Performs the trace and gets the hit result under the specified InteractionSource */
	virtual bool PerformTrace(FHitResult& HitResult);

Now everything works perfectly. My depth perception goes haywire when I get within inches of a wall and open up the menu, that’s floating 6 feet away, but I can live with that.