Supporting A-Frame 1.6.0 and newer versions of three

[nickw1]

Do you want to request a feature or report a bug?

Bug. Haven't had much time for AR.js of late, and unlikely to have much time in the near future, but using a few days' break in my schedule to investigate a few things that are perhaps easily fixed.

What is the current behavior?

AR.js 3.4.5 does not support A-Frame 1.6.0 or latest versions of three.js e.g. 0.164.0.

If the current behavior is a bug, please provide the steps to reproduce.

Modify A-Frame dependency to 1.6.0 when building.

Please mention other relevant information such as the browser version, Operating System and Device Name

What is the expected behavior?

Should work, but location-based examples fail with:
PlaneBufferGeometry is not a constructor.

This is easily fixed; use PlaneGeometry instead, e.g. see: https://stackoverflow.com/questions/77130600/error-three-planebuffergeometry-is-not-a-constructor

When this is fixed, the new-location-based A-Frame examples work.

If this is a feature request, what is motivation or use case for changing the behavior?

Able to support latest A-Frame.

@kalwalt not sure if you have any time to spend on AR.js these days (no worries if not... I don't have much time either, sadly!) but can you foresee any problems with upgrading A-Frame to 1.6.0 (and three to 0.164.0) on the marker and NFT side? Location-based side seems to work with the fix above.

Also wondering whether we need to include three as a dependency in package.json given it's already a dependency of A-Frame (see #504)

[kalwalt]

@nickw1 sadly I have no time to look into this. Did you try upgrading three.js also to the latest? I think it is not compatible with AR.js at this time. We should check upgrading three.js dependencies before upgrading A.frame? What do you think?

[nickw1]

@kalwalt makes sense, yes. I'm not familiar with the marker-based/NFT side of things though, so all I can really do is test the location-based side (which seems to work if the above fix is applied).

In fact (as I messaged you a while back) I'm thinking of separating out the location-based AR into its own project within the AR.js organisation. I feel that this will result in faster bugfixes and improved compatibility with latest three or A-Frame as I will be able to do this without worrying about marker-based or NFT. Any thoughts?

[nickw1]

Update for anyone reading this: there's now a new standalone location-based project here:

https://github.com/AR-js-org/locar.js

which aims (amongst other things) to keep up to date with latest versions of three.js.

[kalwalt]

Great @nickw1! i will try to upgrade A-frame and three.js in the main repository too, i have more time now.

[nickw1]

@kalwalt just an update: I have made live LocAR.js examples (only two so far) available via GitHub Pages https://ar-js-org.github.io/. A while ago I think you mentioned the idea of making more examples available live, do we want to add some for other parts of AR.js?

[kalwalt]

@kalwalt just an update: I have made live LocAR.js examples (only two so far) available via GitHub Pages https://ar-js-org.github.io/. A while ago I think you mentioned the idea of making more examples available live, do we want to add some for other parts of AR.js?

Nice job @nickw1! maybe we can think in a near future to buy a web domain and have a simple web page of the github organization.
As we talked in the past we should have more live examples, we can start with the simple pattern markers and so continue with the others.

[kalwalt]

In regards of this issue i will start to upgrade AR.js to a more recent three.js version, I will start this week with a draft PR.

[nickw1]

@kalwalt Thanks! Sounds good.

[kalwalt]

Im working on this issue in draft PR #615. As mentioned in the PR it seems that it solves the issue #504 about the multiple Three.js instances. I think we need a .module version for all the build libs...