For those interested in tiiiny, efficient shaders, check out shadertoy. It was written by one of the Pixar guys, Inigo Quilez, and has a a lot of awesome user-submitted shaders. https://www.shadertoy.com
From a quick glance at the title I initially thought it was shadertoy too... and here's a quick reference of how to build scenes with certain 3D objects with this or any other shader tool:
I completely forgot how fun playing with shaders in realtime is. Last time I did this was in AMD RenderMonkey. Look what I made after a 2 minute poking around the editor (it's animated, too!)[1] :)
If you are interested in this kind of tool, you should also conside Tao Presentations. See http://www.taodyne.com/shop/dev/blog/288-building-a-dali-sty... for an example of what you can do with it (in that case, a real-shader-based real-time ray traced clock).
Real-time shader editing, complex scenes built using a real-time 3D document description language, animations, multiscopic 3D movies playback, 2D and 3D text layout, dynamic textures, etc. In short, Tao is a rather complete toolbox for real-time 3D.
Quick question; I'm running Linux Mint on a not-very-high-powered laptop (with onboard GPU), trying out this demo in both Firefox (32) and Chromium (37), I find the framerate in Chromium to be significantly better and smoother than in Firefox.
Any idea why this could be? Something about Firefox, or maybe my own configuration? How do I test whether it's actually using hardware acceleration? (or is there no software fallback and I wouldn't see anything in that case?)
Switching to lower polycount objects, even the cube, doesn't do much to improve the framerate either.
There are enough factors to make this answer little more than speculation. Please take it with a grain of salt and not as evidence for a course of action.
In theory, the Javascript engine is significantly faster in Chromium than in Firefox[1]. I don't think your system is falling back to CPU rendering (you would notice), but the overhead associated with WebGL is probably higher in Firefox. Additionally, since Chrome runs each tab in its own process, there is perhaps less overhead when switching task context for GL rendering.
[1] According to the April 2013 numbers on http://arewefastyet.com, they're pretty much on par. I can't shake the idea that Google's V8 engine is faster, but I can't prove it, either.
Very cool! Some hopefully helpful feedback: Running Safari on a Mac, and the text cursor visually shows up in a different place than the actual editing occurs, making editing tough. It is off by an amount that varies largely when I change the size of the on-screen text, sometimes off by 1 character, sometimes off by 4 characters. At a really large font size, I got it to mostly align and it made editing possible.
I've been meaning to do a similar project for a while, but also handling the ability to pass extra data to the shader via texture buffers (it's a useful technique for mass rendering of objects stored within the GPU) although I'm unsure whether WebGL currently supports this as I'm yet to use it.
Very cool! A small bone to pick, you should consider raising the contrast on the text in the Share dialog. It's really dark and very difficult to read on crappy monitors.
For those interested in tiiiny, efficient shaders, check out shadertoy. It was written by one of the Pixar guys, Inigo Quilez, and has a a lot of awesome user-submitted shaders. https://www.shadertoy.com