poor performance on editor/android with large glb file

[incafox]

Hi, i was testing this project and i have very bad performance with "large" glb scene (40mb-100mb) (3d models with lot of objects, ~1M verts ), this was designed just for litle objects? what about performance on mobile devices? what are the limits of this library?

[atteneder]

The goal of glTFast is, to not be the limiting factor when it comes to performance. That being said, your observation can have multiple reasons (that don't exclude themselves):

• unoptimized parts in glTFast
• unoptimized glTF files
• simply too much data to handle

I can't possibly tell you why it's slow without taking a look at the glTF files you load, but 100 MB/1 Mio triangles seems excessive on mobile (so the 3rd category is likely). I can offer to take a look if you provide it.

The only thing I know where glTFast is "poor" at the moment is when using metallic-roughness or occlusion textures in materials. They have to be converted at runtime, which is super slow. I fixed this yesterday and will release it soon. Feel free to check the feature/custom_shader branch, if you're curious.

[incafox]

thanks for answer, i uploaded some files:
https://drive.google.com/open?id=1SyBrFE4kZTIgYQV21FIHS48CLuZvZxG9
i was using an obj runtime importer, on my experience is faster than glTFast, but i will like to implement gltf instead of some other format.
the original files are from sketchup, i used this gltf exporter
https://extensions.sketchup.com/sv/content/gltf-exporter
i tried on the weblg demo the same files located on my drive directory(hosted on other server with direct download) but it never load.

[atteneder]

Thanks for providing the files!

These glTF file have few (2) huge vertex/position buffers for all objects and the indices of all primitives refer to this one huge buffer (380k verts for the bigger file)

I'v never seen a strange layout like this and while it's probably compliant to the specification, I'm not sure if this should be a valid file.

It might load/work OK if your engine/API allows binding render resources manually, but cannot work well with the current Unity Mesh API, which requires one vertex buffer per mesh/primitive.

On top of that glTFast does not handle this well at all and duplicates this huge buffer for every sinlge object. Fixing this is doable and would speed it up significantly, but it still would be way slower than loading a sane glTF with proper separate position buffers.

Unity 2019.3 has a newer mesh API, which might be a solution, but I haven't looked into this yet.

Additional observations:

• the scene is not optimized for realtime (many huge non power of two textures)
• the glTF file is not optimized (all position buffers have an unused duplicate, no mesh compression)
• it takes a minute to load it in Blender, so I think glTFast is not the only one not expecting this kind of data and handling it so poorly.

What I would suggest:
Find some other way/tool that creates better glTF files.

I've tried importing the smaller file into Blender and exporting it again, which solved the problem, but had other quirks like textures being re-encoded to PNG. The big file's export would take too long :/

hth

[atteneder]

you might try a different exporter like this one:
https://github.com/YulioTech/SketchUp-glTF-Exporter-Ruby

[atteneder]

Using gltfpack the big scene loads in under 3 seconds (instead of 18) on a macbook pro.
You might wanna check it out, but be aware that the current glTFast version cannot load the atm. You have to use the mesh_quantization branch.

[atteneder]

I did some more research:

glTFast currently does not properly merge primitives of identical vertex attribute data into one mesh with sub meshes. This is an optimization I'd like to do to fix/improve #57. Your scene might benefit a little too, but the main issue remains the giant vertex buffers.

@aras-p confirmed that it is not possible to re-use a giant vertex attribute buffer amongst meshes.

So the only solution is, to split up the vertex buffer(s), so that each mesh has its own. While it's conceptually possible to do this at run-time, I'd say this has to be done correct at the export stage.

gltfpack (mentioned above) does a good job and glTFast got support for quantized meshes in the meantime.

I might introduce some in-Editor warnings, whenever inefficient glTFs are loaded (just like I do with embed/base64 data).

Thanks