cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a way to turn on anti aliasing MSAA for GearVR in Unreal Engine 4.14?

saldavonschwart
Explorer
I'm working with Unreal 4.14 which supposedly even has a new forward rendering path for VR, though not sure if it is meant just for desktop vr or for mobile too.

I'm attempting to get antialiasing working on a Galaxy S6 with GearVR, but I've spent the past 2 days trying out all sorts of things and nothing makes a difference.

Basically, I start with a blank project set to mobile + scalable graphics quality. Then I've tried the following. Always packing to Android ETC2:

. default project settings (theoretically deferred path by default).
. With the new forward rendering option.
. Setting any combinations of the following console variables:
  . r.MSAACount
  . r.MSAACompositingSampleCount
  . r.DefaultFeature.Antialiasing
  . r.MobileOnChipMSAA
  . r.MobileMSAA
  . r.MobileContentScaleFactor
  . gearvr.EnableMSAA

Nothing seems to enable anti aliasing. I also posted this on SO, gamedev SE, Unreal AnwerHub and the Unreal forums. and no one has replied anything other than "MSAA should be on by default for GearVR."

Has anyone experienced this? Does anyone have any thoughts?

1 ACCEPTED SOLUTION

Accepted Solutions

rpalandri
Expert Protege
Hello!
The forward rendering path for VR is really for PC only, the mobile side has always been forward only.

By default, MSAA should be on when you start GearVR, but issues in the config files might have messed that up. How it works is, if gearvr.EnableMSAA is 1 when the plugin starts, then whatever the value of r.MobileOnChipMSAA is, it will be set as 1 (activated). r.MobileOnChipMSAA is the CVar that actually controls the rendertarget being set as an MSAA rendertarget, which activates the feature.

How we can debug this:
when gearvr.EnableMSAA is set, it will log :
UE_LOG(LogHMD, Log, TEXT("Enabling r.MobileOnChipMSAA, previous value %d"), CVarMobileOnChipMSAA->GetInt());
Can you see this "Enabling r.MobileOnChipMSAA, previous value..." log in your run? 

If yes, and you still don't see MSAA, where the magic really happens is in OpenGLRenderTarget.cpp, line 201, where this is called:
glFramebufferTexture2DMultisampleEXT
instead of this
FOpenGL::FramebufferTexture2D.
Could you verify in which path your renderer goes?

Thanks a lot

View solution in original post

29 REPLIES 29

TuxerLulz
Honored Guest


rpalandri
Expert Protege
Hello!
The forward rendering path for VR is really for PC only, the mobile side has always been forward only.

By default, MSAA should be on when you start GearVR, but issues in the config files might have messed that up. How it works is, if gearvr.EnableMSAA is 1 when the plugin starts, then whatever the value of r.MobileOnChipMSAA is, it will be set as 1 (activated). r.MobileOnChipMSAA is the CVar that actually controls the rendertarget being set as an MSAA rendertarget, which activates the feature.

How we can debug this:
when gearvr.EnableMSAA is set, it will log :
UE_LOG(LogHMD, Log, TEXT("Enabling r.MobileOnChipMSAA, previous value %d"), CVarMobileOnChipMSAA->GetInt());
Can you see this "Enabling r.MobileOnChipMSAA, previous value..." log in your run? 

If yes, and you still don't see MSAA, where the magic really happens is in OpenGLRenderTarget.cpp, line 201, where this is called:
glFramebufferTexture2DMultisampleEXT
instead of this
FOpenGL::FramebufferTexture2D.
Could you verify in which path your renderer goes?

Thanks a lot

motorsep
Rising Star
Could it be that 4.14 is broken for Gear VR ?

4.14.1 is out btw

saldavonschwart
Explorer

rpalandri said:

Hello!
The forward rendering path for VR is really for PC only, the mobile side has always been forward only.

By default, MSAA should be on when you start GearVR, but issues in the config files might have messed that up. How it works is, if gearvr.EnableMSAA is 1 when the plugin starts, then whatever the value of r.MobileOnChipMSAA is, it will be set as 1 (activated). r.MobileOnChipMSAA is the CVar that actually controls the rendertarget being set as an MSAA rendertarget, which activates the feature.

How we can debug this:
when gearvr.EnableMSAA is set, it will log :
UE_LOG(LogHMD, Log, TEXT("Enabling r.MobileOnChipMSAA, previous value %d"), CVarMobileOnChipMSAA->GetInt());
Can you see this "Enabling r.MobileOnChipMSAA, previous value..." log in your run? 

If yes, and you still don't see MSAA, where the magic really happens is in OpenGLRenderTarget.cpp, line 201, where this is called:
glFramebufferTexture2DMultisampleEXT
instead of this
FOpenGL::FramebufferTexture2D.
Could you verify in which path your renderer goes?

Thanks a lot



Thanks a lot for the info. in the meantime I had to switch to another task (saving mp4 files even if on  separate thread freezes the UE game thread and the gearVR IMU stays on, allowing you to see a frozen quad...). But I will try out your test as soon as I can, which will be in a couple days probably. Ill report back when I do.

saldavonschwart
Explorer
@rpalandri


I just did a quick test. BTW, I am new to unreal. So I might need a bit of help here and there...

So first, I assume you meant for me to check the output log via adb. right? If so, yes, when the app starts on the device I get:

12-09 05:18:12.031  5369  5384 D UE4     : ------- EnterVRMode -------, tid = 5384
12-09 05:18:12.031  5369  5384 D UE4     : [2016.12.09-10.18.12:048][-8607492]LogHMD: Enabling r.MobileOnChipMSAA, previous value 0
12-09 05:18:12.031  5369  5384 D UE4     : [2016.12.09-10.18.12:048][-8607492]LogHMD: GearVR has started

But the rendering is completely aliased. So MSAA seems to somehow be off anyway.

Then I searched for the UE_LOG you mentioned. The one that prints the above. It is in GearVR.cpp (and does not seem to be conditionally compiled...).

Last,  I also see the gl multisample fbo attachment at line 201 of OpenGLRenderTarget.cpp. But I don't know how I should check that this line is being hit, since it would run on the device and not the editor in my computer right? I tried sarting the editor from VS (developmentEditor configuration) and then hitting launch from the editor to upload to the device and run. But it didn't hit any breakpoints.

What else should I do?

rpalandri
Expert Protege
Hey!
Sorry you're running into issues with UE4.

So 1), we're seeing that  "[2016.12.09-10.18.12:048][-8607492]LogHMD: Enabling r.MobileOnChipMSAA, previous value 0" is being called, so good! the value should be 1.

To check in which part of the code the engine goes in OpenGLRenderTarget.cpp, you could add a logging line, like : 
UE_LOG(LogTemp, Log, TEXT("Going through MSAA codepath")) in the multisample FBO case, and UE_LOG(LogTemp, Log, TEXT("Going through non-MSAA codepath")) in the other,so that we're sure which path we're going on.

One reason why it would switch off the MSAA codepath is if your driver/device doesn't support the MSAA extension (GLES doesn't support MSAA by default, it's a per-vendor extension that does). When VRAPI starts, it prints out all the supported extensions. Can you verify it contains GL_EXT_multisampled_render_to_texture? Can you also send us your exact model of device, and OS build version? A log of the execution of a UE4 program would also be helpful (containing the VRAPI start, vrmodes, everything 🙂 )

Can you also send us a screenshot of your aliased scene? Although on-device MSAA is definitively helpful, it doesn't remove all the edges.

Thanks a lot

saldavonschwart
Explorer
@rpalandri

The device is:
. Samsung Galaxy S6.
. Software and Baseband version: G920PVPS4CPJ1
. Hardware version: G920P.02
. Model number: SM-G920P
. Android version: 6.0.1
. Kernel version: 3.10.61-8847946

I'm also attaching logs (all, ue output only, vrapi output only).

I see that the UE log is the one that seems to list all device gl extensions. And I do see:
12-09 21:42:27.481  8399  8423 D UE4     : [2016.12.10-02.42.27:488][-8606092]LogRHI:   GL_EXT_multisampled_render_to_texture

Interestingly too, I see that the gles version seems to be 3. I was expecting GLES2 since I do not have v3 checked in the project settings under platform android.

About putting logs in OpenGLRenderTarget.cpp, I guess I need the source code version of the engine right? And recompiling the engine itself?

I am currently running the 4.14.1 version from the Epic launcher.
I tried modifying the file, adding:

UE_LOG(LogTemp, Log, TEXT("------------------------ !!@# : MSAA | 1"));

at line 200. And a similar log for the else branch:

UE_LOG(LogTemp, Log, TEXT("------------------------ !!@# : NO MSAA | 1"));

and hitting compile in the editor but it did not print anything when running on the device.
Also, when I modified the cpp it warned me that it was under version control and had to be made read/write.

About sending you an image of the aliasing I am wondering how could I do this, since the aliasing becomes obvious only when putting on the headset and staring thru the lenses.

rpalandri
Expert Protege
This is gonna sound weird, but are you sure you're not running MSAA? Everything here seems to be pointing towards MSAA being on (which I also replicate on an S6 on 4.14.1). If you send us a screenshot (pressing the home and lock button at the same time), I'll put it in the headset to repro 🙂

MSAA 2x is good, but far form magic, especially if the aliasing doesn't come from the geometry but from the textures (which something like FXAA/SMAA/TAA would solve, but not MSAA)

saldavonschwart
Explorer
@rpalandri

I'll try to get you a screenshot soon.

And yeah, honestly it might just be on. The reason why I think it might not is cause in Unity, a similar scene with MSAA at 4 or 8 definitely makes a difference. My scene is actually made up so far exclusively of an UMG widget. A sort of flat 'card' with some text and an image.

. I see a lot of shimmering in the image, which as you say, would be related to texture filtering and mipmaps. 

. I also see the text shimmering, this I'm not sure how it could be addressed; not sure about Unreal settings related to text since I am new to it. The only thing I've seen so far is the UMG DPI setting but I'm not sure if it is just for metrics when designing the widget or if it has an effect on rendering.

. Finally, the widget's (a square) borders are very jagged. This is what made me think MSAA might be off. I assume the widget is rendered over a quad. If so, the quad is geometry and I would expect MSAA to affect its edges.

Makes sense?