You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will continue the discussion started in this PR AR-js-org/AR.js#615 about the future of AR.js and its development. I will try to summarize the concept and the idea behind this proposed package, and the motivation for a new package as AR.js-core. Below, I will trace some important points of the design I have in mind. I want to underline that everything can be discussed and everyone can express their ideas; any help is very appreciated. I will improve and extend these descriptions in the days to come.
Project Modularity
Probably, as you know, AR.js is divided into two parts: code based on Three.js (Threex and AR.js) namespaces and A-frame, which in part depends on these two. It would be a good idea to create separate modules (for Aframe and Three.js code) and develop a common code root. In this sense, ARjs-core comes into play.
More Flexibility and Improvements in Code Design
Developing separate modules will increase flexibility and also improve the code design. I have already started this process with the AR.js-threejs project, which is entirely developed with the TypeScript language.
In specific convert the code to a more recent ES standard (ES14 ?).
Three.js Import Issue
The code in the threex module imports the Three.js library. This is correct for ar-threex.js, but when imported in aframe-ar.js, it causes a multiple Three.js instance import issue. This happens because both threex and aframe-ar.js import their own instances of Three.js, leading to conflicts and unexpected behavior. To resolve this, we need to ensure that only one instance of Three.js is used across the entire project.
You can find more informations in this Aframe article for creating a box component with Three.js you will see that it's not necessary to import Three.js because Aframe has its own Three.js.
Future Plans for Modularity
In the future, we could consider separating the Three.js and even ARToolKit code to make AR.js more flexible. By decoupling these dependencies, we can create a more modular architecture that allows developers to choose and integrate only the components they need. This would enhance the adaptability of AR.js to different use cases and potentially reduce the overall size of the library.
The text was updated successfully, but these errors were encountered:
Introduction
I will continue the discussion started in this PR AR-js-org/AR.js#615 about the future of AR.js and its development. I will try to summarize the concept and the idea behind this proposed package, and the motivation for a new package as AR.js-core. Below, I will trace some important points of the design I have in mind. I want to underline that everything can be discussed and everyone can express their ideas; any help is very appreciated. I will improve and extend these descriptions in the days to come.
Project Modularity
Probably, as you know, AR.js is divided into two parts: code based on Three.js (Threex and AR.js) namespaces and A-frame, which in part depends on these two. It would be a good idea to create separate modules (for Aframe and Three.js code) and develop a common code root. In this sense, ARjs-core comes into play.
More Flexibility and Improvements in Code Design
Developing separate modules will increase flexibility and also improve the code design. I have already started this process with the AR.js-threejs project, which is entirely developed with the TypeScript language.
In specific convert the code to a more recent ES standard (ES14 ?).
Three.js Import Issue
The code in the
threex
module imports the Three.js library. This is correct forar-threex.js
, but when imported inaframe-ar.js
, it causes amultiple Three.js instance import issue
. This happens because boththreex
andaframe-ar.js
import their own instances of Three.js, leading to conflicts and unexpected behavior. To resolve this, we need to ensure that only one instance of Three.js is used across the entire project.You can find more informations in this Aframe article for creating a box component with Three.js you will see that it's not necessary to import Three.js because Aframe has its own Three.js.
Future Plans for Modularity
In the future, we could consider separating the Three.js and even ARToolKit code to make AR.js more flexible. By decoupling these dependencies, we can create a more modular architecture that allows developers to choose and integrate only the components they need. This would enhance the adaptability of AR.js to different use cases and potentially reduce the overall size of the library.
The text was updated successfully, but these errors were encountered: