Stuck for a while when loading a cubemap

Questions
1

Is there any way to minimize the lag when loading a new cubemap?

I’ve tried using several methods for example using tasks as I did in this sample:

If you press ‘space’ there you’ll notice that the animation will be stopped for a while.

My suspicion is that this happens when running GPU transcoding since using Basis format it does not happen, however Basis format continues to break colors and gradients so it is not usable.

Is there any chance to calculate the loading on a background thread and continue the animation meanwhile or something like that?

Thank you!

2

As the images are loaded and decoded on the main view thread. You can see it in the profiler:

image
image1052×858 132 KB

There is little that can be done here. I am trying to think if it is possible to decode the image in an outside thread, but webgl is running in the main thread, so I can only assume it will bring nothing.

3

So it seems that it decodes each face before creating the cubemap it has sense but I wonder if there is any way to make the cube in Ram before transcoding so you only need to transcode once instead 6 times.

As I said basis files are needed to be loaded and so, and they have no this issue, that’s why I suspect that transcoding is they key.

Anyway is there any other alternative than Basis (it is really a pity about the loss of quality and yellowish colors and dds files are so large) to make it smoother?

Thank you!

4

Have you tried .ktx2 files? You can choose to use UASTC for better quality (I don’t know if it’s available for .basis file…).

1 Like
5

Unfortunately the problems are pretty visible:

6

I must say I don’t see the differences in the pictures in your link…

7

Please check them at 100% (including the lossless compression)

Notice the issues on the dark gray bar as well as the yellowish banding effects around the lamp fixture, maybe they are not so noticeable on mobile devices but pretty neat on computers.
Comparative

They are not related to Babylon but the Basis system itself since compressing png->basis->png has this issue too.

Regards.

8

@RaananW @Evgeni_Popov A user on “the other side of the force” guided me to make this:

My suspects were right and decoding took most of the time, it seems that there ImageLoader has the same problem but ImageBitmap can decode it asynchronously, is there any way to make something like that in Babylon?

In the sample, you can press 1 for using the ImageLoader (same issue than using Babylon) 2 for use ImageBitmap, and 3 to reset.

Thank you!

9

You can force using ImageBitmap by doing engine._features.forceBitmapOverHTMLImageElement = true:

This way, the loading task won’t take more time than in Threejs:

Babylon.js:
image

Threejs:

image
image611×540 16.3 KB

3 Likes
10

:heart_eyes: What are the disadvantages of this system?

11

I don’t think there is any :slight_smile:

We added this flag for WebGPU because we needed to use ImageBitmap everywhere possible, but to avoid changing the way we handle WebGL we set it to false by default for this engine.

1 Like
12

@Evgeni_Popov Just FYI svg files are not loaded with forceBitmapOverHTMLImageElement = true

13

And your cubemap is made with svg? Or are you just challenging (fair enough)?
Though, I believe an svg would not be of such size and the lag would remain minimal, no? Depends of course on what your svg is made of? Can’t help but wondering :thinking:. May be you could share this use case so we can figure? Meanwhile, have a great day :sunglasses:

14

Indeed, forceBitmapOverHTMLImageElement = true is not supported for svg files because browsers don’t support creating an ImageBitmap from a svg Blob.

1 Like
15

I supose that unfortunately there is no way to load some textures in advance with
forceBitmapOverHTMLImageElement = false (the icons)

And the rest of textures with
forceBitmapOverHTMLImageElement = true

right?

16

You can change this setting at any time, so you can set a value, load some textures, then change the value and load some other textures.