TSL is not really a language to be pedantic, because it is an EDSL to build a common AST that can be translated to the target shader language later. All caveats for the overly eager evaluation and usual impedance mismatch between JS and TSL data model also apply here.
I've seen this done in C++ for generating GLSL before a few times.<p>One from Waterloo Univeesity in the early 2000s became RapidMind: <a href="http://web.cs.ucla.edu/~palsberg/course/cs239/papers/rapidmind.pdf" rel="nofollow">http://web.cs.ucla.edu/~palsberg/course/cs239/papers/rapidmi...</a><p>There were a few others, but I can not remember their names.<p>Generally these techniques work, but for some reason they tend to die out.
Looks interesting! There is always a tension between high level paradigms like this and just writing the damn GLSL. glslify is another solution in this space that lets you have more fine control over the GLSL, which is usually way less verbose than a high level API.
Almost like the old days of fixed function pipelines. The example at the top seems a little contrived, I wonder why you would build a shader like that.
This is what happens when everyone decides to break compatibility with the shading languages for the Web, instead of what happened with Khronos APIs on the native side.<p>On the other side, it is business as usual given GLSL, HLSL, MSL, Slang, PSSL,...
What if we stopped adding layers of abstraction? The idea of renderer-agnostic shaders is cool, but in general you want to write your shaders for a specific renderer for best performance.
One thing I'd love to see is whether bundlers can "statically compile" the TSL nodes via constant propagation into a single template literal.
Has anyone taken a crack at building a shading language debugger?<p>I want to be able to step through a shader and see the values at each step (ideally for any / every pixel)<p>The best case scenario would be while it's actually running, but simulating it seems like a great solution too.<p>These are the best I could find: <a href="https://github.com/burg/glsl-simulator">https://github.com/burg/glsl-simulator</a> and <a href="https://github.com/cdave1/shdr">https://github.com/cdave1/shdr</a> - both seem to be missing a fair amount of features, though shdr seems like much better support.<p>There's also: <a href="https://glsl-debugger.github.io/" rel="nofollow">https://glsl-debugger.github.io/</a> but it doesn't support OS X and feels quite out of date.<p>There's "print statements" for wgsl: <a href="https://github.com/looran/wgsl-debug">https://github.com/looran/wgsl-debug</a><p>I guess WGSL is the up and comer... as opposed to GLSL - but both would be great.<p>Anyone else have this hope/dream?<p>The hacks I use today are crazy - like conditionally exiting early based on a time variable and mapping values to colors.<p>So many folks I talk to are like, "yeah that's how it is". But this just seems not good enough to me...
My first thoughts as a technical artist is that TSL should be abstracted to a VPL like most shader artists are used to whether it's the nodes in Unreal, Blender, Vray etc. They're already starting with three.js playground, but this would allow any traditional shader artists in gamedev or really any industry related to 3D to create really awesome shaders using the same exact workflow they're used to on other apps.