If I understand it correctly a lot of the geometry effects build on the ability to do texture reads in the vertex shader (OpenGL calls it "vertex texture fetch"), a not much-noticed, but incredibly powerful feature of modern WebGL implementations.
The reason it is so powerful is because one texture can be used as a write target for the fragment shader and as a read target for the vertex shader, essentially creating a feedback loop that lives entirely on the GPU.
Not all browsers support the feature though (check the MAX_VERTEX_TEXTURE_IMAGE_UNITS constant). Mobile devices could be problematic too since most (if not all) OpenGL ES 2.0-era devices don't support it in hardware.
Still this is one of the most impressive WebGL demos I've seen. Fantastic stuff.
> Please view in Chrome or Firefox. Chrome is glitchy, Firefox is stuttery.
I really want to get behind WebGL, but when is it going to have decent performance/compatibility? I tried this out in both FF and Chrome on a powerful desktop computer (i5-4670K, GTX760, 16GB RAM) and it was glitchy/stuttery as described. Firefox rendered some scenes at what seemed like 2-3 FPS. Chrome was much smoother, but I couldn't tell what parts were glitches. For example, the "classic demoscene water effect" looked completely different in Chrome. But neither FF nor Chrome produced an effect remotely resembling water.
Although this looks like a great library, personally I prefer to stick with OpenGL programming until WebGL's quircks are sorted out.
... when the GPU drivers fix their bugs, when all the undefined behaviour gets defined, when the security holes get patched, and triple-A gaming studios with intimate connections to the vendors aren't the only ones driving the tech. Any day now.
WebGL devs are playing the longest game of chicken seen on the web yet.
Runs OK on my Surface Pro 2. Core i5, Intel GMA, 4GB of shared RAM.
There were some places where the framerate dropped but they were the more complex demos. The fan kicked in almost immediately though. In general, even if the framerate was low it was stable.
Interestingly IE11 seemed to render almost as well as Chrome and I didn't notice a speed difference. I guess that's what happens if you offload work to the GPU.
I viewed this whole presentation on a MacBook Air plugged into a 32" monitor, and while 1 or 2 of the slides would pause here and there, overall it was amazingly smooth. Mind blown.
This is still emerging tech but it's stabilizing rapidly — both Firefox and Chrome play back at 60fps on a MacBook Air. On a sub-$1K laptop it's noticeably slower because things are disabled due to Intel HD 3000 driver bugs but those bugs are now getting a lot more attention since they're so visible. I'd expect the situation to be a lot more viable in a year or two, so now seems to be a good time to start learning the technology and thinking about how to use it.
I was expecting another disappointment but no, on this somewhat dated system it runs great, and I was really impressed with several of the demos, even manipulating/rotating them in real time with the mouse, all running quite smoothly: Chromium Version 36.0.1985.125 Ubuntu 14.04 (283153), i5 2.8 Ghz, 6 Gb RAM
I have your exact hardware configuration and all his slides got a solid 60FPS. I'm curious what your setup was. What version of Firefox? What version of Windows? Latest NVidia drivers? Any weird extensions installed, screen/desktop capture apps running?
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.
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 wonder what it needs to handle text presentation and input. HTML overlays are mentioned. Perhaps there are already WebGL text renderers that could be integrated. Of course visualizations this complex make my Macbook scream, but that's all right since I'm seeing something new (in a browser) and delightful. I have a few million data points that could benefit from vantage point like this, which need complex dependencies and controls.
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.
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.
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 <raymarch> 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.
wow, just wow. amazing stuff Steven. I've been working on a framework for very easy data structure creation and instance management in a 3D environment. I was building it in 3D flash first, and have tried to build exactly those kind of curved arrows, though everything was calculated on the CPU. I've also been wanting to get to generating geometries from a static set of properties/datatypes for a while, and I was wondering to what degree I'm gonna have to get my 'hands dirty' and learn new things to do that. So wow, am I glad there's people like you building libraries like these!
I'm just about ready with rewriting the underlying semantic web framework to typescript and will soon be plugging it in to either Away3D TS or Three.js. Since I already know Away3D and it's written itself in Typescript I thought I might try that first, but seeing this ... and knowing how much more tested three.js is... I think I'm gonna go with Three.js
I really can't wait to play it with once you release it. I hope you can find some time for good documentation though. Cause at the moment I know just too little of the concepts involved to understand everything you explain in the slides.
His website [1] is one of the most impressive websites on the internet. Famo.us got nothin' on him!
First time I heard about Steven was when I saw this [2] post last year.. the best part is that he leaves many easter eggs or "achievements" around for you to discover :)
While we (at famo.us) have had our fair share of neckbeard faux pas, we and Steven are both fighting for the same future of the web; one where more sane low level primitives, such as a proper scene graph, are exposed to developers as a foundation upon which we can build better libraries and frameworks like MathBox 2. [0][1]
These is no need to make this into a pissing contest or a rivalry. We're fans of Steven's work and incredibly impressed with how he has pushed the state of the art on the web forward. Anyone who works on the bleeding edge like this helps build a brighter future for the web and creates more knowledge upon which others may build. Anyways, please keep the discussion focused on what Steven has achieved here instead of trolling.
Finally, something useful with WebGL. So far we've seen lots of techdemos, but WebGL being so far behind the state of the art, it's like watching techdemos from 10-15 years ago but in the browser, with glitches.
But this is something I really want to see. WebGL and GPU acceleration being put to use in the Web proper. Not just a box of 3d graphics inside a web page. Plotting neat 3d graphs with nice shading, fast and smooth rotate and zoom, etc. While you could probably do this using Canvas or SVG, you probably couldn't match the performance.
Now I'd like to see this technology being used outside of tech demos. Some real world data plotted this way.
I'd be interested in making a Flowhub [1] runtime for ShaderGraph 2 graphs. (Flowhub runtimes talk a protocol [2] to define what nodes are available, code new nodes, and build up graphs.)
Just pretend it's C and imagine how you might merge by hand a couple of .c + .h files into a single .c file that compiles. That's basically how it works.
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)
Any plans for Oculus support? I'm building a code analysis framework with a visualization tool and if MathBox were to support the Rift it would be a no-brainer over using raw SVG or D3.
MathBox 2 is built on top of threestrap (don't google it, you get shoes), to enable exactly this kind of extensibility without me having to do it all myself. Just by following a few basic conventions (e.g. binding the VR headset to three.camera), it should just work. Haven't tried it yet, too much to do, but I do know these guys who have a mocap studio being repurposed for free-walking VR experiments using a wireless headset. I sat on the couch in the Unreal Engine 4 apartment two weeks ago, and picked up a mug from the coffee table (i.e. real couch/table + real mug + mocap balls attached to the mug and the headset). Magic. Would be even better with a mathbox chandelier.
[+] [-] zabcik|11 years ago|reply
[+] [-] rsp1984|11 years ago|reply
Not all browsers support the feature though (check the MAX_VERTEX_TEXTURE_IMAGE_UNITS constant). Mobile devices could be problematic too since most (if not all) OpenGL ES 2.0-era devices don't support it in hardware.
Still this is one of the most impressive WebGL demos I've seen. Fantastic stuff.
[+] [-] slater|11 years ago|reply
[+] [-] reedlaw|11 years ago|reply
I really want to get behind WebGL, but when is it going to have decent performance/compatibility? I tried this out in both FF and Chrome on a powerful desktop computer (i5-4670K, GTX760, 16GB RAM) and it was glitchy/stuttery as described. Firefox rendered some scenes at what seemed like 2-3 FPS. Chrome was much smoother, but I couldn't tell what parts were glitches. For example, the "classic demoscene water effect" looked completely different in Chrome. But neither FF nor Chrome produced an effect remotely resembling water.
Although this looks like a great library, personally I prefer to stick with OpenGL programming until WebGL's quircks are sorted out.
[+] [-] unconed|11 years ago|reply
WebGL devs are playing the longest game of chicken seen on the web yet.
[+] [-] teamonkey|11 years ago|reply
There were some places where the framerate dropped but they were the more complex demos. The fan kicked in almost immediately though. In general, even if the framerate was low it was stable.
Interestingly IE11 seemed to render almost as well as Chrome and I didn't notice a speed difference. I guess that's what happens if you offload work to the GPU.
[+] [-] elsigh|11 years ago|reply
[+] [-] acdha|11 years ago|reply
[+] [-] tremendo|11 years ago|reply
[+] [-] runeks|11 years ago|reply
[+] [-] kevingadd|11 years ago|reply
[+] [-] kp25|11 years ago|reply
[+] [-] webXL|11 years ago|reply
[+] [-] watmough|11 years ago|reply
[+] [-] SammoJ|11 years ago|reply
[+] [-] elsigh|11 years ago|reply
[deleted]
[+] [-] iamwil|11 years ago|reply
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.
[+] [-] jarpineh|11 years ago|reply
I wonder what it needs to handle text presentation and input. HTML overlays are mentioned. Perhaps there are already WebGL text renderers that could be integrated. Of course visualizations this complex make my Macbook scream, but that's all right since I'm seeing something new (in a browser) and delightful. I have a few million data points that could benefit from vantage point like this, which need complex dependencies and controls.
[+] [-] unconed|11 years ago|reply
[+] [-] gravity13|11 years ago|reply
Nice.
[+] [-] thebokehwokeh2|11 years ago|reply
[+] [-] gavanwoolery|11 years ago|reply
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.
[+] [-] unconed|11 years ago|reply
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 <raymarch> 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.
[+] [-] rpwverheij|11 years ago|reply
I'm just about ready with rewriting the underlying semantic web framework to typescript and will soon be plugging it in to either Away3D TS or Three.js. Since I already know Away3D and it's written itself in Typescript I thought I might try that first, but seeing this ... and knowing how much more tested three.js is... I think I'm gonna go with Three.js
I really can't wait to play it with once you release it. I hope you can find some time for good documentation though. Cause at the moment I know just too little of the concepts involved to understand everything you explain in the slides.
Thank you already for this amazing presentation
[+] [-] saganus|11 years ago|reply
It's eye candy AND it's interesting at it's core... wow. Beautiful work.
I just can't articulate a better thing than "wow". Really. This is incredible.
[+] [-] mck-|11 years ago|reply
First time I heard about Steven was when I saw this [2] post last year.. the best part is that he leaves many easter eggs or "achievements" around for you to discover :)
[1] acko.net [2] https://news.ycombinator.com/item?id=6268610
[+] [-] malandrew|11 years ago|reply
These is no need to make this into a pissing contest or a rivalry. We're fans of Steven's work and incredibly impressed with how he has pushed the state of the art on the web forward. Anyone who works on the bleeding edge like this helps build a brighter future for the web and creates more knowledge upon which others may build. Anyways, please keep the discussion focused on what Steven has achieved here instead of trolling.
Steven, many kudos for this. Extraordinary work.
[0] http://acko.net/blog/shadow-dom/
[1] http://extensiblewebmanifesto.org/
[+] [-] MaysonL|11 years ago|reply
[+] [-] exDM69|11 years ago|reply
But this is something I really want to see. WebGL and GPU acceleration being put to use in the Web proper. Not just a box of 3d graphics inside a web page. Plotting neat 3d graphs with nice shading, fast and smooth rotate and zoom, etc. While you could probably do this using Canvas or SVG, you probably couldn't match the performance.
Now I'd like to see this technology being used outside of tech demos. Some real world data plotted this way.
[+] [-] anigbrowl|11 years ago|reply
I hoe someone builds the latter on top of it, since the flow-based paradigm is so effective in these contexts. Excellent presentation.
[+] [-] meemoo|11 years ago|reply
1. http://flowhub.io/ 2. http://noflojs.org/documentation/protocol/
[+] [-] m_mueller|11 years ago|reply
[+] [-] unconed|11 years ago|reply
[+] [-] KerrickStaley|11 years ago|reply
[+] [-] stephendicato|11 years ago|reply
A discussion group, sometimes informal, interested in a particular topic.
Conferences often refer to their themed tracks as "BoF" sessions.
[+] [-] chatmasta|11 years ago|reply
[+] [-] lukasm|11 years ago|reply
http://test.co.s3.amazonaws.com/Screen%20Shot%202014-08-15%2...
[+] [-] Shamiq|11 years ago|reply
[+] [-] sillysaurus3|11 years ago|reply
[+] [-] MattyRad|11 years ago|reply
[+] [-] jschrf|11 years ago|reply
[+] [-] unconed|11 years ago|reply
Now I hate 2D screens even more. So yes.
https://github.com/unconed/threestrap http://thesawmill.ca/ http://wavesine.com/
[+] [-] dj-wonk|11 years ago|reply
I have waited so long for a good hardware-accelerated 3D screensaver in my browser! ;)