Shdr – Online GLSL shader editor and validator with live preview

http://bkcore.com/blog/3d/shdr-online-glsl-shader-editor-viewer-validator.html

by chrismdp • 12 years ago

98 16 12 years ago

bkcore.com

dlsym• 12 years ago

Looks like the time variable is not updated...

Update: Sorry - Time is just really slow there :D

Garthex• 12 years ago

This looks cool!

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

userbinator• 12 years ago

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:

http://www.iquilezles.org/www/articles/distfunctions/distfun...

nfbush• 12 years ago

Would you know anywhere that i could learn about all this glgs malarky, ddg isn't being helpfull...

3rd3• 12 years ago

This site always blocks my browser. I wished the WebGL contexts wouldn't load right away.

shuffle2• 12 years ago

"pixar guy" is also "rgba guy" :) http://www.rgba.org/

mixedbit• 12 years ago

Very nice! Consider adding an option to save a result as a multiline JS string (for inlining in JS code).

thegeomaster• 12 years ago

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] :)

[1] http://i.imgur.com/BGv8dL9.png

Robadob• 12 years ago

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.

hitlin37• 12 years ago

this is really cool project. very interesting.

GrantS• 12 years ago

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.

peetle• 12 years ago

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.

c3d• 12 years ago

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.

_pmf_• 12 years ago

WebGL*

* probably crashes browser

tripzilch• 12 years ago

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.

jo_• 12 years ago

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.

Shdr – Online GLSL shader editor and validator with live preview

Related Stories