Tinsl Is Not a Shading Language
Total Page：16
File Type：pdf, Size：1020Kb
TINSL: Tinsl Is Not a Shading Language by Cole Granof A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE In partial fulfillment of the requirements for the Degree of Master of Science in Interactive Media and Game Development May 2021 APPROVED: Professor Charlie Roberts, Major Thesis Advisor Professor Gillian Smith, Thesis Reader Jennifer deWinter, Head of Department Abstract The fragment shader is a powerful, efficient tool for image process- ing. However, shaders are often unwieldy to use, even for simple post- processing operations. We have developed multiple systems in order to simplify the use of fragment shaders for image processing, and applied these systems across different domains, including live coding, creative cod- ing and game development. Through this iterative process, it became clear that a custom domain-specific language (DSL) could simplify the author- ship of a non-trivial rendering pipeline that involves multiple fragment shaders. As a result, we developed Tinsl (Tinsl Is Not a Shading Lan- guage) which is a DSL for specifying multipass render-to-texture (RTT) post-processing effects. This language uses the familiar syntax of GLSL, but adds semantics for specifying how to utilize temporary textures. This \shader metaprogramming system" enables live coders, creative coders and game developers to create complex post-processing effects that in- volve feedback and multipass blurs in a single file. We evaluate the ef- fectiveness of this system using Petre and Greene's cognitive dimensions framework to provide a qualitative analysis. We also perform a user study that gathers feedback from participants who were asked to follow a short tutorial on the language in a web-based creative coding environment. We released the software as a set of open-source libraries and programming environments. 1 Contents 1 Introduction 4 2 Background 4 2.1 Shader Metaprogramming . .5 2.2 Live Coding . .6 2.3 Multipass Effects in Different Environments . .7 2.3.1 Unity . .7 2.3.2 TouchDesigner . .8 2.3.3 Shadertoy . .8 2.4 Implementing Bloom in OpenGL with GLSL . .8 3 merge-pass 10 3.1 Applications . 11 3.1.1 Marching.js . 11 3.1.2 post5 . 12 3.1.3 artmaker . 13 3.2 Regions . 16 3.3 Limitations . 17 4 Tinsl 18 4.1 Language Features . 19 4.1.1 Static Type Inference . 19 4.1.2 Immutability . 20 4.1.3 Default and Named Arguments . 20 4.1.4 No Preprocessor . 21 4.1.5 Color Strings . 23 4.1.6 Render Blocks . 24 4.2 Implementing Bloom in Tinsl . 24 4.3 Error Reporting . 26 4.3.1 Type Checking Expressions . 26 4.3.2 Checking Texture Numbers . 27 4.4 Live Coding Environment . 28 5 Evaluation 29 5.1 Cognitive Dimensions Framework Analysis . 29 5.1.1 Abstraction Gradient . 30 5.1.2 Consistency . 31 5.1.3 Diffuseness/Terseness . 32 5.1.4 Error-proneness . 32 5.1.5 Progressive Evaluation . 34 5.1.6 Viscosity . 35 5.2 User Study . 35 5.3 Code Analysis . 37 2 6 Conclusion 39 7 Acknowledgements 41 A Donut Code 44 B Tutorial 44 B.1 Survey Code . 48 C IRB Approval Certificate 49 D Additional Screenshots 50 E Survey Results 52 3 1 Introduction Despite graphics programming being an endeavor often fraught with technical hurdles, fragment shaders are, by contrast, surprisingly elegant. A fragment shader is a small program that runs once on every pixel to produce a final output. The GPU (graphics processing unit) in a computer specializes in parallelizing these kinds of operations. One area where the elegance of fragment shaders shine is in live coding. Live coding environments offer a playground-like user interface to rapidly see the results of editing programs, often in real time; the simplicity they offer enables these environments to be used in audio-visual performances. Many graphical live coding environments focus on fragment shaders, abstracting away the tedium of dealing directly with graphics API (application programming interface). However, single fragment shaders operating with a single texture can only do so much. Many post-processing effects can only be implemented (in a reasonably efficient way) by using temporary rendering targets and running multiple passes. This form of control flow is outside the scope of the fragment shader. We hypothesize that a DSL could allow programmers to write logic for render-to- texture (RTT) steps directly alongside shader code. In this paper, we discuss the language we created, Tinsl (Tinsl Is Not a Shading Language) which has the succinctness and familiarity of a shading language like GLSL (OpenGL shading language). Unlike GLSL, Tinsl also lets the user specify intermediate rendering to off-screen textures, and sample from those textures later in the effect. The compiler divides (and combines, where possible) the operations into multiple fragment shaders. The compiled output of this language is a tree with leaves containing fragment shader source code. We have also created a live coding environment that focuses on writing post-processing effects on webcam video with Tinsl code. This has the dual purpose of testing the core design of Tinsl, as well as offering live coders a unique tool to enhance performances with easily-authorable multipass rendering techniques. We will also discuss merge- pass, which is a post-processing effect library that offers an API in TypeScript, and highlight the domains where it has been applied. Tinsl is not written on top of merge-pass; it is a completely separate library. We evaluated Tinsl using Green and Petre's \cognitive dimensions frame- work" to perform a qualitative analysis. We also performed a user study to gather feedback on the design of the language. Finally, we perform a quantita- tive analysis based on lines of code needed to implement a \bloom" effect on an image with Tinsl and without. 2 Background In this section, we offer a brief history and explanation of shader metaprogram- ming techniques, and where these techniques fit into the current landscape of graphical apps and games in the web browser. We will also go over existing theory about live coding systems with examples. 4 2.1 Shader Metaprogramming In the paper \Abstract Shade Trees", the authors note that GLSL lacks modern language features for encapsulation and abstraction, making it \hard to create and maintain long GPU programs" [14, p. 1]. While this remark was published in 2006, there are many domains where this is still the case. This problem is especially acute when we consider the web world, where we are limited to earlier versions of GLSL. \Shader metaprogramming systems" are one solution to these problems and surprisingly common in the world of game engines and other high-performance graphical applications intended to run on native hardware. Metaprogramming techniques range from simple textual replacement, DSLs embedded in higher- level languages, and even forks of existing shader compilers. \Sh" is perhaps one of the earliest examples of bringing high-level programming features to shader development. It is a C++ API that provides a metaprogramming language for shaders with operator overloading and macros [13]. Such an approach would not be feasible for a language that does not provide such features natively, like Java or JavaScript. (Sh eventually developed into the RapidMind Multi-core develop- ment platform at Intel; both systems are no longer maintained [20].) Other em- bedded DSLs for shader metaprogramming exist in Haskell and Python [6][12]. Slang is a relatively recent example of shader metaprogramming. Slang extends HLSL with modern language features that help with managing com- plexity, such as generics and interfaces [10]. Instead of being implemented as an embedded DSL leveraging the features of the host language, the team behind Slang accomplished this by developing a custom compiler. Robust shader metaprogramming techniques are not as prevalent in web pro- gramming; the solutions that have been engineered have suffered from waning or non-existent maintenance in recent years. When WebGL was a relatively new standard for browsers in 2012, David William Wallace made the observation that \WebGLSL lacks many high-level language features such as user-defined names- paces and modules" [22], which mirrors the comments made by by McCool et. al. in 2002, who note \custom shading languages usually will not be as powerful as full programming languages. They often may be missing important features such as such as modularity and typing constructs useful for organizing complex multipart shaders" [13]. In an effort to make building large-scale 3D applica- tions for the web more manageable, Ashima Arts developed gloc, which is briefly described in the paper \gloc: Metaprogramming WebGL Shaders with OCaml". It would appear that this library is no longer maintained as the latest commit is from May 2012.1 Another library, glslify, attempts to bring shader modularity to the web, allowing the user to make use of many prewritten shader functions. This open-source project is no doubt still used by many, however contributions to this project have slowed down considerably. The latest official release is from 2016, and glslify still lacks proper WebGL 2 and GLSL 3.00 support.2 1To the best of our knowledge, the most recent version of gloc is only available at this link: https://github.com/dsheets/gloc 2As of April 2021, this 2015 issue on the GitHub page of glslify is still open, which can be 5 String concatenation and textual replacement is certainly a form of metapro- gramming, in the sense that it is code that manipulates other code as data. In general, this is what we see in PlayCanvas3, Babylon4 and Threejs,5 which are three popular open-source platforms for 3D programming. These frame- works/engines treat the shader code as a \black box".