Last minute issues with the AR markers is not fun. Essentially what works on my own laptop at home does not work in college. After some trial and error I’ve realised this is due to the different lighting systems, camera clarity and our AR codes. We’re in a weird position where AR codes we make are too detailed and when we scan them in online (http://flash.tarotaro.org/blog/2008/12/14/artoolkit-marker-generator-online-released/) to make our .pat files what we get back is a file that is essentially instructing the AR code that any patch of black is our AR code. This happened before but I believed I had fixed the problem, I now realise that this is just something that seems to happen on the college computers
Unfortunately these are the computers we’ll be doing the presentation on. I spent most of today trying to sort our AR problem and I think I have it sorted now. Unfortunately we’ve had to revert back to the AR codes that came with the sample demo as these are clear and distinct enough to be seen as separate markers by the AR code.
It’s a weird problem to be having this late but sort of understandable. It’s really hard to implement AR code as it will have very different results depending on the conditions. Poor lighting or a bad webcam can stop it working entirely. This is something I noticed a few weeks ago when I found out Kinder are currently using AR codes with many of their Kinder Eggs (http://www.magic-kinder.com/mk/lang/fr_FR/index.htm). However, when I tried to view these AR codes the camera simply wouldn’t recognise them. So if Kinder can’t get it working 100% then I don’t feel too bad.
I feel like this will be less of a n issue if it’s implemented in the museum. The AR section of the website is not really intended to be viewed outside the museum and instead will be running on a desktop in the museum. We’d be able to tailor our .pat files and markers for that environment.
Recent Comments