hardcoded paths on ar.js library

[albjeremias]

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

What is the current behavior? When setting up a simple example with AR.js some files fail to load if not connected to the internet.

/examples/marker-training/examples/pattern-files/pattern-hiro.patt /data/data/camera_para.dat

If the current behavior is a bug, please provide the steps to reproduce. Use this line of code after aframe-ar-min.js is loaded

    <script>
        THREEx.ArToolkitContext.baseURL = './';
    </script>

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

What is the expected behavior? I expect that instead of using THREEx.ArToolkitContext.baseURL there is another way to configure the correct path of a pattern and of the camera parameters.

Extra On all the examples the aframe-ar library, gltf, patterns and images are not from the current developing branch but instead from a remote source... I guess this is for ease of use by end-users, but its quite "ugly" for a developer.

Possible solution Anyway I could come up with a pull request, but I could not find a middle term way that is easy for end-users and not "ugly" for developers.

[kalwalt]

@albjeremias I understand your point, sometimes is very difficult ot sort out with the path issues. It all ok when you work on localhost or all your resources are in the same host, the problems come out when you want serve with codepen or other similar services. One soultion to avoid these problems, might be configure all those path settings in an external configuration file, maybe in .json format or .yaml, so everyone can make his config file and everyone is happy. I would know also what other developers think about this, maybe someone else has a better idea.

[kalwalt]

Also would be nice to embedd the presets Hiro and Kanji pattern inside the library itself, i think would solve a lot of troubles.

[albjeremias]

you answer about a .json file.. remmembers me of package.json and how the https://github.com/AR-js-org/AR.js/pull/86 is already going on this direction!

I think the issue is that AR.js needs a big refactor so that is more modular... because how do you known which aframe version number you are running? Or which jsartoolkit5 version number is it really using? It's a bit messy.. :) so a patch like that would probably only make it more visible this issue, but it's not a solution

[kalwalt]

I think the issue is that AR.js needs a big refactor so that is more modular... because how do you known which aframe version number you are running? Or which jsartoolkit5 version number is it really using? It's a bit messy.. :) so a patch like that would probably only make it more visible this issue, but it's not a solution

Yes absolutely, we need to find a better solution, I want to know also other opinion.

[albjeremias]

here are very much more friendly examples using threex.js https://github.com/stemkoski/AR-Examples would it be worth it to refactor the examples in here to something more similar?

[HighLifeHighland]

See also: https://github.com/jeromeetienne/AR.js/pull/549/ in previous repo which modified this behaviour.