4 ms·

Show HN: Js2glsl ShaderToy – Source to Source Compiler from JavaScript to GLSL

38 points by albinofrenchy 11y ago

albinofrenchy 11y ago
Some more examples from here: https://github.com/jdavidberger/js2glsl/blob/master/readme.md https://github.com/jdavidberger/js2glsl/blob/master/readme.m... Saving creates an anonymous gist for the shadertoy, if you run into any issues please do report them with the url! It is all in early stages, so I'm sure bugs abound.
bhouston 11y ago
It is neat and a nice implementation. Not sure I'd prefer it in place of real glsl, but I guess it can make shader writer more accessible for some that prefer JavaScript and have reduced use cases (because of the lack of flexibility that comes with using a translator like this.)
fulafel 11y ago
Related: https://github.com/xml3d/shade.js https://github.com/xml3d/shade.js & http://typedarray.org/shaderdsl-js-javascript-based-dsls-for-gpu-shaders/ http://typedarray.org/shaderdsl-js-javascript-based-dsls-for...
- albinofrenchy 11y ago
  Also: https://github.com/stackgl/glslify https://github.com/stackgl/glslify It doesn't do any js -> glsl stuff, but it is another packaging and reuse approach for GLSL
yoklov 11y ago
This is very cool. I'd have very serious concerns about using it in place of GLSL for a real project, but as a toy it's very cool. Seems to generate reasonable code as well.
overgard 11y ago
That's a pretty neat hack, but I can't think of a worse language for shader programming than javascript :-) Dynamic typing and closures are useful in some domains... but I wouldn't want to run that sort of logic per-pixel on a display with 14 million pixels. Plus declaring the types ahead of time is really important. (highp vs. lowp, type sizes, etc.)
- albinofrenchy 11y ago
  Since this drops directly into GLSL, it can't/doesn't support dynamic types or closures -- types are inferred into their GLSL equivalents. I do agree that being able to control precision is important, and as of yet I'm not sure the best way to implement that.

38 points by albinofrenchy 11y ago

Some more examples from here: https://github.com/jdavidberger/js2glsl/blob/master/readme.md https://github.com/jdavidberger/js2glsl/blob/master/readme.m... Saving creates an anonymous gist for the shadertoy, if you run into any issues please do report them with the url! It is all in early stages, so I'm sure bugs abound.

bhouston 11y ago

It is neat and a nice implementation. Not sure I'd prefer it in place of real glsl, but I guess it can make shader writer more accessible for some that prefer JavaScript and have reduced use cases (because of the lack of flexibility that comes with using a translator like this.)

fulafel 11y ago

Related: https://github.com/xml3d/shade.js https://github.com/xml3d/shade.js & http://typedarray.org/shaderdsl-js-javascript-based-dsls-for-gpu-shaders/ http://typedarray.org/shaderdsl-js-javascript-based-dsls-for...

albinofrenchy 11y ago
Also: https://github.com/stackgl/glslify https://github.com/stackgl/glslify It doesn't do any js -> glsl stuff, but it is another packaging and reuse approach for GLSL

yoklov 11y ago

This is very cool. I'd have very serious concerns about using it in place of GLSL for a real project, but as a toy it's very cool. Seems to generate reasonable code as well.

overgard 11y ago

That's a pretty neat hack, but I can't think of a worse language for shader programming than javascript :-) Dynamic typing and closures are useful in some domains... but I wouldn't want to run that sort of logic per-pixel on a display with 14 million pixels. Plus declaring the types ahead of time is really important. (highp vs. lowp, type sizes, etc.)

albinofrenchy 11y ago
Since this drops directly into GLSL, it can't/doesn't support dynamic types or closures -- types are inferred into their GLSL equivalents. I do agree that being able to control precision is important, and as of yet I'm not sure the best way to implement that.