Sandbox - only export the imported object

Hi All

Am I missing something here…?

So I export a model with one material that has 4 textures from blender and the .glb is 600k . Great.

All except the blender principled shader has no AO slot , so I was mixing it into diffuse via a mix node. Obviously that wont export.

So I remembered the sandbox had features to export glb. So I drag the model into the scene , add the AO map in the exporter and then when going to the export option I was already bothered by seeing the title “export scene”

Of coarse when I clicked that … it did exactly that. Exported the entire scene with cameras and skyboxes and the toot. and the resulting .glb was now 4mb big.

I have a heap of assets I need to prep to make ready for selective import into a app scene. I definitely dont want each glb to be a whole scene that is 4mb.

I have a model , I want to edit it , give me back the edited model. Nothing else.

I’m honestly baffled why this was not the first thought of option when developing this tool , at least to me it seems the most obvious use case.

No offense to anyone off coarse.

If somebody knows of a solution to this I would be very thankful.


Adding @Drigax who might know a trick ?

Only trick I can think of off hand is to add a flag to our Node implementation that marks whether or not to exclude it and its subtree from export. Shouldn’t be too hard to implement, but not sure if you can think of something better? Maybe “exclude default assets?” but that may also need some finagling in all our default asset construction to make sure that we know what we’re adding on our end.

Other than that, @shaderbytes you can script your scene to delete all unwanted data before export.

you must mean via the playground? Im sure you cant script the sandbox entity itself. I know the playground can script and that the viewport also has the same inspectors as the sandbox … it probably just is the sandbox haha.

ok so I found this code to load my external model :

var delayCreateScene = function () {
    var scene = new BABYLON.Scene(engine);  

        function (meshes) {          
            scene.createDefaultCameraOrLight(true, true, true);

    return scene;

what hook is there to run the deletion of unwanted assets when clicking export scene in the inspector of the viewport/sandbox here?

I added glb to my htaccess CORS and the model loads no issues. I also added the ao texture to the material but when saving the link to share with you it seems to not save the edits I made , thats ok with me , just so long it works for that moment on export i will be happy.

anyway here is the playground :

here is the texture Im adding for AO :

I hope we can get this working :wink:

I tried this :

var delayCreateScene = function () {
    var scene = new BABYLON.Scene(engine);  

        function (meshes) {          

    return scene;

So it wont create anything besides the loaded model, this resulted in a blank viewport but the model was available via the inspector. This got me excited so I added my AO texture and tested exporting , but the export was still ~4mb.

I noticed if I expand the textures in the inspector there is still an environment texture in there. Since my model is only 600k , it means that texture is 3.4mb, I cant think of a way to remove it:

one moment , i found this in the blender docs now :

glTF is capable of storing a baked ambient occlusion map. Currently there is no arrangement of nodes that causes Blender to use such a map in exactly the same way as intended in glTF. However, if the exporter finds a custom node group by the name of glTF Settings , and finds an input named Occlusion on that node group, it will look for an Image Texture attached there to use as the occlusion map in glTF

let me give that a spin … might resolve the issue at the source :wink:

EDIT : It worked!

For anyone else looking into it , I found the info on this page :

created the custom group hooked up the AO and boom all is good. Tested in sandbox and the AO is there


thanks for everyone’s time

1 Like

Glad to hear that you found a workflow that works for you. Looking at your original glb, I can see that it was created using jpg textures. We don’t re-compress the textures when exporting from babylon, so the increase in filesize looks like its caused by that. It doesn’t look like we include the environment texture in export, however.

Yes , I looked at the size of the one environment texture remaining after that code experiment and it is very plain and only 256x256 so it could never be the remainder of the file size as I first suggested.

Not that it is an immediate matter to me now , but I would think this is something to look into right? injecting a ~600k .glb and getting back a ~4mb one, is not ideal at all … that like a 680% increase in file size!

If the Development team has some sort of list of things to look into when doing the next planned cycle of feature additions or bug fixes , maybe these two things could get added.

  1. Have functionality to easy export a scene without the addition of the sandbox specific items.

  2. Look into texture compression. I mean if other tools , like blender can do it, im sure they can :wink: ( well , its not blender directly, it is actually the khronos plugin addon although from yesterday’s discovery in the blender docs, this addon looks to be a part of the blender build now since it is officially documented ) I was surprised to find that since I knew before this option was not there. SO it must have been added to the exporter at some point.

chat soon

Just an FYI, for those using the JSON / .babylon exporter accomplishes AO using the Red channel of an AO-metal-roughness texture. I have no experience in baking such a texture, but I think there is a topic a while back, where someone did.

Here is how it is hooked up:

Bringing this up since, it is one of the few differences between switching between exporters, and there are very few topics on the subject.

This was about exporting a loose AO texture into a GLTF/GLB. Be it from blender or from babylon sandbox.

I posted that I found a solution, I even I shared the info from the blender official docs to achieve exporting AO info GLTF/GLB using a standard node set up with one extra trick - that is the solution.

The above node setup is using a pre packed metalness/roughness/AO texture as input. So slightly off topic but thanks anyway.

I know this is how GLTF uses these but Im sorry but I dont want to work with my master files in a mixed channel format like above. I prefer to have them as an image per material property. The GLTF exporter will take any combination of those and the push them into the relevant channels of a single texture on export. The above is very over complicated :slight_smile:

here is my node set up. Tried and tested :

The export button should not be exporting the skybox mesh. It is exporting a skybox material (though without the texture) which shouldn’t be there. That shouldn’t cause a big increase in size though.

I tested it now to use the loading code to load the model (~600k) , added the ao , then export ( now ~4086k)

I imported that into blender now to see what it results in.

If i use the original posted loading code, which has this :

scene.createDefaultCameraOrLight(true, true, true);

In blender it does create a light, named “default light” and a object named “BackgroundHelper” with a child mesh named “BackgroundPlane” but it has no material assigned. There is only the one material available to select from which is the material which belongs to my object.

The BackgroundPlane is a floor plane/shadow catcher by the looks of it :

If I remove those two lines then indeed, on babylon export - blender import - the scene is only the intended object and material.

What is interesting is that the babylon export does not write the added ao texture into the already existing ao/roughness/metalness textures r channel. It writes it as a loose texture.

So the blender import sets up a custom node group for this , like I discovered yesterday , which is not even targeting rendering but is set up for exporting, notice the top , this is the AO plugged into the custom named node group :

So anyway from there I tried another export out of blender. This resulted in a (~3540k) glb

I tested exporting the packed textures and indeed they are the culprit. So as @Drigax said , it is due to not compressing the textures again on export from the sandbox.

Babylon has all the original image data from the load or the texture additions made in the inspector… it should just pack those originals and additions. Unless the unpacking is a destructive process on the same block of data.

For interests sake the original textures on disk are 554k combined. These plus the geometry and other code bits make up the original glb.

If you can provide an example glTF/glb to import to the sandbox and then export, that will be much easier to debug. The blender part doesn’t matter for the sandbox issue.

yes it was in the code above sorry here it is :

Thanks! The biggest difference is that Babylon exports using PNGs. The source is using JPEGs. We can possibly preserve this on export or add options to export JPEGs when possible. Maybe file a feature request on GitHub?

in issues on the github I see a label named “new feature” is that the one? I presume it is I dont see another :

Create a new issue and it will have a template that you fill out. :slight_smile:

Awesome all sorted :slight_smile: