Jump to content

VRDeviceOrientationFreeCamera shows highly aliased output


Recommended Posts



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 ?

Link to comment
Share on other sites

@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. 


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  @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 ? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...