7 ms·
The code is quite cool to look at. Love seeing the extensive use of matrices and mathematics to create such a beautiful and mesmerizing display. If anyone is i
by randomdrake 13y ago
The code is quite cool to look at. Love seeing the extensive use of matrices and mathematics to create such a beautiful and mesmerizing display.
If anyone is interested in playing around with it, I threw it up at JSFiddle here: http://jsfiddle.net/zyAzg/ http://jsfiddle.net/zyAzg/
Excellent demo.
- thearn4 13y agoGreat demo, well written code. Though reading through it also highlights that JS is not a great language for linear algebra. But I don't think anyone is really suggesting otherwise.
- segmondy 13y ago"JS is not a great language for linear algebra." what does that even mean? It's a general purpose language. It all boils down to how you want to use it, like any other general purpose language. A lot of times in cases like this, people choose not to make it look pretty and easy to read to gain performance. This simulation is very CPU intensive, trying to have pretty code and speed is going to be tough.
- relaunched 13y agoLook into something like Octave, where matrices are first-order data types, and you'll know exactly what he means.
- Kiro 13y agoHad a look. Still think JS is fine.
- relaunched 13y agoJS is fine; in the same way that is fine to use a sandbox shovel to dig the foundation of a house. Languages are designed for a purpose, though they can be used for all sorts of things. There is a larger upfront cost to learning the right language for the right job. However, many people opt to try to fit a square peg into a round hole.
- Crito 13y agoOr look at Python/Numpy. General purpose language with a sufficiently advanced library that doing linear alg stuff becomes a very pleasant experience. Way, way, way nicer than spelling it all out like this JS code has to. Then again, I might be biased there since I've spent a decent chunk of time porting MATLAB/Octave code to Python/Numpy so that we could get it into production in a robust way..
- relaunched 13y agoI actually like python/numpy, mostly b/c I'm very comfortable in the python stack. Numpy has come a long way, such that it has sufficiently shaved the squared off corners of the square peg, so it pretty much fits into the round hole.
- Crito 13y agoTo me, Numpy/SciPy are Pythons "killer apps". I would say the plurality of times I have decided to use Python in the past two or three years, it was because of them.
- dingdingdang 13y agoNot only tough but ultimately impossible; like C it is nice that people can stretch JS to maximize performance - a developer can always maintain separate file with "nicely" formulated calculations but at the end of the day what matters is the end user's experience of speed in the final app.
- waterlion 13y ago"what does that even mean?" "It's a general purpose language" You answered you own question.
- neumann 13y agoCan I ask why JS is no good? (Genuine question) I thought the only consideration would be speed? The algebra is mainly looping. Isn't that way most languages try to handball algebra to LAPACK/BLAS?
- albertzeyer 13y agoI wonder if it was all handwritten. Esp. functions like invertMatrix or premultiplyMatrix. Or what he used to generate the code. I once used WolframAlpha to get me some complicated formulas and wrote a custom WA-plaintext-output-to-C translator for that output to use it in my code. Here is the script: https://github.com/albertz/helpers/blob/master/wolframalpha_translate.py https://github.com/albertz/helpers/blob/master/wolframalpha_... Example input: http://www.wolframalpha.com/input/?i=solve+a*x_1%5E3+%2B+b*x_1%5E2+%2B+c*x_1+%2B+d+%3D+x_1%2C+3a+*+x_1%5E2+%2B+2b*x_1+%2B+c+%3D+1%2C+a*x_2%5E3+%2B+b*x_2%5E2+%2B+c*x_2+%2B+d+%3D+1%2C+3a*x_2%5E2+%2B+2b*x_2+%2B+c+%3D+0 http://www.wolframalpha.com/input/?i=solve+a*x_1%5E3+%2B+b*x... Output: s->a = ((x1 + x2 - 2.) / pow(x2 - x1, 3.)); s->b = ((- (((x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) - ((4. * x2 * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((6. * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) - ((7. * pow(x2, 2.) * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) + ((6. * x2 * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) - 1.) / (4. * x2 - 4.)); s->c = (1. / 2.) * ((((x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) + ((4. * x2 * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) - ((6. * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((pow(x2, 2.) * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) - ((6. * x2 * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) - ((4. * (- (((x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) - ((4. * x2 * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((6. * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) - ((7. * pow(x2, 2.) * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) + ((6. * x2 * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) - 1.)) / (4. * x2 - 4.)) + 1.); s->d = (1. / 4.) * ((((x1 + x2 - 2.) * pow(x1, 3.)) / pow(x2 - x1, 3.)) - ((4. * x2 * (x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) - (((x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) - ((pow(x2, 2.) * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((2. * x2 * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((6. * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + x1 - ((pow(x2, 2.) * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) + ((6. * x2 * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) + ((4. * (- (((x1 + x2 - 2.) * pow(x1, 2.)) / pow(x2 - x1, 3.)) - ((4. * x2 * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) + ((6. * (x1 + x2 - 2.) * x1) / pow(x2 - x1, 3.)) - ((7. * pow(x2, 2.) * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) + ((6. * x2 * (x1 + x2 - 2.)) / pow(x2 - x1, 3.)) - 1.)) / (4. * x2 - 4.)) + 1.); (https://github.com/albertz/music-player/blob/master/ffmpeg_player_decoding.cpp https://github.com/albertz/music-player/blob/master/ffmpeg_p... SmoothClipCalc::setX)
- omn123 13y agoIt's worth pointing out that you should rarely, if ever, use exact formulas since there are a lot of problems with numerical stability amongst other things. Often it is faster to just numerically solve the system. For example, in your case you are solving Ax=b which you can easily solve by a simple LU decomposition. Plus if your A changes, your exact formula is wrong, so using an LU decomposition just makes sense. Plus your code will look way cleaner as well. And way easier to debug. http://en.wikipedia.org/wiki/LU_decomposition http://en.wikipedia.org/wiki/LU_decomposition
- bd 13y agoJust to clarify - the bulk of the work here is done in GLSL shaders on the GPU, not with matrices in JavaScript. All that matrix code you see in the source here is basically just the minimum prerequisite for doing 3D graphics, it would be the same if you just wanted to get a spinning cube with some camera control. The real magic happens in the shaders which compute water mesh displacement, normals and shading directly on the GPU (21 simulation passes + 1 rendering pass + 1 initialization pass, using several floating point textures, seems like stateful simulation with ping-ponging, basically using graphics rendering pipeline to do GPGPU without a need for OpenCL / CUDA).
- mistercow 13y ago>basically using graphics rendering pipeline to do GPGPU without need for OpenCL / CUDA It would be really cool to see a project that would make that easier to do in JS more generally. Basically a similar idea to Parakeet or Numba, but with GLSL as a target.
- mcpherrinm 13y agoI think the closest you'll get right now is something like THREE.js that builds shaders for you out of a high level graphics API.
- mistercow 13y agoThat seems to me actually further than just writing the GLSL shaders yourself. I suppose the MVP would be a library that simply eases getting data in and out of webgl.
- exDM69 13y ago> >basically using graphics rendering pipeline to do GPGPU without need for OpenCL / CUDA > It would be really cool to see a project that would make that easier to do in JS more generally. Basically a similar idea to Parakeet or Numba, but with GLSL as a target. The problem with doing this on WebGL (which is essentially GLES2) is that the internal precision of the pipeline is not required to be a full 32 bit float. There are 10 bit integers and 20 bit floating point numbers and all sorts of funny number formats in the hardware. When most scientific/numeric computation is done in 64 bit double precision, going to less than 32 bits is a problem. Of course it still could be done in WebGL, the problem is that running it on different hardware would yield different results. If this is acceptable (e.g. image processing where bit-accurate results are not required), then why not.
- nanidin 13y agoI'm not sure how I'd feel about a repost to jsfiddle without my permission if I were the original author. How is this any different than reposting xkcd or other webcomics on alternate hosting without the author's permission?
- mylons 13y agobecause it's code in a browser. if the author didn't want us to look at the code, why would they let us download it?
- chc 13y agoNobody's talking about looking at the code — the issue here is redistributing it on a platform outside of the author's control.
- ephemeralgomi 13y agovia reductio ad absurdum, do you also think it's alright to reappropriate swaths of CSS, HTML, and images from other people's web designs?
- WalterSear 13y agoThis isn't reappropriation. It's just putting something in public view in another form of public view, for better analysis.
- niels_olson 13y agoThis is close. Assuming this is all academic, then the error is lack of attribution.
- elliottcarlson 13y agoif a person didn't want his car stolen, why would he leave his car door unlocked? just because it's viewable, does not mean you are granted the rights to do whatever you want with it.
- itry 13y ago> If anyone is interested in playing around with it, I threw it up at JSFiddle here How do you know the author is ok with that?