Porting ARMonkeyKit to jME3 some questions

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: File name: AR.rar File size: 13.17 MB



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…

Stupid was I. Partly. I have increased the accuracy by increasing the camera resolution request from 320x240 to 640x480 at the lines 44 and 45 of ARApp.java (to fit the double-sized quad in the window, also ‘25’ has to be replaced with ‘50’ on line 131 of ARApp.java). That mostly closes my question number 2. Altough if someone has something to add, I would be glad to hear… the questions 1 and 3 remain + one more that I have forgot of. Occasionally, after some time running the app, I get the following error:





SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]

java.lang.IllegalArgumentException: Number of remaining buffer elements is 0, must be at least 921600. Because at most 921600 elements can be returned, a buffer with at least 921600 elements is required, regardless of actual returned element count

at org.lwjgl.BufferChecks.throwBufferSizeException(BufferChecks.java:162)

at org.lwjgl.BufferChecks.checkBufferSize(BufferChecks.java:189)

at org.lwjgl.BufferChecks.checkBuffer(BufferChecks.java:230)

at org.lwjgl.opengl.GL11.glTexImage2D(GL11.java:2811)

at com.jme3.renderer.lwjgl.TextureUtil.uploadTexture(TextureUtil.java:504)

at com.jme3.renderer.lwjgl.LwjglRenderer.updateTexImageData(LwjglRenderer.java:1865)

at com.jme3.renderer.lwjgl.LwjglRenderer.setTexture(LwjglRenderer.java:1887)

at com.jme3.material.MatParamTexture.apply(MatParamTexture.java:46)

at com.jme3.material.Material.render(Material.java:1009)

at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:649)

at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:299)

at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:354)

at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:891)

at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:842)

at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1118)

at com.jme3.renderer.RenderManager.render(RenderManager.java:1160)

at com.jme3.app.SimpleApplication.update(SimpleApplication.java:266)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:149)

at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:182)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:223)

at java.lang.Thread.run(Thread.java:662)



I know this is due to the image or texture containing less information that required by the LWJGL renderer. The image is filled with data in method onUpdateBuffer() in QtCaptureImage.java… I used to have this error initially but when I have corrected the dimensions and the format of the image with the size of the buffer (width * height * 3; where 3 is for rgb8) it seemed to have gone. Now I get it again, but this time it says about 0 bytes

remaining. I have never worked with LWJGL and I do not understand the actual origin of this error and how to fix it. My best guess is that somehow the app goes out of sync with the camera and either it does not receive a new image or it still processes the old one when the new one is received… The error is critical and causes the app to crash… it is amazing, how subtle the LWJGL is… it crushes on every possible occasion like if an object has no material omg… but does anyone know how to fix this error here?

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

1 Like

@noncom:



I’m interested in the porting, how is the process of the project?

@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 640x480 seems to work better than 320x240. I thought I’d share my observations in case you will ever be in the same situation.

If these changes are essentially updates to the armonkeykit, then you might as well ask for contributor permissions on the offical GoogleCode repo:

http://code.google.com/p/armonkeykit/



If not then, well, set up a new project on GoogleCode or GitHub I guess.

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?

@ajclarkson



Hi! Sure, I want to contribute the code to the core projects. It would be nice to see ARMonkeyKit and JMonkeyEngine developing, bouncing and happy. Actually, I have done very little coding in this project especially comparing to what it was before me. And it might be not very neat and organized and all these headers with licenses, disclaimers and authorship are absent, but at least it works and may save a day or two for someone who tries to walk the same path. Just tell me what should I do in order to contribute…

@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

@ajclarkson



Ok, sure! I will be seeing forward for any news from you.

@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?

If there’s a put, you need to have a clear at the end. I don’t know how that library is structured so I can’t really help you any further …

Anyway, an interesting bug… I will explore more…

@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?

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

Luckily I have a test project from @noncom and the porting is pretty awesome!!!



Hope that he will make a release very soon with fixes… After that, the powers are on our hand :stuck_out_tongue:

@Momoko_Fan



The duplication approach that you have suggested seems to have helped! Obviously it was a race condition due to mutability of the buffer. Thank you very much! Adam contacted me, I hope that soon jME3’s applicability range will be enriched with AR aux lib for those who might need it.

Hello Everybody,

I´m trying to use jmonkey 3 and nyartoolkit, but i´m having some problems to start the cam. Is ARMonkeykit portable for JME3? If yes, where could I find? I checked the link for fileserv, but any file was foud. Could I have access to this example?

Thanks very much,

Thiagol

@taamorim

@taamorim said: I´m trying to use jmonkey 3 and nyartoolkit, but i´m having some problems to start the cam. Is ARMonkeykit portable for JME3? If yes, where could I find? I checked the link for fileserv, but any file was foud. Could I have access to this example?

Noticed your post occasionaly! You better write personal messages if there is something important, they send notifications on email. So are you still interested? I can prepare the package for you again and put it on a fileserv. BTW do you have a Bitbucket account? I could simply invite you to the repo… Anyway, write me a personal message, so that I spot your respone on my email.

Some note about my port: Some pretty significant changes had to be done to the original ARMonkeyKit to make it work with JME3. And the latest version of the port is written in Scala (since I do not write plain Java that much anymore). Maybe Atomix has some acheivements there too, you could PM him too.