Texture swap incorrectly (?) accounted for when exporting modified .babylon scene from Sandbox

I was asked to swap a texture in an existing .babylon scene. I thought I would use the Sandbox for that.

Initial state: .babylon scene containing inlined texture data.

Steps:

  1. import original .babylon file,
  2. locate mesh, follow the link to the material,
  3. under ‘channels’, delete the existing Albedo texture,
  4. under ‘channels’, click ‘add Albedo texture’, and import the new texture in PNG format.
  5. verify visually that the new texture is applied properly to the model. It is! :slight_smile:
  6. under 'tools, click ‘export to Babylon’.

Problem:
If I import the modified .babylon file to the sandbox, the texture is gone. More exactly, instead of inlining the new texture data or referencing the file on my drive, both the “url” and “name” parameters are now set to something like …
"blob:https://sandbox.babylonjs.com/ab655475-8fb3-496e-91b8-b88407bf9ff2"

… and I can see that I get an error in the console:
Security Error: Content at https://sandbox.babylonjs.com/ may not load data from blob:https://sandbox.babylonjs.com/ab655475-8fb3-496e-91b8-b88407bf9ff2.

Is this the expected behavior or am I missing something?

Thanks!

Did I mention that I am stubborn? One lunch-break later I tried something slightly different.

Initial state: .babylon scene containing inlined texture data.

Steps:

  1. import original .babylon file,
  2. locate mesh, follow the link to the material,
  3. under ‘channels’, click on the existing Albedo texture,
  4. click ‘load texture from file’, and import the new texture in PNG format,
  5. under 'tools, click ‘export to Babylon’.

Now If I import the modified .babylon file to the sandbox, the new texture is there, as expected!

When looking at the structure of the produced file, this time I can see that there is inlined texture data present under “url”.

So… my first experience: bug or feature? :slight_smile:

It looks like a bug to me, I will have a look in the afternoon :slight_smile: thanks for the report.

No problem @sebavan , thanks for all the hard work! :slight_smile:

I’ve been playing with the Sandbox some more tonight, and I have had similar issues. I will report my findings here, as it feels all this might be related.

This time I was trying to downgrade the quality of a texture present in the same .babylon file used so far.

Steps in FireFox 78.14.0esr (CentOS 8.4)

  1. import original .babylon file,
  2. select texture to be modified in scene explorer,
  3. under ‘preview’, click ‘edit’,
  4. change both width and height, and click ‘resize’,
  5. click ‘save’; this produces an empty PNG file, but with the right dimension,
  6. close texture editor; the inspector shows the updated texture dimensions,
  7. click ‘edit’,
  8. click ‘save’; this time the expected texture file is produced (right dimensions, not empty),
  9. under ‘tools’, click ‘export to babylon’; the exported file does not take into account the texture modification.
  10. add .png extension to texture file, which for some reason was missing in FF,
  11. under ‘preview’, click ‘load texture from file’ and load the texture file created in step 8,
  12. Repeat step 9. This time the new .babylon file takes into account the texture modification.

Similar story in Chrome version 93.0.4577.82, except for the following:

  • the .png extension is added automatically,
  • once the correct PNG is generated (on second attempt in Chrome too), it is about twice as large as the file generated by FF.
  • this size difference seems to cascade once the files are imported back to the scene: when diff’ing the babylon scenes obtained in Chrome and FF, the ‘url’ field for the modified texture contains about twice the data in Chrome.

I cannot share the files that I am working on, but if you can’t reproduce the issue, let me know and I will try to produce a stripped down version of the original file.

I hope this helps! :slight_smile:

Fix for the serialization and @DarraghBurke it sounds you have a customer for the texture editor :slight_smile:

I am able to repro the issue with resizing then saving. Taking a look now :slight_smile:

1 Like

PR is open to fix this: Fix resize->save bug in texture inspector by darraghjburke · Pull Request #11191 · BabylonJS/Babylon.js (github.com)

Will let you know when it’s merged :wink:

1 Like

Both Seb’s serialization PR Fix blob texture serialization by sebavan · Pull Request #11188 · BabylonJS/Babylon.js (github.com) and mine are now merged, his was before the nightly so you should see the serialization problem resolved right away, mine was afterwards but it should be live shortly :slight_smile:

1 Like

Awesome @DarraghBurke , I’ll test tomorrow and report here!

1 Like

@sebavan thanks for the fix! I can confirm that the first issue I posted about is gone, at least in FF :slight_smile:

@DarraghBurke unfortunately I still have the same issues described in my 3rd post (both in Chrome and FF). I guess your fix should be live by now? If not, do you know when I should try again? Let me know if I can assist you with the troubleshooting. Thanks!

1 Like

Yes, looks like the changes are not yet live. @sebavan can probably tell us when we can expect to see them :slight_smile:

Should be all live by now

@DarraghBurke , I finally got a chance to test again tonight.

Saving a texture to disk directly after an edit does work now, at least in Chrome. :slight_smile:
However I still experience the second part of the issue, both in Chrome and FF : the changes made to the texture are discarded when I export a new .babylon file.

1 Like

Thanks for updating us :slight_smile: Sorry, I didn’t pick up on this issue the first time. Looking for a fix righ tnow!

Hey, quick update: I found the cause of the issue and have opened a PR to fix it. However, we’re not sure if this is the right approach to go with and need to complete some tests first. I’ll let you know as soon as we’re done :slight_smile:

1 Like

Sounds good @DarraghBurke
I had the 3D artist downscale the textures for us, so as far as I am concerned this is no longer high prio. But I think it will be a handy little feature to have. Keep up the good work! :slight_smile:

1 Like

Glad to hear you found a solution :slight_smile: The PR is now merged so it should work correctly once the next build is out: Fix serialization of edited textures by darraghjburke · Pull Request #11266 · BabylonJS/Babylon.js (github.com)

1 Like