Best practice for multiple models, textures and materials

Questions
1

Hi,

I’ve just completed a project that use a relatively small number of meshes created in Blender and exported individually as glbs. In Blender the artist used a texture atlas that had different parts used by the individual models.

In testing we discovered that the scene would not load on older devices such as the iPhone 6. Doing some quick profiling It appeared that memory usage was over 2GB! Since I was unaware that they were all sharing the same texture until I saw this and queried texture sizes used.

The resolution was to export all of these objects in the same glb, all positioned at 0,0,0 and then re-write the loader to split the meshes as required (we had a tight deadline and this was the only way to hit it).

So the question(s):

  • Is there a best practice for dealing with this situation?
  • Does Babylon support monochrome textures (in-memory, not loading a monochrome image)?
  • Are there any recommended resources I may have missed?

Thanks!

2

Instead of creating a single glb file you could have updated the materials of your meshes after loading and made them point to the same albedo texture. However, you would still have incurred the big texture size problem at loading time, so to avoid that you would have needed to set a (small) dummy texture in the glb files (or no texture at all).

I don’t think there’s really a best practice for this, but artists may know better.

You could have tried to use compressed textures to lower the gpu memory footprint: Multi-Platform Compressed Textures - Babylon.js Documentation

Starting from Babylon.js 4.2, there’s the new KTX2 loader used by the KHR_texture_basisu extension that let’s you use .ktx2 files in gltf/glb files, but this Khronos extension is not validated yet (should be soon).

3

Thanks; I will continue with investigations here and post back any findings others may find useful.

Currently I’m thinking we’ll need to post-process the exports from Blender to accommodate both shared and compressed textures.

When loading these processed files we can then match the shared textures/materials when everything is loaded in.

As we’re going to be doing a lot of quick turnaround projects (some are only 1 week, others up to 8) I’m looking at building a tool chain we can use to reduce the work, pain and also memory footprint of this stuff.