jMonkeyEngine.org

Hello! I have mainly done porting the ARMokeyKit to jME3. But there are several problems that I cannot solve.

If you want to have the project, here is the archive with my test project and the lib: [url=http://www.fileserve.com/file/qW4GpN4/AR.rar][b]File name: AR.rar File size: 13.17 MB[/b][/url]

This is the link for the WinVDIG middleware that allows QTJava to work with camera: http://www.vdig.com/WinVDIG/WinVDIG_101.exe there are greater versions but they did not work for me. If all is fine the QTCap application that is installed with WinVDIG should not show any error (although it does not either show any image from the cam %/ )

Also be sure to have C:Program FilesJavajre6libextQTJava.jar in your project dependencies. I think my project setup does it but your path might be different.

The Hiro and Kanji markers pdfs are in the ardata folder inside the project, you should print them to work with the app.

The ARTest.jave should be run as the project’s main class.

The questions are:

1) After I run the project and then close it via closing the window, some thread is apparently still running in the background and I have to manually press the ‘Stop’ button in the jME SDK Netbeans shell. Otherwise the previously run applications keep the camera busy and the error message about that comes up. It is pretty annoying to keep closing application via the STOP button instead of just closing it’s window. How can I fix it? Maybe add some shutdown hooks? What is the correct way with jME3?

2) The marker is tracked very loosely. Most of the time is is not tracked at all or the software often loses it and positions incorrectly. It also does not catch it all the times it should. The guys on the youtube videos have a better performance. The behavior changes if I toggle the matrix smoothing on/off on the line 54 of the ARTest.java but it is strange!

3) The software sometimes misinterprets Kanji for Hiro and vice versa!!! This is totally unacceptable.

If anyone has any suggestions on how to fix these problems, It would be nice to hear..

In the place where you generate the texture, you have to call buffer.clear() at the end so that the number of remaining elements is reset

@atomix: The porting is complete, I have also incorporated the fix for the error, proposed by Momoko_Fan, it seems ok, but I did not do any extensive testing.

I have a complete prefab project that is ready for building any applications that require augmented reality with JMonkeyEngine. The preset main class is available in Java as well as in Scala. It is in one prefab project. As a side note – in order to work with Scala I had to fall back to Eclipse.. but source files do not care for IDE right?))) Anyway, the original project in JME3 SDK (NetBeans) is also available though without Scala support. Both projects include a simple example app.

I can share it with the community if you want for any free use you want, just tell me where to upload or something. My assignment on AR is delayed, and now I am working on a different project, so I won’t be back to AR for a while (few days or more).

PS: As I did not do any improvements to the actual detection routines, the accuracy and stuff remains the same. I have tweaked a coefficient in there a little and it seems to improve a bit. What I can definitely say – the printed marker size matters. The size of 10x10cm looks best to me (although I did not experiment much), which is roughly corresponds to markersize 80 set during marker creation in the program. I was unable to find any docs on that, so no idea what exactly that means. The camera resolution 640×480 seems to work better than 320×240. I thought I’d share my observations in case you will ever be in the same situation.

Hey @noncom

I’m the author of armonkeykit, I’ve not been around these forums for a while as I simply haven’t had time to touch armonkeykit for a while, too many other research demands! It’s great to hear that you have had success with the port as it is something that has been on my todo list for a while now, just restricted by the complete lack of time.

If you want to have a chat about it, I’d be more than happy for you to become a contributor?

@nomcom

Don’t worry about it! The headers etc are easy to drop in, it’s the porting that is the main part and no doubt you have saved a lot of work for others wanting to achieve the same thing. I’ll be in touch soon with regards to what needs to happen

Cheers

Adam

@Momoko_Fan

Sadly this fix did not solve the problem. I thought so. Because when you adviced to use clear() method on the buffer, I was already using rewind() which acts similarly in this situation. It still keeps happening. I really wonder why!!! Do you have any other ideas?

Anyway, an interesting bug.. I will explore more..

@noncom said:
@Momoko_Fan

I have checked all my Java code very thoroughly, there seem to be no error. Aside from that, the stack trace (see the second message in this thread) does not mention any of my classes. The error occures in the lwjgl thread and it is especially so that i do not pass any unrewinded buffers to it. Explicit checks on my code indicate that at no moment does any erroneous object get passed to the engine. The error may come up in the first few seconds of running the application, or it may never come up during an entire hour of running the application. There is no place in my code that could be a source of such error behavior. Therefore I conclude that this might be either a bug in the engine, lwjgl itself, or some kind of a synchronization issue between threads. Too bad.. what to do?

Its possible you’re handling the texture from multiple threads, in that case, you cannot use clear/put/get etc safely on it. You have to use ByteBuffer.duplicate() each time you want to modify the texture which will ensure you’re not altering those values from multiple threads.