seanisom

6 ms·

31.
by seanisom 3y ago
Manifold is awesome! Would love to get that integration going. I've implemented a lot of procedural geometry functions, but that is a long way from an actual CAD kernel.
32.
by seanisom 3y ago
Thanks! I haven't looked deeply into font yet, but I've always been partial to HarfBuzz for shaping, so will probably build on top of that. It also has an experimental Wasm shaper which certainly served as a bit of inspiration for
33.
by seanisom 3y ago
Yes! Not in the open-source repo yet (because it's currently broken :) ) but you can see it in the video, and will have it working again soon. That's exactly the goal - one wasm binary with defined input/outputs that can be l
34.
by seanisom 3y ago
It works well now! You use a SharedArrayBuffer to communicate between Web Workers. Was indeed a dark couple of years where the meltdown stuff disabled that, but there are now specific cross-origin headers that are used to isolate the Shared
35.
by seanisom 3y ago
Yes, that's a good mental model. Input - high-level description of graphics, output low-level graphics code running in Wasm.
36.
by seanisom 3y ago
Without going into the motivations for building a startup and doing Y Combinator, I do agree with many of your points. People can use Unity to build games and non-games. I personally don't think it fits a lot of different use-cases or
37.
by seanisom 3y ago
Also, with the solid foundation and simple API footprint you've built for APIs like sokol_audio, would be interesting to see if they could be expressed in WIT and used as a basis for something like a wasi-audio.
38.
by seanisom 3y ago
+1 for Audio and lots of other APIs necessary to make WASI more like a true OS. With Preview 2 / Component model, hoping the pace of contributions rapidly increases.
39.
by seanisom 3y ago
Yes! wasi-webgpu is coming, as well as more APIs with wasi-gfx. Getting rive-renderer working was not hard because in the demo its running on the host side, and not in Wasm yet, although compiling for Windows/DX11 took some minor chang
40.
by seanisom 3y ago
Partially. wgpu can translate graphics api calls like WebGPU to platform specific APIs - this is something I had to implement on the backend. In the future, will likely tool on top of wgpu on the backend as wasi-gfx (WebGPU) becomes a reali
41.
by seanisom 3y ago
Yes! There are a few different approaches to making that work - one would be to have an intermediate shader representation generated from Wasm compile to native platform shaders on the host graphics API. Longer-term, will likely expose WebG
42.
by seanisom 3y ago
Yes! Will look into that
43.
by seanisom 3y ago
There is the host API - wander, which contains the Wasm runtime and interfaces with the GPU. The actual graphics code is always compiled to Wasm.
44.
by seanisom 3y ago
sokol is great - I think of it as more of an "STB for apps". With renderlet/wander the goal is more to express graphics using higher level constructs and automatically generate the runtime code behind it. For example, with th
45.
by seanisom 3y ago
Yes! It's kind of a pain to build now, so will probably shift to shipping as a .so/dll with a raw C api in a future version. With that, should be easy to generate bindings for any language - the host API footprint is minimal.
46.
by seanisom 3y ago
The long-term goal is no - wander should handle shader compilation automatically. In the current version, the host app has to attach a shader using the host's shader API to render arbitrary geometry and textures. Was looking at several
47.
3D + 2D: Testing out my cross-platform WASM graphics engine
579 points by seanisom 3y ago|152 comments
48.
by seanisom 3y ago
Excited to see this! There's a need demonstrated need for WASI apps that can draw to a screen/canvas outside of a browser, and hope to see this as another community-driven contribution to WASI.