Skip to content

Plan to develop a core package for AR.js #2

@kalwalt

Description

@kalwalt

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

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationenhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions