AR.js: [location-based]: near and far clip planes not working as expected
Do you want to request a feature or report a bug? Possible bug.
What is the current behavior?
An a-camera is created with the far clipping plane set to 5000 WebGL units (metres), and the near plane set to 0.1 units. Objects seem to always disappear when you move around 500-1000 units away from them - no matter what the value of the far clipping plane is.
If the current behavior is a bug, please provide the steps to reproduce.
See example at
https://hikar.org/webapp/test/clipPlane.html
WASD-controls are enabled so you can move around the scene. By default you look north, you can see an a-text 0.5km (500 units) north (towards -z) from the origin. You should also be able to see another a-text 1km (1000 units) north of the origin, due to the far clipping plane value of 5000, however it only comes into view if you move ‘north’ for a short distance (press W).
These are simple a-texts with position set using the position attribute. The same behaviour occurs if gps-entity-places with latitude and longitude are used. Also, the same behaviour occurs with either gps-camera or gps-projected-camera.
Possibly related to #52? However I do set the logarithmicDepthBuffer to true as suggested.
(Same behaviour occurs with polylines - roads and paths - in my Hikar webapp demo: https://hikar.org/webapp/?lat=51.049&lon=-0.723, z-flghting type flickering and polylines beyond 0.5km - 1km or so cannot be seen)
Please mention other relevant information such as the browser version, Operating System and Device Name Browser: Firefox 75.0 or Chrome 81.0 on Ubuntu 18.04 (same behaviour).
What is the expected behavior?
I would expect to see the a-text 1km north.
If this is a feature request, what is motivation or use case for changing the behavior?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 23 (6 by maintainers)
Commits related to this issue
- Merge pull request #119 from nickw1/dev Partial fix of #110 (distant augmented data not visible even if within the viewing frustum) — committed to AR-js-org/AR.js by nicolocarpignoli 4 years ago
To follow up, I have just had a quick look through the source to try and find the webcam code – it’s triggered from ARjs.Source._initSourceWebcam() in three.js/src/threex/threex-artoolkitsource.js. This looks like it simply renders a camera feed onto the screen; it doesn’t try to use WebGL to render the feed.
It looks also like an alternative approach, rendering the webcam into a WebGL texture, has been attempted but is never actually called: see ./three.js/src/threex/threex-arvideoinwebgl.js; there’s an ArVideoInWebgl() method which takes a WebGL texture as a parameter.
I am wondering if this is the best approach to take? In other words, stream the camera feed into a WebGL texture, draw two unprojected triangles covering the whole of the screen, and texture them using the texture containing the camera feed. This is the recommended approach in an Android OpenGL ES environment, and is the approach I’ve taken in my (Android) Hikar app. It works fine without any z-fighting issues or unexpected invisibility. Not sure how easy it is to do this in JavaScript but I will take a look; I’d imagine three.js and/or A-Frame might make this fairly easy to do?
EDIT:
https://github.com/willwnekowicz/aframe-passthrough
or
https://github.com/sachaa/aframe-webcam-component could be starting points, though neither have been updated in a while.
I am quite happy to work on fixing this assuming I have time.