Is this project still active?

[bydesign]

So I encountered this bug on a project I'm trying to do:
#335

I'm wondering if this project is still actively maintained anymore.

• There are Stack Overflow questions that have gone unanswered for a long time
• The above issue report has no answers in the last 12 days
• Project has 139 open issues with only 109 closed
• No code commits in the last 5 months
• There are pull requests with no movement in over a year
• Most github discussions are marked as "Unanswered"
• The documentation has old and inconsistent examples

This looks like a really cool and exciting project and it has huge potential. If there's a way for people to get more involved to help with these things please reach out.

[nickw1]

Hi,

I am one of the developers of AR.js though have only joined the project relatively recently and have only made relatively small contributions: @nicolocarpignoli (who I know has had little time recently) and @kalwalt have done more work on the project.

Unfortunately all of us have had little time in recent months and I have hit a stumbling block with the problem encountered in #335 : it seems to be a commonly-encountered problem but is not easily reproducible.

Could I get you to try this: https://hikar.org/265/ ?
This is a basic example which "ought to" work and definitely works on some devices: it gets your GPS location and draws two boxes a short distance to your north, wherever you are on the earth. If you still get the "sticking" effect with this example, then it is a bug in AR.js.

I'll try and have a look at the codepen to see if it should work, though it is @nicolocarpignoli's work not my own. I'm not sure how up to date it is.

We would very much welcome contributors on the location-based side, particularly if you have experience with A-Frame and the device orientation API. The persistent problems are this "sticking" issue and an inability to get accurate device orientation on Firefox (which seems to be a limitation of Firefox unfortunately as it doesn't seem to have an API to get absolute orientation; see #302)

So feel free to look at the code and either suggest issues or submit a PR. The more people we have looking at this the sooner the bugs will be resolved!

[hiukim]

May I make a bold suggestion? Will you guys consider deprecating this project and join force with me here: https://github.com/hiukim/mind-ar-js

I really appreciate all the hard work of all people behind ar.js and before that, artoolkit. It also helped me a lot back in the days.

I think there is a fundamental issue to hinder this project from going forward, which is also probably the reason why it has almost no progress for at least a year or two. The core AR engine is compiled from artoolkit which is C based. The code is extremely difficult to understand especially for web developers who proficient in javascript. I'm telling this from my first hand experience, because I actually took at least 300 hours to go through the codebase line by line. ARtoolkit is apparently not maintained anymore, so there is almost no way to fundamentally improve AR.js

I do believe the community need an open source solution for web AR. I would really like to push it forward with the help of you guys. A maintainable codebase is fundamental for contributions. I've been working on a new version of MindAR and will be released soon. The AR tracking has been greatly improved and there will also be a face tracking feature.

If you guys are open to this suggestion, I would try to write up some migration guide to help people move from AR.js. We can also work on adding the location based AR so there won't be anything missing.

Let me know what you think. @nickw1 @kalwalt @nicolocarpignoli

[nicolocarpignoli]

Hi @hiukim and nice to meet you!
What you are saying is basically correct. Artoolkit (and its JS porting) are very hard to be understood, and apart from that, marker-based and nft technologies are probably "stuck" from a performance p.o.v. That means, we are not relying on technologies that are working in progress or are becoming better with time, but we are "just" encapsulating them and making them more accessible from the Web. I understand this.
It is also true that we have a poor time working on AR.js. Personally, I do not have time to work on your project too.
But I don't see any good reason to deprecate AR.js. Why can't we just have both mind-ar-js and AR.js? They are different, they support different AR types, they are based on different technologies.
They both have reason to exist at the same time, at least for now.

If you need help with a Call to Arms for your project or a sponsor on our Documentation/Readme we can do that, no problems. But, again, I see no point in "deprecate AR.js and join force on mind-ar-js".
Of course, this means that if anyone wants to help you (@nickw1 or @kalwalt or anyone from Github :) ) it is totally fine for me - of course.

What I'd like to say is: AR.js is currently, with its limits, the most known OSS Web AR library around. If mind-ar-js is (or will be) better, more updated, more maintainable than AR.js, I still will see no point in deprecating AR.js until users will have an interest in using it.

Let's keep the OSS Web AR open and let's add more important projects rather than having one, single solution for the user. I'm very excited to try out your library and very happy that we are not alone in the Web AR ecosystem. :)

[hiukim]

@nicolocarpignoli Thanks for your reply. And nice meeting you! :)

First of all, I hope you guys don’t get the wrong idea. I’m just trying to initiate a discussion on how we can move forward in the opensource web AR. Would really love to hear everyone thoughts.

I can try to elaborate on what I meant. By deprecating, it doesn’t mean the project will be removed from GitHub. It merely gives a signal that the project is not being actively developed anymore and maintenance support will be very limited. This is my observation or maybe some others. Again, please don’t get the wrong idea. This is not to blame anyone. I totally understand that people move on from projects to projects. It’s my bad if my observation is wrong.

I did work on artoolkit before trying to improve the engine. In fact, that’s how I started MindAR. I rewrote the whole artoolkit C code in javascript and that’s the base of MindAR. I made a lot of improvement after that. The technologies behind aren’t that different. In fact the API (e.g. aframe wrapper) is similar. If I (or we) can add location base AR to it, it would cover most functionalities of AR.js, and It could be a good successor. I pointed out the issue behind AR.js is because I think that could be the reason to stop it from moving forward in recent years, and I’m trying to propose a solution to that. With a more maintainable codebase, we could attract more contributions and push the opensource community forward.

I need to admit that I can’t do it alone, and the community support is very important. As you mentioned, if you could simply do a Call to Arms that would means a lot to me. AR.js is definitely the most well known Web AR library, no doubt with that. and you guys are probably the most influential persons on the opensource web AR as well. That’s why I’m reaching out to see if we can join force.

Anyway, that’s just my thought. It’s mostly based on the assumption that you guys are too busy with other work, and don’t have time and plan on AR.js anymore. In that case, this could be a way to continue and make use of the community. I have no intention to argue, and you don’t have to convince me on that. Whatever it is, I respect that :)

[nickw1]

Hi @hiukim @nicolocarpignoli - I would largely go along with what @nicolocarpignoli says here, AR.js is a well-known project and is still worth developing and maintaining. MindAR can still be developed alongside as an alternative - it is always good to have many alternative libraries as they all have their own strong points and some might be particularly appropriate to certain use cases.

I cannot help much on the marker/NFT based code, as thatis not my area. I have only contributed to the location-based code and it is likely to remain that way.

However, my inclination (and @nicolocarpignoli please raise any objections!) is to re-write the location-based code from scratch to see if this resolves the long-standing problems such as #335. I am more likely to be able to fix bugs quickly that way. Furthermore I am inclined to offer both A-Frame and three.js interfaces as both have been requested, and to make the location-based code completely independent from the remainder of AR.js.

Doing this is likely to increase my activity on the project in the coming months as I will know the code more intimately and will be able to resolve problems more quickly.

[nicolocarpignoli]

I might propose this @nickw1: instead of rewrite location-based for AR.js, you could see what means to rewrite it on mind-ar-js. Maybe It is portable on both projects, with little differences.

If I had to choose, I would rewrite it for a "new" project with a full JS codebase, so mind-ar-js. What do you think? Stop me if you think it's too much work - but I think no, as you will probably use poor AR.js basics (or none at all).

[hiukim]

@nickw1 thx for your feedback!

I agree that AR.js is the most well known project and I'd definitely love to see more available libraries. I also appreciate all the people who spent effort to develop and maintain AR.js. However, It's only based on my and maybe other peoples observations that the development and maintenance has stopped. Again, please don't take the wrong idea. It's not to blame anyone. It's an open source project, you can't expect other people to work for you for free. All I'm saying is that I might have figured out the issues that hinder the development, and I'm suggesting a solution that could get the community going forward again. I'm talking about the development of the opensource web AR instead of specifically AR.js though.

Actually I think you somewhat arrived at a similar conclusion with me when I started mindar :) I tried to improve the image tracking and then rewrite everything from scratch. You have the same intention with the location based AR. That's exactly what I meant. You are going to rewrite the code and make it more maintainable so hopefully you and more people can then contribute and keep it going.

If you ask me, if you are rewriting anything from scratch, you might as well start it brand new rather than sticking with the original AR.js. Maybe you can call it AR.js v2 so you don't have the burder of making it perfectly backward compatible. It could save you a lot of time fixing old applications. In that case, you are "deprecating AR.js" and work on AR.js 2, which is more or less what I'm suggesting in the first place. It's not a very unusual thing to rewrite something from time to time and create new version.

Anyway, that's just my opinion. If you guys want to keep working on AR.js, I respect that. :)

[nickw1]

@nicolocarpignoli sounds a good idea: one idea would be write reusable A-Frame components and three.js plugin/extension which could be used both in AR.js and mind-ar-js - does that make any sense?

I haven't looked at the mind-ar-js codebase yet so not sure how feasible this is in practice.

[kalwalt]

Hi to all here! Is this project still active? I think yes, but we have our time, we are not payed for doing this, not sponsored by any Big company or corporation or institutions. Personally i am not a professional developer, i have my job not related to OSS or other coding activity, and these last few months was a very intense period for me, i had zero free time. I do for my personal interest and because i like to collaborate in OSS project. So if you want you can help directly to improve the project. Ar.js now is a github organization you can join it and help us in many ways: solving some issues or directly in the code See the open PR's. I know that reading the AR.js code can be somehow difficult and obscure, because rely on jsartoolkit5 that is the emscripten port of Artoolkit5, but for example the PR #116 that will add the ES6 support is a long time there, because i haven't time to solve the issue with Aframe. I would really love that this feature will become a reality, i hope that in this next month i will have the necessary time to reach this goal.

[hiukim]

@kalwalt I totally agree with what you said! I'd never blame anyone for not working on it. I appreciate the work of any contributors very much. It's an opensource project, anyone can step up. In fact, I executed this first hand. I went all the way down the artoolkit, fix things and improve things. Now I do have a better version which is more maintainable. It can indeed solve a lot of issues in AR.js, including ES6 support. However, my personal judgement is that making modifications on top of the existing AR.js codebase is just not the best way.

While it's true that everyone can contribute, but in reality there are objective factors that could affect the quality and quantity of contributions. I could list a few: 1) more maintainable codebase, 2) having someone who understand the codebase to review PRs, 3) having someone actively involved in coordinating the development of new features, 4) project being well known, good reputations and have influential personnels. etc. etc.

Again, all I"m saying is that I saw the issues that could hinder the progress of development, and I'm suggesting a way that we can move forward. And again, if you want to keep working on AR.js, I respect that. :)

[JamesBotterill]

I feel that coming in with a slight different perspective, we need to be honest about the state of the project as it is to day and by all objective standards it's dormant, it still works and is usable so dead is the wrong word to use.

But with no active commits or development occurring in months and a major issues which impact the ability to use image markers since day one (#114) has been inactive since November 2020.

This is no way meant or intended as a slight on @nicolocarpignoli or @kalwalt who have previously worked tirelessly to improve AR.JS massively from a place it was in a few years back, we need to be honest on how much they can contribute today and moving forward.

[nicolocarpignoli]

Honestly, I just do not have time to manage this project.
Saying this, I'm totally fine with (almost) any way you guys are proposing to push forward new features and maintain AR.js.
It's now owned by an OSS Github Org. so it has not to be my decision. I'm okay with anything that keeps AR.js alive.

If someone needs access to the repo to do something and it's blocked by this, please let me know.
If the question is: "should we deprecate AR.js and support another free library?" I would say the same thing as above: do not deprecate, but maybe merge the two. If that's not possible, and any developers think that another library is more maintainable and looks more promising for the future, please support that and work on that. While keeping AR.js where it is.

I know this is not very useful "practically" but I just wanted to state my "position": If anyone thinks that there is some kind of block by me from changing things in AR.js or moving all the development to another library, that's not as it is :)

So, okay, we agree on the stale of this project. Now, what's the move?
Your choice.
My idea is: let's give a try to mind ar js (as I proposed, new features by @nickw1 on location-based might be ported on that project rather than on AR.js).
While keeping AR.js where it is, as it is. And then we will see in the future.

[nicolocarpignoli]

This is mostly a "decision" that @kalwalt @nickw1 or others that are actively working on AR.js have to do.
I'm no longer active on this and will not be in the future, so my position is only "strategic" and I can only give some suggestions. But again, not decisions.

[nickw1]

Thinking about it, my preferred approach is to write a new A-Frame component for location-based from scratch (as I will be better able to maintain it, and @nicolocarpignoli has limited time at the moment) but to add it to the AR.js dev branch as an experimental feature. Then people can test it and see if it irons out the problems people are still having. Having worked on AR.js from time to time during 2020 I don't really want to abandon the project, as such.

I think now also would be a good time to merge my pure three.js location-based code into dev, and update it (e.g. some bugs with the THREE.DeviceOrientationControls add-on have been fixed recently, I believe). @kalwalt I know last time we spoke about this you wanted to finish the ES6 work, but again my inclination is to add it straight into dev as an experimental feature, along with the new A-Frame component. Any objections to this?

[kalwalt]

@nickw1 i will reply you this evening, thank you!

[kalwalt]

but again my inclination is to add it straight into dev as an experimental feature, along with the new A-Frame component. Any objections to this?

Hi @nickw1 are you refering to merge the ES6 into dev or merge the three.js location-based code into dev?

[nickw1]

Hi @kalwalt just the three.js location-based code; I don't think the ES6 is ready yet?

[kalwalt]

OK, that's clear. Yes ES6 feature is not ready and if threejs location-based code is ready why not merge on dev branch? 🙂

[nickw1]

@kalwalt it is ready yes, could do with some improvements but is working. Thanks!