Large size obj's not loading its causes java.lang.OutOfMemoryError.

[ArigarasuthanRepo]

I have working ar-core android sample using your library to read obj files and render in opengl es.I have 200mb obj file its not read by simple wavefront loader library it causes the java.lang.OutOfMemoryError.But 110 obj files were read perfectly.is any to solve this problem?

[javagl]

Technically, I'm afraid that I cannot give more specific hints than those in https://stackoverflow.com/a/25719828/

But 200mb is really large for an android device. This must be waaay more than 500k vertices + attributes (possibly many more, when flattened for rendering).

So conceptually, I'd strongly recommend to check whether you really need such a large model on a mobile device. It would probably be better to just convert it into a model with fewer vertices.

[ArigarasuthanRepo]

Thank you so much for the solution.may i know how much maximum size of obj we can render?

[javagl]

There are limits for the number of vertices for a single rendered object, see https://github.com/google-ar/arcore-android-sdk/issues/73#issuecomment-350889946

But regarding the OBJ loader: There should be no limit, except for the available memory. So the maximum size only depends on your system and setup.

[ArigarasuthanRepo]

Thank you for your help. i was resized models and rendered perfectly.Is there any way to load model fast because 40 mb and 50mb models were render slowly.

[javagl]

Is there any way to load model fast because 40 mb and 50mb models were render slowly.

Is the problem that the model is not loading fast enough, or that the model is not rendered smoothly?

The latter is something that you can hardly change. You could try some tweaks (simpler shaders, non-indexed geometry or so), but eventually, you have to anticipate that a smartphone is not a graphics workstation.

If the model takes long to load: When developing the OBJ loader, performance was not the primary goal. It should be a loader that is

• simple to use
• can load most of the existing OBJ files
• (important: ) allows to easily obtain the geometry data so that it may be rendered with OpenGL

Of course, I tried to not waste time on the "critical paths", and I did some performance tests, benchmarks and optimizations. But at some point, there is the usual trade-off: If you knew the structure of your input file and ignored some possible corner cases, you could probably trade a few percent of performance against reduced flexibility.

One point that may be worth mentioning: If you are using the convertToRenderable method (and you are most likely doing this), then there might be a considerable potential for improvement. As stated in the JavaDoc of this method: It performs some steps that are necessary to make sure that "every" input file has a "renderable" format.

But for example: If you already know that your input file only contains triangles, you can omit the triangulation step. And if you know that you already have unique normals and texture coordinates, and/or your model is already single-indexed, you can skip these steps as well (and the steps are comparatively expensive)

[ArigarasuthanRepo]

Ok.but the scenkit in ios rendered object fastly why android does not rendering 3d object fastly.

[javagl]

So this is (only) about the rendering performance?

[ArigarasuthanRepo]

Yes. only rendering perfomance is slow otherwise objects were rendered perfectly.

[javagl]

Then, I'm afraid, I won't be able to help you here immediately

And it's hardly related to the OBJ loader, by the way. You could consider opening this as an issue in the Google AR demo repo, where the actual rendering code is located.

I'd really like to have a closer look at this, and play around more in the Android/OpenGL rendering world, but am juggling with too many tasks and their priorities right now (and the OBJ loader is only one of dozens of my spare-time projects...)

I'll leave this issue open, though - maybe I can allocate some time to investigate this, but I cannot promise anything right now.

[javagl]

It's unlikely that I'll allocate this time in the near future (and if so, it's unrelated to this issue...)