8 ms·

Shdr – Online GLSL shader editor and validator with live preview

98 points by chrismdp 12y ago

dlsym 12y ago
Looks like the time variable is not updated... Update: Sorry - Time is just really slow there :D
Garthex 12y 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 https://www.shadertoy.com
- userbinator 12y 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/distfunctions.htm http://www.iquilezles.org/www/articles/distfunctions/distfun...
  - nfbush 12y ago
    Would you know anywhere that i could learn about all this glgs malarky, ddg isn't being helpfull...
- 3rd3 12y ago
  This site always blocks my browser. I wished the WebGL contexts wouldn't load right away.
- shuffle2 12y ago
  "pixar guy" is also "rgba guy" :) http://www.rgba.org/ http://www.rgba.org/
mixedbit 12y ago
Very nice! Consider adding an option to save a result as a multiline JS string (for inlining in JS code).
thegeomaster 12y 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 http://i.imgur.com/BGv8dL9.png
Robadob 12y 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 12y ago
this is really cool project. very interesting.
GrantS 12y 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.
deleted 12y ago
[deleted]
peetle 12y 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 12y 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-style-clock 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_ 12y ago
WebGL* * probably crashes browser
tripzilch 12y 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_ 12y 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 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.

98 points by chrismdp 12y ago

dlsym 12y ago

Looks like the time variable is not updated... Update: Sorry - Time is just really slow there :D

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 https://www.shadertoy.com

userbinator 12y 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/distfunctions.htm http://www.iquilezles.org/www/articles/distfunctions/distfun...
- nfbush 12y ago
  Would you know anywhere that i could learn about all this glgs malarky, ddg isn't being helpfull...
3rd3 12y ago
This site always blocks my browser. I wished the WebGL contexts wouldn't load right away.
shuffle2 12y ago
"pixar guy" is also "rgba guy" :) http://www.rgba.org/ http://www.rgba.org/

mixedbit 12y ago

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

thegeomaster 12y 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 http://i.imgur.com/BGv8dL9.png

Robadob 12y 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 12y ago

this is really cool project. very interesting.

GrantS 12y 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.

deleted 12y ago

[deleted]

peetle 12y 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 12y 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-style-clock 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_ 12y ago

WebGL* * probably crashes browser

tripzilch 12y 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_ 12y 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 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.