background

I’ve recently been working on some procedural background systems for a browser-based game I’ve been working on.

The idea was to create a sort of Shadertoy-style 100% per-fragment-procedural background. The background is what displays when there’s no other actual scene object/mesh at a given pixel on the screen. So, in order to work efficiently, this pass reads from the scene depth buffer and skips all of its relatively expensive procedural logic in the case that the background won’t be visible anyway.

the problem

After upgrading my Rust toolchain to the latest nightly, I started getting errors when building a WebAssembly project of mine:

error: linking with `rust-lld` failed: exit status: 1
  |
  = note:  "rust-lld" "-flavor" "wasm" "--export" "create_terrain_gen_ctx" "--export" "free" "--export" "gen_heightmap" "--export" "malloc" "--export" "set_params" "--export=__heap_base" "--export=__data_end" "-z" "stack-size=1048576" "--stack-first" "--no-demangle" "--no-entry" "<2 object files omitted>" "<sysroot>/lib/rustlib/wasm32-unknown-unknown/lib/libpanic_abort-*.rlib" "/home/casey/dream/src/viz/wasm/target/wasm32-unknown-unknown/release/deps/{libcommon-a24e0de9c9a36cad,librand_pcg-96aa495088ea06d3,librand-dd7ab4b12369f67a,librand_core-5f1e6ad6780daf68,libopensimplex_noise_rs-29c02d98fe844459,libnanoserde-5b273dd919df410e}.rlib" "<sysroot>/lib/rustlib/wasm32-unknown-unknown/lib/{libstd-*,libdlmalloc-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-L" "<sysroot>/lib/rustlib/wasm32-unknown-unknown/lib/self-contained" "-o" "/home/casey/dream/src/viz/wasm/target/wasm32-unknown-unknown/release/deps/terrain.wasm" "--gc-sections" "--no-entry" "-O3"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: /home/casey/dream/src/viz/wasm/target/wasm32-unknown-unknown/release/deps/terrain.terrain.1508d28c2e9bb756-cgu.0.rcgu.o: undefined symbol: log_error
          rust-lld: error: /home/casey/dream/src/viz/wasm/target/wasm32-unknown-unknown/release/deps/terrain.terrain.1508d28c2e9bb756-cgu.0.rcgu.o: undefined symbol: log_error

The place in my code causing these issues was this:

The Problem

When trying to complete the OAuth flow for my web app spotifytrack.net, I started getting sent to an error page with a 500 status code and the following unhelpful message:

Oops! Something went wrong, please try again or check out our help area.

The app had been running successfully for years with no changes to the OAuth configuration. The error was easily reproducible just by visiting the /authorize URL directly. It persisted after trying incognito windows, different browsers, different devices, logging out and back in, etc.

For the past several months, I’ve been working on a programming language called Geoscript. It’s specialized for generating and manipulating 3D geometry for use in a Shadertoy-inspired web app called Geotoy.

I maintain the three-good-godrays library, which adds support for volumetric raymarched screen-space godrays to Three.JS.

The most recent version of Three.JS (0.182.0) made some breaking changes to its depth packing and shadow internals that the library relied on, and it needed to be updated in order to work with it. I figured I’d create a little summary of what changes were needed for anyone else updating similar code for newer Three.JS versions.

I recently had a desire to convert text to 3D meshes that I could render and manipulate as part of my Geotoy project and Geoscript language. I did some research into tools and libraries that could solve different pieces of this, and I put together a pipeline that implements the whole thing - yielding nice, 2-manifold 3D meshes with arbitrary fonts, text styles, and more.

The Problem

I was working on optimizing some WebAssembly, and wanted to use the Linux perf utility to profile Google Chrome to analyze where the most time was getting spent in my code at the assembly level.

I was following a guide to do this: https://v8.dev/docs/linux-perf

There is one step that involves processing some artifacts generated during the profiling process. This involves running the following command:

perf inject --jit --input=perf.data --output=perf.data.jitted;

When I ran this command, it would start but then hang indefinitely. It seemed to be making no progress even after several minutes of running, and there was no noticeable CPU activity to indicate it was doing work.

Here is an account of the process I developed to get the boundary-first-flattening library building for use on the web via WebAssembly.

Boundary First Flattening (I refer to it as BFF throughout this article) is a powerful algorithm and library for “surface parameterization” - or projecting 3D surfaces into 2D. It also includes built-in support for other parts of a full UV unwrapping pipeline like bin-packing texture islands into a square. I was using it for my Geotoy project - a browser-based, Shadertoy-inspired web app for procedural geometry.

Well, here’s another chapter in the saga of graphics and GPU issues with Google Chrome on Linux.

I have a 7900 XTX GPU, and I think at least part of these issues are a result of AMD GPU drivers being pretty messed up on Linux.

The Problem

One day after updating my packages and rebooting my system, WebGL web apps were running at very low FPS in my Google Chrome browser. It was really slow - like sub-10 FPS when I usually get 165.

The Problem

I am using SvelteKit and importing a WebAssembly module on the server side inside a +page.server.ts file like this:

const WasmPromise = import('src/viz/wasmComp/geoscript_repl').then(
  async (engine) => {
    await engine.default(fetch('/geoscript_repl_bg.wasm'));
    return engine;
  }
);

It works when I run for local development, but it fails when running on my VPS in production. Some notes about my deployment environment:

• I’m Sveltekit’s adapter-node
• I’m deploying the Sveltekit app inside Docker behind an NGINX reverse proxy

This Wasm module as built using wasm-bindgen for Rust, and it needs the path to the Wasm to be explicitly provided since it’s running on the server side rather than the client.