OBJ file isn't rendered correctly

[marcus905]

Hi,

While loading an obj file it gets rendered with about half the triangles that compose it, as in the attached picture.

I can't post the obj file for copyright reasons but I can assure you that it's always this way even if processed with blender or meshlab. Both of them correctly display the model and the associated texture that, by the way, is also not displayed even though it's loaded as I see the log message 'hastex ...'

There are no errors or warnings in the logcat.

What's happening here?

(ps: I use the VuforiaRajawali extension)

[jwoolston]

what material are you using for the OBJ? Can you try setting the object returned from the parser to double sided?

[jwoolston]

There is no edge primitive in open gl es. This is not a shortcoming of the library.

[jwoolston]

Sorry, wrong issue...

[marcus905]

I use a mtlfile that I'm pasting here:

newmtl material_0 Ka 0.200000 0.200000 0.200000 Kd 0.407843 0.333333 0.058824 Ks 1.000000 1.000000 1.000000 Tr 1.000000 illum 2 Ns 0.000000

newmtl material_1 Ka 0.200000 0.200000 0.200000 Kd 0.505882 0.517647 0.203922 Ks 1.000000 1.000000 1.000000 Tr 1.000000 illum 2 Ns 0.000000 map_Kd a.jpg

newmtl material_2 Ka 0.200000 0.200000 0.200000 Kd 0.000000 0.000000 0.000000 Ks 1.000000 1.000000 1.000000 Tr 1.000000 illum 2 Ns 0.000000

newmtl material_3 Ka 0.200000 0.200000 0.200000 Kd 0.278431 0.317647 0.298039 Ks 1.000000 1.000000 1.000000 Tr 1.000000 illum 2 Ns 0.000000 map_Kd a.jpg

a.jpg is a 512x512 image (fixed the not loading textures, they needed to be square and powers of 2 -- put this in the wiki)

The triangles are still missing.

[jwoolston]

Square textures should not be a requirement but power of two in each dimension is a common hardware restriction. The wiki documentation is being rewritten but the new development is our priority and the new implementation is very different so most of the documentation is no longer valid.

Did you try setting the object to double sided?

[marcus905]

Yes, I did. There is no difference, forgot to mention it before.

[marcus905]

In your opinion if I contributed an automatic resizer for textures, would it be useful?

[jwoolston]

So long as it was pure java/android (no NDK usage and no external libraries) yes. We have an open issue for a render script framework which will include things like this but that is many months away from being a reality. It also remains to be seen if we will be able to do everything in 4.0 or if we will be required to use some 4.1+ features so it may be that a java implementation is necessary in either case. If it is sufficiently robust and abstract we could even have it automatically invoked by the engine when loading a NPOT texture on a device which does not support it.

[marcus905]

I did it for another framework, it is pure Android Java. I'll try to reimplement it around your framework then.

What about the missing triangles?

[jwoolston]

Sounds good. Still thinking on the triangles. I'll take a closer look when I get to the office.

[marcus905]

Oh, forgot to mention that there are also some triangles that are noticeably wrong in other parts of the model.

Wrong means with one of the vertices stupidly far from the other 2, making it a very long skinny triangle that goes through/in-front-of the model.

[jwoolston]

As in position/size? If that's the case it sounds like an index problem. Since I can't look at your file can you tell me if it tries to reuse vertices or does it specify a duplicate for each triangle?

[jwoolston]

Also, are you using groups in your file?

[marcus905]

The triangles are wrong sizewise because one of the vertices is in the wrong place (wrong position of one vertex -> wrong triangle size).

By looking at the file in a text editor, it seems to my eyes that it reuses some indices in the faces.

There is another thing I noticed: the top left of the model is almost completely correct, while the lower right is the most erroneous with many missing triangles.

No groups in the file.

[jwoolston]

I'm not well versed in the details of the OBJ parser for this library but I know it has numerous things which will make it stumble. Having written one myself before, I know that the format is difficult to create a parser for which will handle any OBJ file. I know @ToxicBakery was making an improved version a week or two ago but I am not sure what its current state is.

Your observation about part of the model being mostly correct is making me wonder if when exported, something tried to optimize the model and the result was a form Rajawali's parser is not ok with. Can you try re-exporting the model (from the source model not by importing the OBJ) and disabling any optimization settings?

[Davhed]

Did you triangulate your mesh before exporting? This is what my models often look like if I forget that step.

[dcerisano]

You may also want to try setDoubleSided(true), and/or setBackSided(true) during the render. Some models get exported with reversed faces. Try un/setting "Keep Vertex Order" during Blender export.

I have found myself editing OBJ files by hand in order to get a model to render. ObjParser has a couple of limitations:

Will not import OBJs that contain groups, but multiple objects (children) are allowed. Only one color/material/texture allowed per object - all faces will be rendered with it. Keep the above in mind when creating models. Models that don't follow the above must be edited be hand.

Never trust a free model. Generally they are a piping hot mess inside. Also any model you get will have to be made "game ready" ie shelled, vertex reduced and face culled to get the poly count down to something reasonable.

Curious as to whether the Rajawali Serializer automatically flattens and busts up the objects for texturing?

[ToxicBakery]

The Rajawali Serializer uses the Rajawali framework for parsing and exporting, the tool itself is just a shortcut to prevent you from needing your own boiler plate code to do conversions.

As for the OBJ parser, yes I am working on it. Also I am doing a LOT to the AWD parser which will be better than serialization by a ridiculous amount. The new OBJ parser, whenever it is done, will be a carbon copy of the Away3D implementation so whatever they support, we will try to support in Rajawali.

That said, OBJ is an awful, awful format and I highly recommend you use anything else.

[dcerisano]

Yes, I could eat a handful silicone and puke a better object format than OBJ. Looks like the pain involved to make Blender export AWD is somewhat less than a poke in the eye ... Any comment on an ideal developer toolset for using Rajawali going forward? I would love to ditch Blender, and its martian UI.

[ToxicBakery]

As blender is free an accessible I believe it is the choice moving forward. The Away3D team does provide Away Builder though which can do FBX to AWD format for you. Once supported properly, the Rajawali Serializer will allow the same.

[marcus905]

@jwoolston it's the same if exported with blender in various ways and in meshlab. @Davhed yes, I did. @dcerisano, I tried all you wrote to no avail sadly. My obj has no groups, only a single texture (as you can see in the mtl I posted above @ToxicBakery, I know about the crap that is the OBJ file format -- and I think this has become a legacy situation where you have to support it even though it's crap because everyone and their dog want it... should I try using the AWD file format then?

[marcus905]

oh, and what about the x3d format?

[marcus905]

@dcerisano forgot to mention that while it did nothing for the malformed triangles, turning the keep vertex order made more triangles visible, so the model is more correct than the other but still not completely right.

[marcus905]

@ToxicBakery the AWD parser doesn't work either, it starts parsing all the blocks then crashes with EOFException when loading a file created with AwayBuilder 1.0.0 Gold. Is there a newer version of the parser?

[ToxicBakery]

AWD parser always throws an EOFException from the internal parser, it should not be propagating up to your try/catch block though. Unfortunately this is by design as the standard does not have a way to know when you will hit the end of the file, you just keep trying until nothing is left to read.

The current AWD implementation only reads geometry, if you look at the AWD-Continuation branch you will see a lot more is coming soon. Same for OBJ, when its done, it'll be significantly improved. X3d has no support, never even heard of it.

[marcus905]

X3D is this: en.wikipedia.org/wiki/X3D Another common format that'd be interesting is probably Collada DAE/ZAE.

I'm checking-out the AWD-Continuation branch to see what can be used or fixed :)

[jwoolston]

My company needs COLLADA support so its on the list for me to work on for the v0.11 release.

[ToxicBakery]

@marcus905 don't submit anything to that branch, I'm actively working on it and until I finish this cleanup its not even possible to reliably commit block parsers yet. Still need a few more features before that.

[marcus905]

@ToxicBakery oh, ok :)

So, to recap:

• OBJ format is crap and the parser needs to be rewritten (and I see the related branch in GitHub)
• 3DS doesn't work.
• AWD is being worked on but it still needs some time (in the related branch).
• FBX is slow as hell, incomplete and doesn't work half of the times.
• STL has no texture support
• MD2/MD5 are for low poly animations, not high poly models.
• Collada DAE/ZAE will be there by v0.11

What do you suggest I do now?

[jwoolston]

@marcus905 I'm afraid that about sums it up. That said your options become tricky. In spite of its serious shortcomings most people currently use the OBJ parser. If you are able to get the geometry loaded from an fbx file you could serialize it to eliminate the speed issue. Hopefully COLLADA and AWD will both be part of the next release.

To deal with your current issue though...I have lost track, what is the source if your file? In-house or a repository (either paid or free)

[marcus905]

This file comes from a paid private repository (it's a bit more complicated than that) and I, sadly, cannot give it (or a portion thereof) away due to copyright reasons.

[jwoolston]

That is unfortunate as it severely limits our ability to determine the issue. Have you tried other files from the same source? Are you certain there are no quads specified in the file? On Jul 16, 2013 7:53 AM, "Marco Antonio Mauro" notifications@github.com wrote:

This file comes from a paid private repository (it's a bit more complicated than that) and I, sadly, cannot give it (or a portion thereof) away due to copyright reasons.

— Reply to this email directly or view it on GitHubhttps://github.com/MasDennis/Rajawali/issues/943#issuecomment-21047201 .

[marcus905]

Simpler files parse better, almost correctly -- the smaller/simpler the file is the more correct it is.

I'm certain as I processed the file in blender and triangulated it, then exported with the triangulate option.

[marcus905]

Would this be of any use to you? https://github.com/seanrowens/oObjLoader

[jwoolston]

@ToxicBakery? On Jul 16, 2013 8:52 AM, "Marco Antonio Mauro" notifications@github.com wrote:

Would this be of any use to you? https://github.com/seanrowens/oObjLoader

— Reply to this email directly or view it on GitHubhttps://github.com/MasDennis/Rajawali/issues/943#issuecomment-21051267 .

[jwoolston]

What is the poly count of these files?

[marcus905]

@jwoolston I'm not at the office now, but if I recall correctly about 38 thousands triangles the one I try to load. About 4 million the one from which we processed this one.

Edit: it's 33941 polys.

[ToxicBakery]

Can't hurt to try, if someone else wants to give it a shot, please go for it. I'm pretty busy and though I'll gladly continue updating the OBJ parser, I do not actually use it and my only motivation fixing it is so that the spare time dennis has, can be spent on important features.

AWD and STL on the other hand I want to use more so like I said before, I will be crushing on those as much as possible. Well AWD anyways, STL seems to be perfect or close enough to it that most STL files work perfectly.

[jwoolston]

it's 33941 polys

I wonder if the device you are using only supports short buffers, in which case you would be over the maximum index count. Can you call RajLog.systemInformation() and post the results please?

[marcus905]

Here the system info for the 2 devices we use for testing:

07-22 14:10:47.394: I/Rajawali(5788): -=-=-=- Device Information -=-=-=- 07-22 14:10:47.394: I/Rajawali(5788): Brand : acer 07-22 14:10:47.394: I/Rajawali(5788): Manufacturer : Acer 07-22 14:10:47.394: I/Rajawali(5788): Model : A511 07-22 14:10:47.394: I/Rajawali(5788): Bootloader : unknown 07-22 14:10:47.394: I/Rajawali(5788): CPU ABI : armeabi-v7a 07-22 14:10:47.394: I/Rajawali(5788): CPU ABI 2 : armeabi 07-22 14:10:47.394: I/Rajawali(5788): -=-=-=- /Device Information -=-=-=- 07-22 14:10:47.394: I/Rajawali(5788): -=-=-=- OpenGL Information -=-=-=- 07-22 14:10:47.394: I/Rajawali(5788): Vendor : NVIDIA Corporation 07-22 14:10:47.394: I/Rajawali(5788): Renderer : NVIDIA Tegra 3 07-22 14:10:47.394: I/Rajawali(5788): Version : OpenGL ES 2.0 14.01002 07-22 14:10:47.394: I/Rajawali(5788): Extensions : GL_OES_rgb8_rgba8 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_EGL_sync 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_surfaceless_context 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_fbo_render_mipmap 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_depth_nonlinear 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_draw_path 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_texture_npot_2D_mipmap 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_EGL_image 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_EGL_image_external 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_vertex_half_float 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_mapbuffer 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_draw_buffers 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_multiview_draw_buffers 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_Cg_shader 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_packed_float 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_texture_half_float 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_array 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_compressed_ETC1_RGB8_texture 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_compression_latc 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_texture_compression_latc 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_compression_dxt1 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_compression_s3tc 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_texture_compression_s3tc 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_filter_anisotropic 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_get_tex_image 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_read_buffer 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_shader_framebuffer_fetch 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_copy_image 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_fbo_color_attachments 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_bgra 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_format_BGRA8888 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_unpack_subimage 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_pack_subimage 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_texture_compression_s3tc_update 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_read_depth 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_read_stencil 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_uniform_buffer_object 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_map_buffer_range 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_robustness 07-22 14:10:47.394: I/Rajawali(5788): : GL_OES_standard_derivatives 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_EGL_stream_consumer_external 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_separate_shader_objects 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_copy_buffer 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_3dvision_settings 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_debug_marker 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_debug_label 07-22 14:10:47.394: I/Rajawali(5788): : GL_KHR_debug 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_texture_storage 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_pixel_buffer_object 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_framebuffer_blit 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_non_square_matrices 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_explicit_attrib_location 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_smooth_points_lines 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_coverage_sample 07-22 14:10:47.394: I/Rajawali(5788): : GL_EXT_occlusion_query_boolean 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_occlusion_query_samples 07-22 14:10:47.394: I/Rajawali(5788): : GL_NV_timer_query 07-22 14:10:47.394: I/Rajawali(5788): -=-=-=- /OpenGL Information -=-=-=- 07-22 14:10:47.394: I/Rajawali(5788): -=-=-=- OpenGL Capabilities -=-=-=- 07-22 14:10:47.394: I/Rajawali(5788): Max Combined Texture Image Units : 16 07-22 14:10:47.394: I/Rajawali(5788): Max Cube Map Texture Size : 2048 07-22 14:10:47.394: I/Rajawali(5788): Max Fragment Uniform Vectors : 1024 07-22 14:10:47.394: I/Rajawali(5788): Max Renderbuffer Size : 3839 07-22 14:10:47.394: I/Rajawali(5788): Max Texture Image Units : 16 07-22 14:10:47.394: I/Rajawali(5788): Max Texture Size : 2048 07-22 14:10:47.394: I/Rajawali(5788): Max Varying Vectors : 15 07-22 14:10:47.394: I/Rajawali(5788): Max Vertex Attribs : 16 07-22 14:10:47.394: I/Rajawali(5788): Max Vertex Texture Image Units : 0 07-22 14:10:47.394: I/Rajawali(5788): Max Vertex Uniform Vectors : 256 07-22 14:10:47.394: I/Rajawali(5788): Max Viewport Width : 3839 07-22 14:10:47.394: I/Rajawali(5788): Max Viewport Height : 3839 07-22 14:10:47.394: I/Rajawali(5788): Min Aliased Line Width : 1 07-22 14:10:47.394: I/Rajawali(5788): Max Aliased Line Width

(--this ends abruptly here--)

and:

07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- Device Information -=-=-=- 07-22 14:13:48.995: I/Rajawali(13782): Brand : samsung 07-22 14:13:48.995: I/Rajawali(13782): Manufacturer : samsung 07-22 14:13:48.995: I/Rajawali(13782): Model : GT-I9300 07-22 14:13:48.995: I/Rajawali(13782): Bootloader : smdk4x12 07-22 14:13:48.995: I/Rajawali(13782): CPU ABI : armeabi-v7a 07-22 14:13:48.995: I/Rajawali(13782): CPU ABI 2 : armeabi 07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- /Device Information -=-=-=- 07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- OpenGL Information -=-=-=- 07-22 14:13:48.995: I/Rajawali(13782): Vendor : ARM 07-22 14:13:48.995: I/Rajawali(13782): Renderer : Mali-400 MP 07-22 14:13:48.995: I/Rajawali(13782): Version : OpenGL ES 2.0 07-22 14:13:48.995: I/Rajawali(13782): Extensions : GL_EXT_debug_marker 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_texture_npot 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_compressed_ETC1_RGB8_texture 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_standard_derivatives 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_EGL_image 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_depth24 07-22 14:13:48.995: I/Rajawali(13782): : GL_ARM_rgba8 07-22 14:13:48.995: I/Rajawali(13782): : GL_ARM_mali_shader_binary 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_depth_texture 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_packed_depth_stencil 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_texture_format_BGRA8888 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_blend_minmax 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_EGL_image_external 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_EGL_sync 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_rgb8_rgba8 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_multisampled_render_to_texture 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_discard_framebuffer 07-22 14:13:48.995: I/Rajawali(13782): : GL_OES_get_program_binary 07-22 14:13:48.995: I/Rajawali(13782): : GL_ARM_mali_program_binary 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_shader_texture_lod 07-22 14:13:48.995: I/Rajawali(13782): : GL_EXT_robustness 07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- /OpenGL Information -=-=-=- 07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- OpenGL Capabilities -=-=-=- 07-22 14:13:48.995: I/Rajawali(13782): Max Combined Texture Image Units : 8 07-22 14:13:48.995: I/Rajawali(13782): Max Cube Map Texture Size : 1024 07-22 14:13:48.995: I/Rajawali(13782): Max Fragment Uniform Vectors : 256 07-22 14:13:48.995: I/Rajawali(13782): Max Renderbuffer Size : 4096 07-22 14:13:48.995: I/Rajawali(13782): Max Texture Image Units : 8 07-22 14:13:48.995: I/Rajawali(13782): Max Texture Size : 4096 07-22 14:13:48.995: I/Rajawali(13782): Max Varying Vectors : 12 07-22 14:13:48.995: I/Rajawali(13782): Max Vertex Attribs : 16 07-22 14:13:48.995: I/Rajawali(13782): Max Vertex Texture Image Units : 0 07-22 14:13:48.995: I/Rajawali(13782): Max Vertex Uniform Vectors : 256 07-22 14:13:48.995: I/Rajawali(13782): Max Viewport Width : 4096 07-22 14:13:48.995: I/Rajawali(13782): Max Viewport Height : 4096 07-22 14:13:48.995: I/Rajawali(13782): Min Aliased Line Width : 1 07-22 14:13:48.995: I/Rajawali(13782): Max Aliased Line Width : 100 07-22 14:13:48.995: I/Rajawali(13782): Min Aliased Point Size : 1 07-22 14:13:48.995: I/Rajawali(13782): Max Aliased Point Width : 100 07-22 14:13:48.995: I/Rajawali(13782): -=-=-=- /OpenGL Capabilities -=-=-=-

Let me know :)

[marcus905]

After having done multiple tests and a parser rewrite that didn't fix on ameliorate anything at all I think that there's a problem with the processing pipeline somewhere between the array creation and the opengl code, probably in the arrays to buffers conversion.

I found another model that shows kind of the same problem that I can share with you and that you can find here:

https://www.dropbox.com/s/exo8htlh14hmc07/testobj.zip

I can almost assure you that the device is not the culprit as the same model in another framework are displayed perfectly.

@ToxicBakery @jwoolston what do you think?

[jwoolston]

I'm busy at the moment but I will try and take a look at it today. It certainly seems like a possibility.

[jwoolston]

Hmmm, I just loaded that model on a Galaxy Nexus with no problems. Confirmed by loading in Blender as well.

[marcus905]

May I have a screenshot of what you see? This is what I see:

I honestly have no idea at all about what's happening.

It's the same on both devices.

[jwoolston]

Here you go. I'm wondering if the Vuforia engine is in some way messing with this.

[marcus905]

The OBJ colors are wrong, bur apart from that it's ok...

@jwoolston how do we check if vuforia is the culprit?

[marcus905]

I tried to load the model in the examples app as you did but I see the same artifacts!

What branch or revision/commit do you use?

I'm puzzled by what's happening here...

Any idea?

[jwoolston]

That was master (for both) before noon Pacific time yesterday. Is give you a hash but I'm not at a computer right now. As for testing if it is vuforia or not it looks like we can rule that out since you had the same trouble with the examples. I can try testing it on a few other devices but I'm leaning towards something on your two devices. Do they have custom ROMs?

[marcus905]

Please do.

The device on which the screenshots have been taken, an Acer A511, has the factory ROM. The other one, the Samsung GS3 Intl. GT-I9300, has the latest CM10.1 nightly build.

The artifacts are the same on both

[jwoolston]

Well the Acer certainly throws a wrench in things but I would be remiss if I didn't point out that many people have encountered numerous bugs caused by using that particular ROM. I'll test the devices we have in the office when I get there.