The WebGPURenderer causes the browser to crash while loading the glb model

[mlt131220]

Description

I found that when I used WebGPURenderer to load the glb model, the browser would crash. Under webgl is normal!
I made a simple example,see: web-gpu3d-preview

Reproduction steps

1. init WebGPURenderer
2. GlTFLoader.load("XXXX.glb")
3. WebGPURenderer.render()

Code

// code goes here

Live example

web-gpu3d-preview

Screenshots

No response

Version

r154

Device

Desktop

Browser

Chrome

OS

Windows

[Mugen87]

Do you mind sharing your code at GitHub? The zip download at gitee only works with an account and the clone via git takes ages because of a low downloading speed.

[mlt131220]

Do you mind sharing your code at GitHub? The zip download at gitee only works with an account and the clone via git takes ages because of a low downloading speed.

I've shared it on GitHub,see:WebGPU3dPreview

[Mugen87]

Your model has 80.000.000 faces and produces 16000 draw calls. I'm not surprise that this model crashes the renderer.
I'm sure the WebGL version will also crash on low and mid end devices.

I suggest you simplify the model and try again.

[mlt131220]

Your model has 80.000.000 faces and produces 16000 draw calls. I'm not surprise that this model crashes the renderer. I'm sure the WebGL version will also crash on low and mid end devices.

I suggest you simplify the model and try again.

The same model is not stuck on the WebGL version, at 60ms at frame time, but crashes when opened with WebGPU and called render() method. I looked on the console and found that the render function keeps executing when I'm not rendering, which I'm sure I didn't call.

[Mugen87]

Do you mind reproducing the issue with a smaller asset?

[mrdoob]

The same model is not stuck on the WebGL version, at 60ms at frame time

What GPU is that with?

[mlt131220]

The same model is not stuck on the WebGL version, at 60ms at frame time

What GPU is that with?

3070TI

[mlt131220]

Do you mind reproducing the issue with a smaller asset?

Performs well in BabylonJS WebGPU and THREEJS WebGL

[mrdoob]

@sunag any ideas?

[sunag]

@mrdoob I'll be checking this out, @Mugen87 I will reopen until I'm more satisfied with the optimization results I'm working on, this PR could be a good benchmark.

[sunag]

@mlt131220 Could you test again?

[mlt131220]

@mlt131220 Could you test again?

There hasn't been any improvement. When my scene is large, using WebGL may seem sluggish, but when I switch to WebGPU, the entire browser window freezes and cannot be closed. Even after waiting for a while, the browser cannot close!

[mlt131220]

@mlt131220 Could you test again?

In my case of GITHUB, we can see that the use of WebGL is very smooth and the mapping is normal. After switching to WebGPU, Catton can not rotate and the map is lost! In the larger scene in my project, the browser faked death directly, and the browser can only be closed from the Task Manager!

[sunag]

I found the main problem, it is still related to the NodeBuilder cache, the optimization will have to be done using customProgramCacheKey() with some improvements too. Currently, if we create 3 x MeshStandardMaterial with identical settings it runs NodeBuilder 3 times, this can be a problem with scenes like this where there are a huge number of materials with the same type just with different colors. I will be working on this improvement, to keep the high customization of materials in line with this optimization.

[mlt131220]

I found the main problem, it is still related to the NodeBuilder cache, the optimization will have to be done using customProgramCacheKey() with some improvements too. Currently, if we create 3 x MeshStandardMaterial with identical settings it runs NodeBuilder 3 times, this can be a problem with scenes like this where there are a huge number of materials with the same type just with different colors. I will be working on this improvement, to keep the high customization of materials in line with this optimization.

Thank you for your reply.
I'll run the local test again after you fix it.
In the current version of R155, I used ten different types of larger scenario tests, all of which had poor performance and were far from webgl.

[mlt131220]

I found the main problem, it is still related to the NodeBuilder cache, the optimization will have to be done using customProgramCacheKey() with some improvements too. Currently, if we create 3 x MeshStandardMaterial with identical settings it runs NodeBuilder 3 times, this can be a problem with scenes like this where there are a huge number of materials with the same type just with different colors. I will be working on this improvement, to keep the high customization of materials in line with this optimization.

Is there any new progress

[sunag]

Is there any new progress

This improvement is being discussed here with others related.

[mlt131220]

Is there any new progress

This improvement is being discussed here with others related.

OK