Haven't heard of it until now!
I can't quite tell - but it seems like you have to hit their servers in order to run this from the command line and the code isn't fully open source?
Regardless - thanks a lot for sharing!
530 karma · joined June 29, 2014
I can't quite tell - but it seems like you have to hit their servers in order to run this from the command line and the code isn't fully open source?
Regardless - thanks a lot for sharing!
There's a recent issue [1] in the wasm-bindgen repo that explains this, but essentially:
- In this demo the WebGLRenderingContext was created on the Rust side (technically by calling a light JS shim), but it could've just as well have been passed in from JS.
- This means that JS could very easily have had access to the WebGLRenderingContext.
- This means that we cannot guarantee that it is immutable. Who is to say that there isn't a line of JS `gl.mutated! = true;` that we don't know about? We have no guarantees that whoever instantiated this WebAssembly module isn't doing something funky.
- So we treat most DOM / JS APIs as if they have interior mutability, so more or less you can think of them as `RefCell`'s [2]
---
As an aside. When you work with WebGL you're just making calls to the GPU and your state on the GPU gets mutated. The object just controls state (WebGlRenderingContext) does not get mutated (aside from maybe a couple things that I'm forgetting..?).
As in.. `gl.viewport` doesn't actually mutate `gl`. But again.. just a small aside!
In general the idea here is that we can't guarantee that there is only one mutable reference so there is no point in calling these things `&mut`, even for things that really do mutate.
---
So yup! Interior mutability without runtime checks for many of the APIs is "the right way" in today's idiomatic Rust + WASM + DOM access since you can't guarantee that there isn't foul play going on from whoever instantiated the module.
---
Does this cause issues? It hasn't (noticeably) for me yet but I'm only a couple months into using `web_sys` so I haven't worked with every single DOM API.. so grain of salt!
[1] - https://github.com/rustwasm/wasm-bindgen/issues/1061
[2] - https://doc.rust-lang.org/std/cell/struct.RefCell.html
One thing that can be done is playing around with the numbers / uniforms in the fragment shader to change the look. For many use cases you can get pretty far with that without actually changing the implementation in this demo.
If a more physically based level of realism is needed (like the water ripples on click in the demo that you linked) you can use techniques like height simulation based on a wave equation [1].
You'll of course need to balance realism with realtime feasibility - but often times getting a much better look comes down to tweaking some numbers until things look good!
[1] - https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch01.ht...
Today WebGL is commonly referred to as a JS API because pretty much every WebGL app is written using JS.
But, even though that MDN link quite literally says "JavaScript API", it turns out that WebGL is entirely specified in WebIDL and isn't coupled to JS.
Because of this, `wasm-bindgen` [1] is able to auto-generate all of the WebGL bindings [2] that I used for this demo.
Today `wasm-bindgen` automatically generates some JS shims because that's the only way to call the WebGL APIs at this time, but once anyref and host bindings land you'll be able to interface with the WebGL APIs directly without going through JS.
`wasm-bindgen` already plans to just replace those JS shims with direct host bindings.
But yup - totally agree with your points here - just sharing this minor detail that will be more relevant in the future!
[1] - https://github.com/rustwasm/wasm-bindgen
[2] - https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.W...
- I see that I poorly communicated this in the title, but I was actually shooting less for "Rust/WASM makes this better!!" and more for "Hey, this is possible with pretty much just Rust/WASM!" I ended up hand writing about 10 lines of JS [1] in total
- More minor point - WebGL commands don't need to be called via JS [2] after anyref and host bindings land, and I think that it's important for people to know that it's possible to do things on the web without JS (whether that's a good idea is very situational)!
So yeah apologies if the title could be a bit better - but the main goal was to share with others that it's possible to build 3d experiences on the web with Rust today!
And - just to not come off wrong here - I'm not saying whether this is right or wrong and when to go this route. I am just interested in demonstrating how to do it :)
But all in all you're right - all of this same experience could totally be built with only JS if someone so desired!
[1] - https://github.com/chinedufn/webgl-water-tutorial/blob/maste...
[2] - https://github.com/WebAssembly/reference-types/blob/master/p...
Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!
One difference is that Yew is powered by stdweb and Percy is powered by wasm-bindgen.
I'm personally SUPER bullish on wasm-bindgen because it's been designed from day 1 to be able to take advantage of the host bindings proposal when it materializes.
Host bindings tl;dr is that instead of needing to go through JS to interact with browser APIs you can interact with them directly.
Another difference is that to my knowledge Yew doesn't support server side rendering ( which was why I couldn't use it even though I wanted to :( ).
Without having used Yew I don't want to comment any further than those high level differences.
I can say that a big focus of Percy is to be a grab bag of modules / tooling for frontend Rust web apps with a major focus of you being able to swap out the parts that you think are bad for other peoples' better implementations. That dream isn't realized yet.. but I think that Rust's generics / traits could make this feel very clean!
The backend is pretty much this (messy) file - https://github.com/chinedufn/percy/blob/master/examples/isom... .
It
1. Pulls in your application crate 2. Initializes your app (more or less sets initial state 3. Renders your app's virtual DOM into an HTML string 4. Serves the HTML to the client, along with the initial state serialized into JSON in a script tag (using serde-json) 5.Also serves the WASM script and the JS that initializes the WASM
So that's your server crate. Then your client crate also pulls in your same application crate and you compile it to WebAssembly and that's what runs browser side.
Feel free to let me know if any of that was poorly explained!
If you don't need server side rendering you can have one Rust file but you also need a JS file to initialize the WebAssembly module. So just one file isn't reasonably possible.
For a server side rendered app you need to have a cargo workspace with 3 crates (they can be in the same repo so not a huge deal).
One crate is a `cdylib` that you compile to WebAssembly to serve your app to the client. This is a light wrapper around your actual application.
One crate is your actual application.
And one crate is your server, which is also a light wrapper around your actual application.
That server side rendering structure can be found here - https://github.com/chinedufn/percy/tree/master/examples/isom...
But in terms of a super minimal example without server side rendering.. I'll be working on adding one (along with updating the current example)!
What I really mean is a virtual dom implementation that
- On the frontend can diff/patch a real DOM node - On the backend can render into an HTML string that you can serve
So my intended takeaway with that title was:
-> A virtual dom implementation that allows you to write frontend web applications that support server side rendering.
Apologies for the buzz-wordification I didn't even realize ha!
1. Figure out what I wanted the input and output to be for the API. Write that down. 2. Write and implement tests against that desired input and output. So at this point the `skeletal-animation-system` API is ready. Time for the demo
3. Create the demo. The main pieces of the demo are:
A vertex shader that positions each vertex based on up to four bones that have a certain percentage of influence on that vertex. That shader looks something like this -> https://github.com/chinedufn/load-collada-dae/blob/master/sr...
A parser to get the mesh and bone data from a collada file -> https://github.com/chinedufn/collada-dae-parser
---
I don't have much of a write up right now of how this works.. But if you'd like to get a better sense you might look through the demo code. The entry point is here -> https://github.com/chinedufn/skeletal-animation-system/blob/...
Alternatively you can run the demo locally and play around with it:
```
git clone https://github.com/chinedufn/skeletal-animation-system
cd skeletal-animation-system
npm install
npm run demo
```
Really wish I could point you to something more in depth, sorry!
So I usually blend my successive animations CPU side before passing in my uniforms so I end up using the same number of uniforms no matter what.
I'll definitely need to spend some more time playing with and learning from all of the existing solutions
So, it turns out that this demo doesn't use Three.js, but the idea is that, if you wanted, you totally could :)
And I'm a Blender noob as well, this tutorial series on character modeling, texturing, rigging and animation was super useful for me. Has a nice pace and doesn't skip over any details -> https://m.youtube.com/watch?v=DiIoWrOlIRw
So the short answer is - not in the demo, but yes in your own code
---
The demo's model rendering is powered by load-collada-dae ( https://github.com/chinedufn/load-collada-dae ) which right now has a default shader (what you see in this demo) and very few options to manipulate that default shader (I'm still thinking about the API)
Planning to update load-collada-dae to allow the user to pass in their own shader (with non-constant shading if they so please)
But skeletal-animation-system works completely independently of whatever renderer you're using so you could swap out load-collada-dae with, say, regl or Three.js or your own custom library.
---
So I'm fond of the idea of being able to quickly get up and running with small modules, hence me working on things like this. Totally hear and agree with you on most of the WebGL being "hidden" here.
I hope to work on more tutorials that dive into how the sausage is made, but for now you can look at the implementation on GitHub -> https://github.com/chinedufn/load-wavefront-obj
It turns out that the files are roughly the same size since the parser just shuffles the data around to make it easier to pass to your uniforms later.
`f16-model.obj` -> 396.9 kB (396947 bytes)
`f16-model.json` -> 397.5 kB (397534 bytes)
Using pre-parsed `JSON` here helps you avoid needing to parse your `.obj` file during runtime. Plus, since JS runtimes are heavily optomized for JSON, this seemed like a good starting place.
Super open to better alternatives of course!
Well if it still doesn't work, feel totally free to try it locally:
```
git clone https://github.com/chinedufn/collada-dae-parser
cd collada-dae-parser
npm install
npm run demo
```
So I was using linear blend skinning and had those horrid artifacts.
Google.com told me that dual quaternion skinning was the solution, so more or less blindly went with that.
santaclaus mentioned OCR in another comment, so I'll be reading up on that
So admittedly I only heard of DLB a few weeks ago, and OCR skinning 10 seconds ago :)
But this looks pretty damn cool. Thank you so much for the link, I'm definitely going to read this paper and consider it for a standalone skeletal animation library that I've started working on