Live data from Hacker News

MathBox 2

acko.net

11–20 of 93 posts

Re: MathBox 2

#11
I'm pretty excited about it. I think there are three impressive things about it.

First is that you can write vertex shaders in a reactive DOM. That makes it much easier to get pictures up on the screen. If any of you have ever messed around with vertex shaders, it can be a bit of a nuisance.

Second is that while the reactive DOM doesn't really exist as XML, it can be expressed as such, and would be easily diffable. This is important for collaboration.

Lastly, because it's making the GPU do all the work, data visualizations can be done by pushing large amounts of data to it. We should be able to see more patterns from data as a result.

Re: MathBox 2

#13
The visual representation of calculus, speed, velocity, and acceleration taught me more in 60 seconds than would take in 4 hours worth of lectures. Fantastic! (Makes my laptop catch on fire though)

Re: MathBox 2

#15
Looks great, seems like this takes advantage of implicit calculations a lot. For example, there are two ways to draw a graph:

Calculate just the points to be drawn, then draw them (explicit generation).

Calculate the entire surface/volume, and draw values where they exist (or based on magnitude or whatever properties are used) (implicit generation).

The second method is in some circumstances less efficient, especially if the graph is very simple and takes up little screen space, but overall much easier to work with. Its similar to the difference between ray casting and rasterization, in a way.

Re: MathBox 2

#16

Wow, after viewing the examples, almost 10% battery was consumed.

Totally agree, under Chrome / OS X, fans went crazy on my rMBP 15 iGPU and CPU raised 80 C degrees just to watch a few slides of that site. I closed the tab to stop overheating.

Re: MathBox 2

#18

Looks great, seems like this takes advantage of implicit calculations a lot. For example, there are two ways to draw a graph: Calculate just the points to be drawn, then draw them (explicit generation). Calculate the entire surface/volume, and draw values where they exist (or based on magnitude or whatever properties are used) (implicit generation). The second method is in some circumstances less efficient, especiall…

Yes and no, everything is still sampled on grids. But the intermediate calculations can be doing tons of implicit look ups. So it's more like lazy evaluation, though there's no auto-memoizing (because the memory/time tradeoff is highly context dependent).

So if you wanted to render an implicit surface this way, you could do e.g. marching cubes or tetrahedra on a grid, and only feed in a scalar 3D field, either as an array or as a procedural function. Or you could do a operator for raymarching a distance field. On the inside, this could be a dumb per-pixel loop, or do recursive quad-tree subdivision. You shouldn't need to care.

It's all vaporware right now, but it's just a matter of fitting it in neatly.

Re: MathBox 2

#19
post #8

This is one of the most beautiful things I've seen for some time. And to think this is all in a browser, usable from JavaScript. I feel like there could be so many applications for this, for more complex, interdependent visualizations, yet easier than D3 and the like. Also, in the end it's described as Reactive DOM. So, now I wan't to see TodoMVC redone with this. It must be the fastest yet (I'm only half joking!). I…

To handle HTML overlays, I basically need to add read back capabilities to find the final on-screen positions of points, so I can sync with CSS 3D matrices. GL text is a rabbit hole I'd prefer to avoid, especially since I often need math notation. It would turn into HTML/CSS-for-GL right away.
Post reply on HN