Wasm build

[verekia]

Following the discussion on #113 :

It would be nice to have the option to use the rapier3d Wasm build instead of the rapier3d-compat build.

Size on disk as of 0.9.0:
rapier3d (Wasm): 1.4MB
rapier3d-compat (JS): 1.9MB

[hmans]

I did a little asking on the Rapier Discord. People seem to be using the non-compat packages successfully with Webpack 5, using a config like the following:

const path = require('path');

const config = {
    entry: './src/index.js',
    output: {
        path: path.resolve(__dirname, 'dist'),
        publicPath: 'auto',
    },
    experiments: {
        asyncWebAssembly: true
    }
}

module.exports = (env, argv) => {
    if (argv.mode === 'development') {
        config.mode = 'development';
        config.output.filename = 'physics.debug.js';
        config.output.webassemblyModuleFilename = 'rapier3d.debug.wasm';
    }

    if (argv.mode === 'production') {
        config.mode = 'production';
        config.output.filename = 'physics.js',
        config.output.webassemblyModuleFilename = 'rapier3d.wasm';
    }

    return config;
};

Maybe we can reconstruct a similar setup for Vite. Vite seems to have a maintained plugin here:

https://github.com/Menci/vite-plugin-wasm

[balraj-johal]

I took a crack at this by taking the same approach that this person did in their repo, where this is the commit they migrate from raiper3d-compat to the wasm build.

Applying the changes in that repo - mainly adding wasm & top level await plugins to vite.config, and then refactoring all the imports in the library - seemed to make the demo work successfully with the WASM build. Problem is, the wasm build doesn't seem to play nice with vitest, as whenever I changed any of the test imports to use the WASM build I got the following error:

Error: Failed to resolve entry for package "@dimforge/rapier3d". The package may have incorrect main/module/exports specified in its package.json.

I believe this is due to an incompatibility with the vite-wasm-plugin and the vitest environment, as detailed in this issue.

I have made a draft PR for visibility of the issue if it is helpful, as I'm not sure how to proceed from here: #385

[isaac-mason]

Thanks for spending time on this @balraj-johal! I had a very brief look at your PR -

In my mind, ideally we would have 2 flavours of @react-three/rapier - one that still uses @dimforge/rapier3d-compat, and a new one that uses @dimforge/rapier3d (which has the external wasm file).

I think maintaining a flavour that doesn't require folks to set up a wasm friendly build config is important for keeping the library accessible. Otherwise, I fear we're going to have a lot of folks sticking on the old versions.

I'm not exactly sure how this should look, there's a few ways to approach it. e.g.

• two separate packages
• one package with entrypoints
• one package with support for both @dimforge/rapier3d and @dimforge/rapier3d-compat + tree shaking support to remove the unused dependency

That last one could be interesting, as it could solve some problems around how we handle this with respect to the new addons package.

This is a bit of a tricky problem to solve, but I think it's worth solving 🙂

[wiledal]

Indeed @isaac-mason, I had the same idea. Ideally one could choose something like import { Physics } from '@react-three/rapier/wasm' if one's setup supports it.
I haven't thought too much about how that could work, but in general since everything is created via factories coming from the world instance, it might not be too painful to switch out just the core context with the wasm equivalent 🤔

[opeologist]

has this issue received any more traction? would like to not use the compat variation of rapier with react-three, so my bundle size isn't so bloated upfront. thanks!

[opeologist]

another question i just realized as well: does using the -compat version prevent the deterministic claim that rapier has? the way i read it required using the wasm variant, but i might've misunderstood that section of the documentation

[isaac-mason]

Using the -compat version shouldn't affect determinism. Beyond a small difference in how the library is initialised, there aren't any functional differences.

-compat is the exact same wasm, just encoded as a base64 string, rather than as a separate wasm file

[opeologist]

awesome news! thanks for the clarification