VRDeviceOrientationFreeCamera shows highly aliased output

[dsman]

@RaananW

 

Well, VRDeviceOrientationFreeCamera is really great camera in babylon which takes all pain out of process of adding support of cardboard based VR headgear. 

But there's one issue. The output is highly aliased (or very low resolution ?). And it can't be used for purpose of  visualization. Following screenshot is from my Xiaomi Mi4 device (Adreno 330) with full HD resolution.

 

 

 

I am guessing this camera uses post-process and webGL disables hardware anti-aliasing when any post processed is used ( as per this post  ) .

We tried FXAA . But it had no effect. Could be because of order of post-process pipeline ?  How do we make sure FXAA is after this camera (If at all this camera uses pipeline ) ?

I have seen some games in Android without such aliasing. What could they be using  ? Unity ? 

 

Can one single Scene object's two separate camera render on different canvas ? Can we do such solution to avoid aliasing ?

[GameMonetize]

Can you share your code? It should not be so aliased

[JCPalmer]

Also, make sure you are using 2.4 (probably are).  When using 2.3 and a 3D rig, post processes other than the rigs would not work.  Camera rig post processes are last.

[dsman]

@JCPalmer   We are using 2.4 . I didn't understand about 3Drig stuff. But I am guessing what you are saying is VRcamera will be last post processes and hence FXAA post process wouldn't apply to it ? Does this mean it is confirmed that VRcamera uses post-process and hence there's aliasing ?

 

@Deltakosh  I will prepare PG. And send link. 

 

But for more information,

1. We are using lots of texture/material channels . Like Baked AO on AmbientTexture, baked lightmap on SpecularTexture (No channel of Maya is mapping to Lightmap channel of babylon so we used Specualr instead ) . But not all objects have all channels. Not sure if this should affect it. 

2. We are using mirror at 2-3 many places. Not sure if this should affect it. 

3. We are using a shader I found on babylon website somewhere for shiny Steel metal effect. 

4. We are using 3 lights. Two directional that follows camera and one hemispheric.

5. Many of the meshes have some level of EmmissiveColor .  

 

Some clues: 

1. Could it be related to any ratio or anything ? Depth pass ? We played with Depth pass earlier for live SSAO performance. 

 

PS: When using normal ArcRotate camera , the scene looks very highly anti-aliased and smooth on same device. Screenshot from same device, same resolution. 

 

[JCPalmer]

All the 3D cameras are implemented using post processes.  3D Cameras (anaglyph, stereoscopic, & VR) all have 2 sub-cameras, which render the 2 views.  The rig post process merges the 2 sub cameras accordingly.

Any Post processes on the main camera were flat out ignored when you added them to a 3D camera in 2.3.  In 2.4, any post processes on the main camera are run on each sub-camera.  Then the rig postprocess(es) compose the final output.  I tested with Black & white on all 3D cameras.  As I look down the list, most post processes could run before or after(provided it is not ignored) the rig's post processes.  I think some would cause problems after (volumetric light scatterring, or hdr rendering).  fxaa may be an edge case which only works after.  If that is the case, you might change camera for 2.5 to indicate which have to run after.  I cleaned up adding & removing post processes a lot for 2.4, but people an add and remove post processes in any order, so trying coordinate with the 3D rig post processes could be treacherous.

[dsman]

Ok.  I think I understand it now. Concept of camera rig ( two subcamera for anaglyph, sterioscopic & VR ).  If I am not wrong, you mean to say that we have to edit VRDeviceOrientationFreeCamera to ensure FXAA runs after its own post-process and send pull request for 2.5 ?

[JCPalmer]

Actually, the file that needs to change is Camera.ts.  3D rigs are designed to be independent of the actual input that causes them to move( accelerometer, gamepad, mouse, touch, etc).  Inside of camera, you need to make sure that the last post process comprising a rig gets marked as intermediate, or if the fxaa is after it, you'll never see it.

Think any post process which needs to be run very late, should perhaps be indicated using a specific method on camera rather than attachPostProcess().  Wouldn't technically be a breaking change.  If you did not have a rig would still work.  With a rig, fxaa actually changes the rig processes themselves.

[GameMonetize]

Do you have the same result with this scene: http://leblon-delienne.com/ ?

[dsman]

@Deltakosh  I checked the Leblon Delienne app . It doesn't look aliased. Screenshot below is taken from same device. Actually in the live rendering it looks more anti-aliased than in snapshot (That's expected I think ) 

 

 

But was this app done in babylon ?

 

[dsman]

Its only happening on mobiles. On larger screens it looks good without or without fxaa. The aliasing effect is even there when using chrome tools to emulate screen sizes. So its resolution dependent.

[GameMonetize]

The demo uses Babylonjs and VRDeviceCamera. So there is something different in your code

@Temechondid the demo

[Temechon]

The application is made with Unity

[dsman]

  @Temechon is there web version of Leblon delienne ? I checked Android app. And screenshots above are from android app. If there's web version. Please provide link. I will check in my phone. 

@Deltakosh On PC monitor the output is smooth. It's just happens with mobile (And chrome dev tools mobile screen preview ) . So it is something related to resolution and pixel ratio. 

I understood from somewhere or someone that the rendering on mobile device is always scaled. So even if mobile is full HD, babylon wouldn't be computing all 1920x 1080 pixels but it would be doing for fraction of it and then scaling it. Could it be somethng related to it ? 

[GameMonetize]

You can control it with sethardwareScalingLevel (0.5 will generate a rendering buffer twice bigger than your screen).

http://www.babylonjs-playground.com/#2HDJQT#0

 

You can use the statistics window of DebugLayer to get the current rendering resolution