Hi everybody.
In the web configurator I’m developing now:
-
I’m importing a GLTF with a size of 396KB plus other 805KB for the BIN file, having so there a total of around 1MB;
-
I’m attaching the three PBR textures channels to two materials, having so six textures for a total size of around 1MB;
-
Then I use BABYLON.GLTF2Export functionality and … the result is a GLB of about 20MB
How can It be that 1MB + 1MB = 20MB?
Even more weird:
-
Now, I open that 20MB GLB file within the BJS Inspector, looking for some clue of the inflated size (as could be duplicated nodes), but all is OK;
-
Exporting then from Inspector, the resulting GLB file have a size of only around 2MB, that is the size I were expecting from the BABYLON.GLTF2Export.
What can be happening here? Any tip about where to start looking?
Thanks for your time.
1 Like
Can you provide a repro in the playground ?
Your versions might be different between inspector and your in code once ?
The inspector only does this:
with
i know there was an issue before that imported jpeg files get exported as png … could this not perhaps be the issue again?
1 Like
Hi there @shaderbytes:
I’m using not compressed PNG in my PBR material channels (the ones with sizes around 300KB each aforementioned).
I suppose that in the case the exporter is embedding them instead as JPEGs, it would be always a smaller size than PNGs.
Thanks for your time.
i didnt say that
I said there was a previous issue where it took jpeg source images ( embed in the loaded glb or loaded into the editor ) and when exporting, converted them to png … thus making the exported glb bigger ( mostly ) but that got fixed
Something else to pehaps check , if these are simple png files color wise but big in dimension and they get converted to jpeg on export , that wont make it smaller , jpeg is not always smaller than png , in that case they will be bigger.
worth investigating because with that kind of file size jump I can only imagine it is probably due to some image files not being handled correctly, not any other data in the glb
1 Like
Hi there, @sebavan:
Please, find here a PG with a “really simplified” example of the issue.
Here, as the asset is tinier, the difference between size of loaded asset and exported one is small but anyway it shows that the size is doubled (from 800KB to 1.4MB).
In my production code, I have the door in a room (that is of course the model what weights more, by far, in the scene), but I only want to export the door. I do that using the options’ shouldExportNode parameter, as I can check opening the exported GLB in (by example) the BJS Sandbox.
Said this, I’m starting to thinking that even when not shown in Sandbox, all the model buffers, even the ones from the room that I mark as not to export, are indeed exported, as the size number of the GLB correlates pretty much with such a scenario.
That is, when I export only the door I get more or less the same exported GLB file size (~20MB) than if I export door+room, even when not room at all is present in the Inspector’s scene breakdown of the exported file, as is shown in the Inspector. When I export that 20MB file scene from Inspector, it shrinks again to the 800KB of the door.
Any thoughts on all this?
thanks for the repro, I can now bring our GLTF expert @bghgary in the thread
Hi, @sebavan:
This issue is related with this other thread I was commenting with @bghgary last week.
Looking at the code you’re bringing here from the export in Inspector, maybe I must forceUpdate (what API is this?) before glb.downloadFiles?
forceUpdate is for the UI nothing related to the upload.
1 Like
Original (babylon.js glTF exporter for Autodesk Maya 2018.5 v20220518.1):
Exported (Babylon.js v5.50.1):
The meshes are duplicated because the Babylon.js exporter isn’t currently smart enough to reuse meshes. This can be fixed in the exporter if someone is willing to try to implement.
The textures are bigger because the web PNG exporter doesn’t compress as well as the native version. I don’t think there is a fix for this unless we use some third-party library to create the PNG. Currently, it is up to the browser what compress setting is used to generate the PNG.
2 Likes
Hello, @bghgary:
But the Inspector export implementation is not inflating the size of the exported GLB, as the call to the API (by code, I mean) does.
I’m going to try to make a more specific PG of the issue and will come with it as soon as possible.
BTW, what tool have you employed for the screenshots you’re providing?
Thanks for your time.
Here is what the inspector does when it exports: Babylon.js/toolsTabComponent.tsx at master · BabylonJS/Babylon.js (github.com). All the options are false by default.
I’m using glTF tools for vscode.
1 Like
Hi there again, @bghgary (and @sebavan ):
Thanks for your info. From that, I think I’ve finally “catch” what is happening with my code.
The case is that inside the shouldExportNode parameter, I’m having an erroneous filtering, so I’m exporting more nodes than the ones I need to. The case is that I’m filtering out some parent nodes, but not their children.
What have being obfuscating to me this behavior until now, is the fact that the Inspector is not showing orphans nodes, I mean nodes without its parent node being exported in the first term. Is that possible? It would explain that I get an inflated file.
Anyway, when Inspector export that inflated file, I think it is skipping all those orphans nodes, and so I get finally the expected (by far) more small file size.
Does all this any sense for you?
I’m not sure I understand what you mean. The shouldExportNode
is fully generic, so you can do whatever you need to. Are you asking how to not export nodes whose parent is not exported? Maybe this thread will be useful?
1 Like
Hello @bghgary:
I apologize for my, certainly, not very clear redaction.
What I meant is that I suspect the Inspector doesn’t show orphans nodes (that is, with an ancestor not present in the scene, in my case because it has been filtered out) so if you look the node tree it can mislead you in the search of where is going all that extra-size of a GLTF/GLB.
That extra size is going to nodes that Inspector is not showing at all. Not even the node tree. Is this assumption true?
The exporter looks at all transform nodes, meshes, lights, and cameras under the scene given to it. I believe we show all of these in the inspector. Do you have a repro?
Hi, @bghgary:
Finally, I’ve managed to “at least” export the nodes I want to, filtering off the others.
Anyway, reviewing the size of the files and the polygon count I’m obtaining, I wonder if the exporter is keeping the instances “as is” or, instead, it is creating new copies of the geometry.
Thanks for your time.