Aframe: Aliasing issue in latest A-frame 0.7.0 while viewing 3D model in VR mode

Created on 25 Jan 2018  路  8Comments  路  Source: aframevr/aframe

So, I downloaded a gltf model from sketchfab and put it on different versions of A-frame, Here are my observations -

On A-frame version 0.5.0, the model looks good. There is minor aliasing issue in the edges but it is negligible.
Link - http://aframe5gltf.surge.sh/

On A-frame version 0.7.0 which is the latest, There is a lot of aliasing and it looks very bad in VR.
Link - http://aframe07gltf.surge.sh/

Interestingly if viewed in Sketchfab viewer in VR mode, the model looks perfect, not even minor aliasing.
Link - https://sketchfab.com/models/192bf30a7e28425ab385aef19769d4b0

Please do watch in a VR headset to clearly observe the issue. I hope to get this solved with your help.

  • A-Frame Version: 0.7
  • Platform / Device: Samsung S8 / Daydream VR headset / Chrome browser
  • Reproducible Code Snippet or URL: Given above

Most helpful comment

I think i've found a solution to this problem...
After manually setting antialias="true" in a-scene, there still appears to be some rough edges on the shapes.
It appears that after turning VR-mode on and off again, the pixel ratio has changed in the renderer of the scene (WebGLRenderer.getPixelRatio()).
This is why this problem only appears to be on mobile devices where the device pixel ratio is higher than 1.

A manual fix (that worked for me) would be:

  • Add an eventlistener to the scene for when you exit VR-mode
  • Set the renderers pixel ratio to the correct pixel ratio: document.querySelector('a-scene').renderer.setPixelRatio( window.devicePixelRatio );

I hope this fix will be implemented soon.

All 8 comments

Note that antialiasing is a setting you can control, have you tried putting antialias="true" on the scene?

see also https://github.com/aframevr/aframe/issues/2666, i'm not sure where/if it is documented how antialiasing behaves by default.

Also I suggest checking the model against a "just threejs" viewer like https://github.com/aframevr/aframe/issues/2666, as Sketchfab's viewer is highly customized and will not necessarily match our results.

There are also some z-fighting artifacts in all versions, but those are part of the model itself.

Yes, I've tried that as well. No luck. The model still looks bad in VR on latest version while it looks fine on 0.5.0. With or without the setting.

We prioritize performance over visual fidelity. That鈥檚 why antialiasing is disabled by default. Sketchfab is a single model viewer with limited interactivity so they can make different choices.

I try to force antialias with <a-scene antialias="true /> in VR (GEAR - samsung S7) antialias is disabled. No way to force it ?

antialias="true" does force it, you may be seeing just low resolution for other reasons? see https://github.com/immersive-web/webvr-polyfill/issues/273 and https://github.com/immersive-web/cardboard-vr-display/issues/7 ...there are some issues on Samsung phones, manually setting resolution in phone settings may help.

Appear alias after exit VR mode

568d48da-bbae-4e1c-8fdb-b29c1368ad21

Enter VR mode, edges are perfect

74fe7c03-091f-4e62-ac98-7325544d1156
290c16cb-0755-47f0-821f-91b8719f423f

Before enter VR mode, edges are perfect

On A-Frame home page, When I turn back from VR mode, the aliases appears on the edges of shapes. Why that happened?

I think i've found a solution to this problem...
After manually setting antialias="true" in a-scene, there still appears to be some rough edges on the shapes.
It appears that after turning VR-mode on and off again, the pixel ratio has changed in the renderer of the scene (WebGLRenderer.getPixelRatio()).
This is why this problem only appears to be on mobile devices where the device pixel ratio is higher than 1.

A manual fix (that worked for me) would be:

  • Add an eventlistener to the scene for when you exit VR-mode
  • Set the renderers pixel ratio to the correct pixel ratio: document.querySelector('a-scene').renderer.setPixelRatio( window.devicePixelRatio );

I hope this fix will be implemented soon.

Was this page helpful?
0 / 5 - 0 ratings