Wasm build about react-three-rapier HOT 8 OPEN

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

from react-three-rapier.

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 🤔

from react-three-rapier.

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

from react-three-rapier.

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

from react-three-rapier.

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 🙂

from react-three-rapier.

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!

from react-three-rapier.

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

from react-three-rapier.

awesome news! thanks for the clarification

from react-three-rapier.