Gltf-blender-io: File size is much larger than the Exporter addon

[ankervold]

I was using the blender exporter in 2.79b with the gltf node and everything would export as expected. I made the move to 2.8beta and started using the import/exporter with the principled BSDF and have several issues. I also tried the import/exporter with principled BSDF in 2.79b and run into the same problems. My test has 18 different materials but they all use the same three color, roughness, normal textures just adjusted to different factors. Rendered in cycles they all look correct inside blender. I'm on Blender 2.80.37 I think its a day old maybe two.

The final glb export file size is much larger than usual. My file size with the exporter was around 10mb with the import/export and principled it’s around 200mb. I started with 9 of materials being unique and 9 being the same, the export was around 130mb. I changed the other 9 to be unique also and the export jumped to 200mb. Its like every material is exporting its individual color, roughness, normal map when the factors are different.
https://drive.google.com/open?id=1sustJDcEGHbF0eS4cpHjenScK7W_IUN6 Blend file. 1.2mb.
https://drive.google.com/open?id=11rXojREXfPnyCPfSDdP5TcFS27YDpaua Exporter glb. 10mb.
https://drive.google.com/open?id=1-tz8DlKJkCi1QkIv1Cs9SziJ3f_aSGd6 Import/Export glb. 200mb.
Here's the node setup I've been using.

Normal maps looks like they all exported at 1.0. I set the Normal Map strength at 0, 0.5, 1.0, 10, 100 and they all looked the same, around 1.0.
Import/export

Exporter

Roughness maps don’t export. If a roughness map is connected to principled BSDF it looks like it sets to 1.0 and with no unique features its just flat roughness. If no roughness map is connected then you can adjust the factor 0 to 1.0 fine.
Import/Export. No normal map, Roughness at 0, 0.5, and 1.0.

Exporter. No normal map, Roughness at 0, 0.5, and 1.0.

The mapping node doesn’t rotate. I also had this problem with the exporter in 2.79b. The connected mapping node doesn’t effect my texture in anyway, rotating 90 degrees worked in the rendered view but not on export. I didn’t check scaling but I don’t think that worked for me either.

The UV map node didn’t seem to do anything. Putting the UV map into the normal map also doesn’t seem to have any effect. I don’t know exactly what it’s supposed to do. Overall nothing changed on export if I had UV map and Mapping nodes connected to my texture image nodes or not.

[donmccurdy]

The increase in file size is (at least partly) a known issue, see https://github.com/KhronosGroup/glTF-Blender-IO/issues/130. The rest of this I'm not sure about but does sound like a bug for sure. Thanks for reporting this, and for the test cases. 👍

[ghost]

@ankervold Can you please also attach the used textures?

[ankervold]

https://cc0textures.com/view.php?tex=WoodFloor08
I used the 2K download.

[ghost]

I am able to reproduce this. What's interesting is that the output totals at <10MB if I select the separated glTF instead of glb.
To be continued…

[ghost]

One problem seems to be that you have a separate material for each of the cubes even if the materials are all identical. If I make all cubes use the same material, the output glb is just 13MB large. This might still be a bug though – if it's creating duplicates of the textures for every material, we should fix that.

[ghost]

Keeping in mind that we want to have a 1:1 mapping of all Blender objects if possible, here are my thoughts, presented in a minimal reproduction setup:

Blender side (= desired glTF side)

• we have m materials
• every material has one texture
• we have m textures in total
• every texture references the same image (=uri)
• we have one image in total

Current glTF side

• we have m materials
• every material has one texture
• we have m textures in total
• every texture references a different image (in separate glTF, they all have the same uri, but are still different JSON objects)
• we have m images in total

We need to create exactly one image object per actual image being used in Blender. This would solve the problem in glb and embedded glTF (fixing it in the buffer views would only affect glb) and it provides the best mapping of blender properties in the glTF.

[donmccurdy]

We need to create exactly one image object per actual image being used in Blender.

Agreed, I think that's the right change and merging materials should be out of scope. 👍

[robertlong]

We are also seeing large file sizes when exporting. In our case it's not due to exporting duplicate textures but instead re-encoding optimized textures.

We are running all pngs through optipng before we use them in Blender, this results in a decent reduction in file size. However, we lose all of those optimizations when exporting from Blender. It looks like Blender is converting all textures to bitmaps before re-encoding them as png/jpeg images.

It would be best if the exporter could use the original image data rather than first converting to a bitmap.

We have more info on our findings and test assets available in this repository:

https://github.com/robertlong/GLTFExporterTextureSizes

[alexey-pelykh]

1099 should enhance at least unwanted JPEG-to-PNG cases

[scurest]

Can this be closed? OP's problems appear to have all been fixed.

---

The final glb export file size is much larger than usual. My file size with the exporter was around 10mb

The exported .glb is now 12MB.

Normal maps looks like they all exported at 1.0. I set the Normal Map strength at 0, 0.5, 1.0, 10, 100 and they all looked the same, around 1.0.

normalTexture.scale is now set from the strength.

Roughness maps don’t export

They do now. Roughness map + roughness factor still doesn't work but that is tracked by #646.

The mapping node doesn’t rotate

It does now.

We need to create exactly one image object per actual image being used in Blender.

The export now has three images, just like Blender does.

The UV map node didn’t seem to do anything

The UVMap sets the textureInfo.texCoord field.