Problems with rendering on Mac OS

[aliakseikalosha]

Having issue with rendering in Firefox web browser runing on my Apple Macbook pro with Intel CPU. Only first chunk render prorperly as you can se on the image:
If I edit mesh it aslo geting corrupted. Physics and interaction with ground work. Safari and Chromium was geting error in WASM, so they can't even start the demo.

[DouglasDwyer]

Thanks so much for reporting this issue! As I am currently a one-man team, I have not been able to test on that many devices. No testing has been done on Mac OS. Thus, all of the input helps! Would you mind posting the WASM error that you're receiving, and also providing the errors in the Firefox developer console? That way, we can narrow down the source of the problem. It definitely looks like a memory corruption problem. It probably has something to do with the buffers and textures in which data is stored. If it's not too much trouble, could you also post the results of visiting this website? It provides information on the computer's WebGL capabilities.

[aliakseikalosha]

Errors in Firefox

Errors in Safari

SyntaxError: Unexpected token '*'. import call expects exactly one argument. (anonymous function) — octo.js:1

This error points to that line of code:

import * as __wbg_star0 from './snippets/wasm_thread-c298f0aa2b1e5b23/src/module_workers_polyfill.min.js';

Unhandled Promise Rejection: CompileError: WebAssembly.Module doesn't parse at byte 920: can't get 1th argument Type

Errors in Chromium

Same first one :

Uncaught SyntaxError: Cannot use import statement outside a module

and the next one

Uncaught (in promise) CompileError: WebAssembly.instantiateStreaming(): invalid value type 's128', enable with --experimental-wasm-simd @+919

Results for Firefox

Results for Safari

Results for Chromium

[RedNicStone]

Seems to me like an issue involving unbound GPU memory. Taking a closer look with RenderDoc it seems like @DouglasDwyer is using heterogeneous bindings. Opposed to homogeneous bindings where all resource bindings are updated with every new command buffer, they are only updated when an update is needed, which is good practice if you are going for performance. I also confirmed this using an objdump on the binary (could the source be provided in the future maybe?). This issue seems Metal specific as I'm not having any problems when using Zink on my own pc. One solution would be to simply update all bindings when the target is MacOS (of course this would negatively impact performance). I've tried replicating this issue on my only two apple devices (one 2012 and one 2019 iPad) but they don't seem to support WebGL in any meaningful way. Hope this helps with the issue.

[DouglasDwyer]

@aliakseikalosha, these detailed screenshots are extremely helpful - I really appreciate it! There appear to be two separate issues at play here:

1.) If I'm reading your WebGL stats correctly, both Safari and Google Chrome are multiple years out-of-date. I'm taking advantage of the latest WASM features, so it may be that your browsers are too old for me to support. This is exemplified by the --experimental-wasm-simd error in Chrome; SIMD support is now enabled by default. Given that the error is reported at position 919 on Chrome and 920 on Safari, I am guessing these are the same issue. Update your browser and see if that helps.

2.) Based upon your WebGL results, it looks like your computer should be well capable of running this demo. I will have to spend some more time digging and testing on Mac when I can get my hands on one. Nothing sticks out to me at the moment; the Firefox developer console looks normal to me. Perhaps if you update Chrome, you could let us know how that behaves.

[DouglasDwyer]

@RedNicStone, I'm flattered by your interest in my project - it's super cool that you were able to use RenderDoc, as it's not something that I've tried with the WASM version of the game. It's possible that the issue we see here is with Metal; I wonder if the ANGLE implementation would behave differently than the Firefox WebGL backend. Bear in mind that I am writing my code for the WebGL abstraction, so I don't actual control how command buffers are created. RedNicStone, did you specifically see something in RenderDoc that shows Firefox isn't correctly binding textures? The screenshots shown do make it look like the GPU could be drawing garbage. However, for such a small render distance only one 3D texture should be in use, and since the first chunk renders correctly, you would think that the rest of the texture would also be accessible. I wonder if this is actually a problem with how glBufferSubData or glTexSubImage3D behave on Firefox/Metal.

[aliakseikalosha]

@DouglasDwyer @RedNicStone It is unfortunate but render dog is not avaliable on Mac OS only Windows(32-bit and 64-bit) and Linux (64-bit) are superted base on webpage download section.

@DouglasDwyer

Safari has uptodate version 15.6.1

Chromium is Version 88.0.4292.0 so it was pretty old will try to update it

After update it was working with problems after 5 to 10 seconds it just stop rendering the world, no voxels where visible, so I cant get good screenshoot.

WebGL stats of updated Chromium

If you need someone to test on Mac OS would like to help with that.

[RedNicStone]

@RedNicStone, I'm flattered by your interest in my project - it's super cool that you were able to use RenderDoc, as it's not something that I've tried with the WASM version of the game. It's possible that the issue we see here is with Metal; I wonder if the ANGLE implementation would behave differently than the Firefox WebGL backend. Bear in mind that I am writing my code for the WebGL abstraction, so I don't actual control how command buffers are created. RedNicStone, did you specifically see something in RenderDoc that shows Firefox isn't correctly binding textures? The screenshots shown do make it look like the GPU could be drawing garbage. However, for such a small render distance only one 3D texture should be in use, and since the first chunk renders correctly, you would think that the rest of the texture would also be accessible. I wonder if this is actually a problem with how glBufferSubData or glTexSubImage3D behave on Firefox/Metal.

I find your project very interesting as for the performance is amazing. I've written a couple share of voxel engines in the past, the best of which was only scraping by at 12ms per frame when rendering 10 gigavoxels which would be fine if not for the amount of "hacks" used.

For me, on Linux, the demo runs fine on both Firefox and Iridium (Chromium). I was able to attach RenderDoc to a Firefox instance to view the render buffers (the call chain here is presumably octo->webgl(->gecko)->gl->zink->vulkan->renderdocvk->drm->nvidia). I was not seeing anything obvoius going on that would explain the issue. The reason I believe it to be a binding issue is simply that one chunk is visible (probably the one that is first loaded). What might happen is that the first chunk is loaded into memory and the buffer resized and rebound to fit more chunks. The driver or Metal or what else is not registering the new bind (likely since the resource is to new or other reasons) and sticking with the cached old one. Another piece of evidence that would speak for such an issue is as mentioned before is the usage of heterogeneous bindings. However I can't determine what the reason for these bindings is. Since the GL is first translated to Vulkan in my setup I just see a very inconsistent use of bindings on the Vulkan side which Metal might not support in the same fashion. This might be due to glBufferSubData or glTexSubImage3D or something completely different.

I for one do not think the console errors have anything to do with the issue. I'm getting quite the same errors even when just running it in plain Firefox:

@aliakseikalosha Could you by any chance look up your GPU here, ruling out any hardware incompatibilities early on might help.

[aliakseikalosha]

@RedNicStone Apple Mac OS support OpenGL up to 4.1 but it looks like browsers using OpenGL ES 3.3(Firefox) and 3.0(Chromium). I cant find exact GPU on this site but closest is https://opengl.gpuinfo.org/displayreport.php?id=4070 but it is pass throw Pralells VM. My GPU is https://www.notebookcheck.net/AMD-Radeon-Pro-555X-MBP15-2018-GPU.328958.0.html

I have played with a OpenGL (4.1) and WebGL(1.0 and 2.0) on my pc and basic stuff worked as it should be. If you have any demo I could try I can try to run it.

[eKoopmans]

Just chiming in - the demo works fine (though a bit slow, and definitely running hot) on my Macbook Pro 2019, Chrome 104.0.5112.101. The engine is very cool, keep up the awesome work! 👍