At least one person asked on Piazza…
There is this problem of how to put your GLSL code into your WebGL program. The browser deals nicely with JavaScript and HTML, but now we have this third thing, and we need a place to put it. Unfortunately, there are 3 bad options. (option 3, is the “good” option, but it is problematic for class).
Option 1: Put the code as strings in your JavaScript code
This is just yucky. It’s bearable for very simple shaders and when you don’t want to explain a more complex solution. But the fact that you need to stick it into strings, and that JavaScript doesn’t allow multi-line strings, and you need to worry about escaping things in strings (generally not a problem with GLSL, since there aren’t weird characters).
It’s OK for a simple demo in lecture. But probably not want you want to do for anything bigger.
Option 2: Use a script tag in your HTML file
You can use the “script” tags in HTML to put shader script code in (just like you put in JavaScript code). You do need to set the “type” attribute to be something that tells the web browser not to interpret the script as JavaScript. And worse, setting a “src” attribute doesn’t actually load it from a file – so this only works for putting the scripts right into the HTML file.
So, in your HTML file you can write things like …
And then you can easily grab the string in your JavaScript code…
var vertShaderSource = document.getElementById("vertex-shader").text;
The good news is that your shader code isn’t in strings, and it isn’t hidden inside of your JavaScript. The bad news is that all of your shaders are in one file. And it’s an HTML file, so your editor’s syntax coloring won’t work.
This solution is supported nicely by twgl (and used in a lot of my demo code, see this one).
Option 3: Put the script into a separate file
The “right” answer is to put each shader into a separate file, and then load these files from JavaScript. This isn’t hard to do. However, there is a catch: JavaScript programs aren’t allowed to read files on the local disk (it’s a security issue – you don’t want some random web page reading your disk).
If you’re serving your program from a web server, this isn’t a problem. However, if you are doing development locally, this option becomes complicated. Often what people do is run a local web server (which is something we don’t want students in class to have to do). Alternatively, you can turn off the security in the browser, but we don’t recommend this (since you might forget to turn it back on). Also, some browsers are a little more lax about this (firefox).
What do we do for class?
For most students, I recommend Option 2. As we get into the projects, it will be a bit of a pain to have lots of shaders all in the HTML file, but trying to figure out how to deal with the security issue with files is one we don’t have a good answer for.
If you want to do Option 3, we can work something out. Make it clear in your instructions when you hand things in (the type-in box). We can use firefox (if you confirm that works for you). We’ll try to work out some other mechanism.
