Tearable cloth in asm.js(jlongster.com)
jlongster.com
Tearable cloth in asm.js
http://jlongster.com/s/lljs-cloth/
14 comments
The original (http://codepen.io/stuffit/pen/KrAwx) feels much more responsive (when feeding the same dimensions -- 114,53 -- as what your version uses), tested on Firefox 19.0.2 and Chrome 26.0.1410.65
No idea what you mean. It's just as fast, if not faster, for me. I don't know what that one does (haven't looked at the code), but it's cloth interaction is more powerful so it's probably just an interaction difference. I liked a softer interaction, but moving the mouse fast if you want to blow it up.
EDIT: I shouldn't have said "no idea". There is one reason I can think of -- this uses WebGL, so if you have a bad card or drivers this might be slower. My algorithms might be more precise too, I don't know the other code.
EDIT2: A coworker just mentioned that I should turn off antialiasing (it's on by default) and that should help a lot of machines. Also optimized WebGL a few other ways.
EDIT: I shouldn't have said "no idea". There is one reason I can think of -- this uses WebGL, so if you have a bad card or drivers this might be slower. My algorithms might be more precise too, I don't know the other code.
EDIT2: A coworker just mentioned that I should turn off antialiasing (it's on by default) and that should help a lot of machines. Also optimized WebGL a few other ways.
This is relatively new (early 2013 retina macbook pro 15", MacBookPro10,1, 2.7 Ghz, 16GB Memory), so I would think WebGL would work in both places ...
I don't think WebGL is used with the original, since it was working just fine on my eeepc with linux (which does not do WebGL, last I checked). This new one barely works in chrome on windows on this T420 though.
I don't know what the cause is in my case, maybe WebGL on this thinkpad is really slower than CPU rendering on an Atom?
I don't know what the cause is in my case, maybe WebGL on this thinkpad is really slower than CPU rendering on an Atom?
I'm using the exact same rig and testing same version of Chrome, and they seem the same. We're really just comparing WebGL to canvas. Note that I had to use WebGL because with asm.js, the cloth gets so dense that canvas couldn't handle it.
Not having any issues in latest FireFox nightly / OSX / Retina MBP, am running at 225x110 or something like that. Nice job!
It seems like the cloth in this version has much higher tension so it doesn't respond as much when you pull on it.
You need Firefox Aurora or Nightly (which will be Firefox 22 and 23) for asm.js support, without which the demo will be several times slower than it could be. (I have no idea whether it should match the speed of the original in browsers that don't support asm.js or not.)
This isn't exactly right. First, the demo starts with a really tiny cloth and then scales it up until your system starts slowing down. Second, he's comparing the same dimensions with asm.js and non-asm.js code, and they should be equivalent in browsers without asm.js (in fact, that style of code is usually a tiny bit faster because it's hitting all the optimized parts of javascript).
Just installed Nightly to test this out. It doesn't work. Just sits there blinking "Seeing how much your system can handle..." with no growing cloth in the background.
Opened up FireBug; the console had the following error at line 18 of renderer.js:
> NS_ERROR_FAILURE: Failure > this.gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl')
EDIT: It doesn't work in FF 20.0.1 either... Win 7
Opened up FireBug; the console had the following error at line 18 of renderer.js:
> NS_ERROR_FAILURE: Failure > this.gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl')
EDIT: It doesn't work in FF 20.0.1 either... Win 7
That means your browser doesn't have WebGL available. If you're on Nightly, that probably means your GPU is blacklisted. Type about:support into your address bar to see details.
How come it doesn't return null here? I display an alert if WebGL isn't available.
You can get an exception from any canvas or WebGL API in cases where a driver is misbehaving (or, worst case, you have hit a browser bug).
You gotta wrap that stuff in try/catch (at least the getContext call, as a minimum). I don't think this is spec compliant, but I've seen it in Firefox, Chrome and Opera under various configurations.
You gotta wrap that stuff in try/catch (at least the getContext call, as a minimum). I don't think this is spec compliant, but I've seen it in Firefox, Chrome and Opera under various configurations.
Has anyone noticed that if you edit trace("Floating point literals are typed as double: " + 1.1 / 2) on lljs.org's demo to become trace("Floating point...are typed as double: " + 1.0 / 2.0) you get an answer of 0 instead of 0.5?
LLJS may not be ready for prime time, so compiling crap is probably just going to produce more crap.
This one is much slower than the Javascript one for me (using latest Chrome stable).
They aren't using the same algorithm and settings, so the two demos are not directly comparable.
This is still javascript. Just only using the most highly optimized pieces.
This uses WebGL, so there's potential that you have a bad driver/video card that this will be slow. That's the only reason I can think of.
This uses WebGL, so there's potential that you have a bad driver/video card that this will be slow. That's the only reason I can think of.
works well for me in chrome / os x.
Used the 'a' key to cut / tear.
Cool demo! I don't know much about this sort of stuff, could you talk about what's going on in the vertlet.js file a bit?
Cool demo! I don't know much about this sort of stuff, could you talk about what's going on in the vertlet.js file a bit?
Verlet.js is a physics engine written in javascript [0]. It was posted and discussed on HN a few days ago [1]. OP didn't write it, but probably understands it very well.
[0]http://subprotocol.com/verlet-js/ [1]https://news.ycombinator.com/item?id=5580596
[0]http://subprotocol.com/verlet-js/ [1]https://news.ycombinator.com/item?id=5580596
I didn't use the aforementioned verlet.js physics engine, but that's basically what this is. Verlet integration is a simple way of modeling forces. If you are referring to the actual js code, it's asm.js-compatible javascript, which you can read more about here: http://asmjs.org/
For me the cloth dimensions in Firefox go up to 122, in Nightly and Aurora go only to 85 and the lines of the cloth looks blurred. (Win8, latest NVIDIA driver)
For me (firefox 19), if I've scrolled down on the page, the mouse clicks seem to register on the cloth below the mouse pointer.
It randomly has the whole cloth disconnect from the top and just fall down. Chrome 26.0.1410.65
Crashes Chrome tab - draws sad face. Slow in Firefox. Windows XP.
Crashes my iOS safari browser