I recently attempted to update several of my programs from r167 to r168. However, they are either running incredibly slow or giving odd errors, such as that for the first line, i.e.:
<!doctype html>
“A valid external Instance reference no longer exists.”
This is odd because others who have updated the same programs have had no problems.
I suspect that the issue may be that my GPU is no longer able to handle all the improvements made to the WebGPU renderer version of three.js. The GPU I am using is at least 5 years old - a NVIDIA GeForce GTX 1060 3GB.
Could that be the problem? If so, what kind of minimum or optimum GPU would everyone recommend for working with WebGPU?
A FINAL NOTE:
Thanks to everyone who contributed.
After several days of research, I have determined that there is a difference in the way r168 handles shadows. However, I was able to minimize those differences by taking the following steps:
Don’t use a large shadowMap (e.g. 8192)
Minimize the number of objects which receive shadows.
With regard to the second point, My programs create a large surface (the Ocean) using nested scrolling grids which contain individual planes: the inner grid contains the smallest planes, the middle grid contains larger planes and the outer grid contains the largest planes. For r167 and earlier, I had set “receiveShadow = true” for all of the planes in all of the grids, even though my object would never cast a shadow on the planes in the middle or outer grids. The program now sets “receiveShadow = true” only for the planes in the inner grid.
These two changes reduced CPU and GPU usage enough for my programs to work at 60fps on my CPU. The usage meters still shows that r168 has clearly increased the GPU usage and there is an odd sawtooth pattern that wasn’t there with r167. The image below shows how this looked before I made the second change (note that r168 affected both CPU and GPU usage):
It might be completely unrelated to your issue, but this is just to express my personal experience of WebGPU instability issues since I migrated code from r167 to r168, and from three.module.js to three.webgpu.js.
When I edit a program, reload the browser page, and repeat this 20-30-40 times, the browser crashes in a variety of ways (becomes unresponsive, or prints some message that something with the GPU could not be initialized, or shows a dialog with some issue that I cannot relate to my code). This happens irrespective of the browser, and irrespective of whether it uses WebGPU or WebGL2 fallback. I have never experienced such types of browser crashes before.
I have not filed an issue at Github, because:
I’m still not sure this is related to WebGPU of r168 or to Three.js in general
I’m unable to reproduce the issue, it happens out of the blue, usually 2-3 times a day of heavy coding
The good news is that when I close and restart the browser, the same WebGPU program works fine. No need to restart the computer.
I’ll keep an eye on this and will try to collect more details.
I am going to get a new GPU and see if that solves the problems I am having with r168. As someone pointed out to me, the GPU I am using predates WebGPU.
When I modify or create a module (which I save to my repo), I sometimes have to hit a hard reload (CTRL+reload) followed by a soft reload (reload only) or two to get it to work the first time. I have always assumed that this is because I need to revise my initialization procedure to agree with the three.js examples. But, perhaps it is also due to “growing pains” with WebGPU.
I’m glad that you are also working with WebGPU. It seemed pretty lonely out there for awhile with most people still using WebGL and very few online tutorials discussing programs using WebGPU and NodeMaterials.
My old GPU handles that. It also handles my Ocean module on a small scale. It stumbles when I create a large scale version that involves spreading textures across multiple meshes. It dies when I load several large animated objects.
Normally, I would dig into my code and try to determine where the problems exist. But another programmer took several of my r167 examples, changed a couple of lines and converted them to r168 where they work perfectly for him. So I have to assume that my problem is a hardware issue. (By pure coincidence, our modem crapped out and I got a new one, so there should be no connection issues.)
If a new GPU does solve the problem, that may mean that (1) WebGPU will not work with certain old GPUs; or (2) there are issues with the current version of WebGPU that are being masked by the greater capabilities of newer GPUs. I assume those will be resolved over time. In the meantime, I don’t mind having an excuse for getting a new GPU.
If you would try my standalone GLTF WebGPU viewer, found on the bottom of this post, and change r167 to r168 in all applicable spots (5 spots) then you could notice an error after loading some GLTF model that THREE.NodeMaterial.fromMaterial() function was removed.
Even if the sections with this function are commented out in the code then some new warnings will appear about MeshStandardMaterial and MeshPhysicalMaterial not being supported.
There could probably be more errors that might appear depending on what code in this viewer is changed.
EDIT: Just changed some code in this viewer and it is currently using r168.
Here is the r167 version of my program which runs at 60 fps on my PC.
Here is the r168 version which runs at 60 fps on my PC.
The only changes I had to make for r168 were to the emitter.
I am not asking anyone to dig into the code. I am just interested in whether both versions are running at the same speed for people with newer GPUs. I am also interested if any new error messages pop up with the r168 version…
Wow, i get 4 fps on a 2080ti, this thing ran doom at ultra a few years back. I played cyberpunk on it. An airplane, above a plane, should not cause 4 fps on this machine. For some reason i cant activate specter.
I can’t really find my way around the code and i dont know what renderer.compute does, but it seems to me that you are drawing to many many textures. Eg that one loop says “9” in one direction. If you are also reading every pixel during these times, that would explain the 4fps.
Is there a reason to use the https://unpkg.com over https://cdn.jsdelivr.net/npm?
Even three.js switched over and in my area I usually have to wait a bit for downloads from the unpkg.com.
In Chrome browser on mac mini M2:
both r167 and r168 show:
repeated error upon loading: Uncaught TypeError ... sunflare.update is not a function:
this might be happening just before the sunflare is constructed and the render loop is firing early
all controls appear to be working properly
variable FPS is between 38 and 60 depending on:
rotation and zoom
more of the ocean in the window lowers the FPS
more of the sky in the window increases the FPS
r168 also shows a warning that for context.getImageData (line 568 in html) you should set the willReadFrequently attribute to true for Canvas2D, which might be similar to this:
let context = canvas.getContext( '2d', { willReadFrequently: true } );
I use unpkg.com because it works. But I would be glad to switch to something that is faster.
Yes, the SunFlare error pops up, probably for the reason you suggest. You can do a “soft reload” to make it go away (it is the routine that creates the two white dots).
I am getting a solid 60 fps in all directions - but only for the r167 version.
The context warning relates to my use of context to split textures apart during the initialization process. I do not use it during runtime.
The fact that you are getting similar fps for both r167 and 168 seems to indicate that the GPU is the problem.
Is your 2080ti an older version? It looks like they have been making them for years and are still making them.
Yes, the ocean is more than a simple plane. It consists of 3 groups of meshes of two different sizes. The meshes for the inner group consists of animated geometries - which are repeated using displacement textures - and their associated normal maps. The diffuse textures for each mesh are extracts from a larger texture. So there are several unique meshes. The meshes for the next group are similar but don’t use a displacement map, only a normal map. The meshes for the outer group use a fixed normal map (repeated) and a full size diffuse texture. (I am a little fuzzy on the exact details since I haven’t looked at it in awhile.)
This may all sound like a lot, but it works at 60fps for me in r167. (You can go down to low level and click on the “-” key to slow the airplane down to 50 mph to see the Ocean in action.)
ADD
Just to confirm - did you get significantly better fps with r167 than with r168?
You should try using keyboard controls instead of the screen controls - they don’t seem to be working the same.
Tapping the up arrow key on the keyboard will have the plane nose dive at different rates depending on how many times you tap this key.
Tapping the down arrow key on the keyboard will have the opposite effect and you should tap it as many times as you tapped the up arrow key to stop the descent once you reach the desired altitude.
Yes, that version is just supposed to show that the ocean looks good at a higher altitude - where tiling might otherwise be a problem. The textures help prevent that problem.
I have other versions on my GitHub repo (a model demo and a flight demo) where you are closer to the waves and in a much more detailed aircraft. But those would probably not work on your machine in either r167 or r168. They work fine for me in r167, but not at all in r168 (see my first post).
Just for comparison, here are links to a couple of r165 programs that used WebGL and NodeMaterials - the last revision where you could do that (NodeMaterials now work only with WebGPU). The r165 example similar to the above.is here. And an example with a detailed model is here. (You may have to reload a few times to get them to work. But I just checked and they still work for me.)
