Transpiling shader from GLSL ES 3 to TSL

[AndreasRosdal]

Hello!

I am in the process of updating https://FreecivX.net from WebGL to WebGPU.

I am reaching out to the Three.js devs here for help to port the shader from GLSL3 to TSL.

This is the shader code:

freecivx/freecivx/blob/075e572bbff4376d52578e26df9b0b9c5d6535f6/freeciv-web/src/main/webapp/javascript/webgl/shaders_square/terrain_fragment_shader.glsl

I would like to use this transpiler:
https://threejs.org/examples/webgpu_tsl_transpiler

So I would appreciate some help porting this shader to TSL. Some questions:

• What is the best source for documentation for learning TSL? ( Three.js Shading Language · mrdoob/three.js Wiki · GitHub )
• The transpiler isn’t able to define the ‘in’ and ‘out’ parameters. The ‘out’ parameter should be the result colour. How can I port the in and out parameters to TSL?
• How can I initialize this shader in Javascript?
• How to I specify the shader data, such as textures, in JavaScript?
• How to I apply this shader as a shader material to the Mesh for the terrain?
• Are there any examples using WebGPU Shading Language (WGSL) directly on a Mesh in Three.js? three.js/examples/webgpu_compute_texture_pingpong.html at dev · mrdoob/three.js · GitHub

This is for the open source FreecivX 3D project. Thank you!

Andreas

[dubois]

I’m curious about the out qualifier, I understood that nodes support only one output?

[EliasHasle]

It looks like the transpiler is TSL → WGSL/GLSL, not the other way around.

I think TSL looks very interesting as a higher-level shader representation that can be compiled to various low-level shader languages. But the syntax is way less readable than the low-level shader languages, which makes me a bit sad. This is due to JavaScript’s lack of operator overloading. Now, if someone made an even higher-level language on top of TSL to allow a more readable syntax… Possibly just bindings in a language that compiles to JavaScript, even. Are there any such proposals? @sunag @Mugen87

[sunag]

@EliasHasle There is an example that uses TSL Transpiler and does the process on the fly, some shadertoy examples are running in GLSL on WebGPU and WebGL using TSL. I think the way to do this would be to improve the TSL compiler to provide better transpilations.

@makio64 has made great progress in this regard as well

GitHub - Makio64/vite-plugin-tsl-operator

I would also love to be able to use operator overloading natively, but that is an open question in JavaScript that can be changed. One thing we can be sure of is that TSL will evolve as Three.js developers need it and as JavaScript evolves.

TSL is quite new and I think we have a problem explaining its true purpose, as I see it is often misunderstood. The original proposal was never an intermediate language to deal with two backends, although that in itself is great, but rather to simplify the process of maintaining the renderer and shaders, which in GLSL/WGSL string replacement is a mess when we need to modify the core code and keep all the examples working. WebGPURenderer evolves very quickly because of these features, as it allows maintainers to create a lot of modifications to the renderer core without worrying about breaking shaders that have already been created by other developers. Other great benefits are the sharing of uniforms between materials because it is node-based, easy manipulation of bind-groups, MRT fully handled with native materials, rendering manipulation directly in TSL functions and several other things that I mentioned here that are only possible with a node-based approach.

[dubois]

@sunag

TSL is quite new and I think we have a problem explaining its true purpose, as I see it is often misunderstood.

Where can these explanations be found?

I ran across this, but it was already locked so I couldn’t ask questions.

Three.js Shading Language

[EliasHasle]

Thanks for the elaborate answer. Ah, now I actually found the TSL transpiler. Thanks! That looks potentially pretty useful.

I am getting started “vibe-coding” my own little library for converting TSL with conventional operator shorthands into valid TSL. There are some obstacles already, though. I wonder if it is realistic to keep the Fn blocks clean and pure, without texture loading, JS conditionals, etc.. Otherwise (and perhaps anyway!), there are ways in which type ambiguity may persist within the block. It is not that important to me that everyone can use my script with their own spaghetti coding style. I just try to make sure that it accommodates my spaghetti coding style in a feature-complete way.

[Makio64]

@sunag

The original proposal was never an intermediate language to deal with two backends, although that in itself is great, but rather to simplify the process of maintaining the renderer and shaders, which in GLSL/WGSL string replacement is a mess when we need to modify the core code and keep all the examples working.

You point out a real communication problem as I forgot it as well..

On the subject, @AndreasRosdal the Transpiler will be your best tools for porting the thousand of shaders existing in glsl, but you also have to understand the logic of the node system itself, and take advantage of webgpu, its a mind gymnastic.

My plugin for vite make the TSL synthax less heavy, for fast coding / iteration but it’s a matter of preference and didnt change at all the output ( like babel / typescript / etc.. ).

About the TSL point, I was discussing with fellow talented webgl and a fact surprised me: Almost none of them knew what .toVar() was doing concretly.. TSL learning curve is like react learning curve but we also discuss the long term benefits as @sunag underline it

@sunag

Other great benefits are the sharing of uniforms between materials because it is node-based, easy manipulation of bind-groups, MRT fully handled with native materials, rendering manipulation directly in TSL functions and several other things that I mentioned here that are only possible with a node-based approach

Good luck for the porting, especially the first one it might be hard..