Android's camera output is green on the Nexus 5

[manuelbua]

The workaround is to always attach a dummy texture as per the other example in the repository: i implemented the same attach/detach surface code and it works fine now. Too bad camera access is quite a PITA on Android :/

[RaimundWege]

@manuelbua could you please explain your solution in more detail?

[ayberkozgur]

We recently abandoned libgdx development. Feel free to continue the discussion here but please be aware that we will soon delete all libgdx-related repositories.

[manuelbua]

@RaimundWege not sure if i still have the code at hand, but i may look it up for you: i just looked up at the examples and implemented the same workaround there, you need to attach a dummy texture so that the whole camera thing gets kickstarted correctly, but can't really remember exactly what the one example was.

[RaimundWege]

@manuelbua like always i've found the code that you mean a few minutes after the post ;) (here: https://github.com/chili-epfl/chilitags/blob/150378373a79f10ade1ac3f6aaf428dcb9103473/platforms/jni/samples/android-estimate3d-gui/src/ch/epfl/chili/chilitags/samples/estimate3d_gui/CameraPreviewRenderer.java) I think i get rid of it now. thx! @ayberkozgur too bad. is there a good reason not to use chilitags in libgdx? I've planned to use them both for my master-thesis.

[ayberkozgur]

@RaimundWege We didn't abandon Chilitags :) However, expect the JNI bindings of Chilitags to be not maintained since we abandoned Java together with libgdx. If you're interested, check out https://github.com/chili-epfl/chilitrack, it will hopefully be a full-fledged markerless tracking solution soon.

We replaced libgdx as a development platform with Qt. There are multiple reasons behind this:

• Qt is much more mature and is developed by a professional company by a much greater number of people.
• Qt community is much bigger and much more well established.
• Qt is native while libgdx is Java. Java becomes a HUGE problem if you're doing any serious calculation. The solution to this would be to write modules natively and JNI wrap everything. This is very high maintenance and messy.
• Qt + QtQuick is very modular and powerful: it can describe UI/non-UI scenes very expressively and in very little code.

As for the downsides:

• Qt does not support iOS yet, but we pretty much don't care.
• Qt3D 2.0 is not yet ready but will be in a couple of months' time. This will hopefully include a better, faster API with bone animation support.

So I would recommend you to give Qt a go before settling on libgdx for your master's thesis.