Web Assembly Support

[Schr3da]

Is web assembly initially planned?

[kvark]

@Schr3da we haven't look into it, and don't know what the requirements/implications are. It would be much welcome for sure ;)

[jpryne]

AFAICT, WASM has the same limitations as WebGL. If Three.rs can run using OpenGL ES 2.0, then it should compile to WASM just fine. I haven't tested this yet, but am digging into Three.rs for just this reason...

[alteous]

I imagine there will only be a few issues to consider (all amendable) before WASM support can be a reality.

1. Faces take GL_UNSIGNED_INT indices. We would have to enable the OES_element_index_uint extension or restrict indices to GL_UNSIGNED_SHORT.
2. Shaders are written in more recent GLSL versions. We might have to write equivalent GLSL 1.x shaders.
3. Use of Rust mpsc channels. This might have to be replaced with a WASM-friendly equivalent.
4. Compilation, although I've had success with cargo web.
5. The main loop needs to be a callback.

[kvark]

Note that gfx-0.17 has WebGL2 support, so we may be very close to get this going. I'm planning on updating our graphics stack, and I'll test WebGL2 for three-rs on the way, will report back here.

[ForsakenHarmony]

is there any progress / timeline for this?

[kvark]

@ForsakenHarmony we are currently stopped in a situation where Emscripten could possibly be gotten to work. The upstream PR unblocking it has landed only recently - https://github.com/kripken/emscripten/pull/5951 . However, Rust community/ecosystem appears to be moving in the direction of using wasm-unknown-unknown target instead (thus, no Emscripten), and we are watching a hero laying down this path in https://github.com/gfx-rs/gfx/issues/1900

Anyhow, a champion is always needed here in Three-rs to get things hooked up and tested. Jump on our gitter to chat about it if you want to lend a hand ;)

[ForsakenHarmony]

I'm not sure if I could be of any use

[LordBenjamin]

Any thoughts on this now that gfx-rs supports wasm-unknown-unknown?

I'm interested and could possibly lend some time to implementing (although I'm a Rust newbie) if there is a good idea of what is required?

[jpryne]

Likewise to LordBenjamin. I'm experienced with THREE.js via Javascript, but new to Rust & WASM. Nonetheless, would like to contribute given sufficient guidance or examples to work from.

[kvark]

@LordBenjamin it's an entirely different gfx-rs that now has basic support for wasm-unknown-unknown. Three-rs uses gfx-0.17, which we call "pre-ll" for "pre low-level rewrite". There is no straight path to upgrade to the current latest and greatest gfx-hal-0.3, see https://github.com/gfx-rs/gfx/issues/1721

This project needs a big leap in order to continue developing - moving from gfx pre-ll to wgpu-rs, which is modern, extremely portable, and has a similar level of abstraction. See #222. wgpu-rs is naturally going to be targeting the Web, even though today its capabilities are mostly focused on native.

@vitvakatu earlier expressed interest in doing the port, but I'm not aware of any progress, so the task is still open for interested parties.

[vitvakatu]

Yeah, I got distracted by other tasks (and continue to be distracted), so I suppose someone else could try to do so. I can help with code reviews.

[LordBenjamin]

@kvark / @vitvakatu - thanks for the info.

Is there any detailed breakdown of what would need to be done to move to wgpu-rs? #222 doesn't really seem to indicate what the steps involved in this port would be.

What sort of effort do you think the port would involve - days, weeks?

[kvark]

It's a big multi-week effort. Steps can be described as follows:

1. remove all gfx-related dependencies
2. add wgpu=0.3 dependency
3. fix all the compile errors :)

Here is a similar effort that was done in the past - https://github.com/kvark/vange-rs/pull/73 , to give you a sense of scale.

[jpryne]

How about we break it down further and assign chunks to willing owners?

[vitvakatu]

Basically you need to rewrite the whole render module, and you can't do it step-by-step. You can, however, translate examples one-by-one (by disabling ones that are not working) and slowly implement necessary features.

I don't know how to break down such huge task.

[kvark]

You could also cut out all the pipelines/shaders except for the most basic one to start with. But it still requires a lot of thinking up-front. Just rewriting the infrastructure we have is the biggest challenge, and it will probably need to be done in one go.

@LordBenjamin @jpryne we greatly appreciate your interest in helping with this, and we'll be happy to provide guidance along the way. Just giving a fair warning that this is not an easy task, especially if you also need to learn about gfx pre-ll and wgpu-rs along the way.

The way it could be done, I imagine is:

1. learn about wgpu-rs by analyzing the example code, so that you have a rough idea of how we'll need to restructure the render module
2. hook up wgpu-rs 0.3 dependency here and start adding wgpu-backed objects to stuff that the current three-rs has backed by gfx-rs (this stage is not testable, but at least it compiles!)
3. at some point, you'd need to start removing the gfx-rs entirely, and this is where things will break compiling likely
4. fix all the compile errors :)

[LordBenjamin]

Just giving a fair warning that this is not an easy task, especially if you also need to learn about gfx pre-ll and wgpu-rs along the way.

Fair enough. Possibly in over my head TBH - I have little Rust / gfx experience as I'm coming from a C# / DirectX and TypeScript / three.js background.

I'm sure it would be an interesting ride and I would learn a lot by doing this. Appreciate your offers of guidance and code reviews. I don't want to commit to doing it and then waste your time with trivial questions either though.

I'll have a bit more of a look into wgpu-rs and let you know if I think I can help!

[jpryne]

Yeah, I'm in the same boat. Chewing my way through lib.rs...