Lab 0

Getting started

There is no deadline. Yay!

This lab is just to get you started, to figure out the computing equipment etc. and will NOT be graded. The best thing to do at this point is work through some WebGL tutorials or examples. This are links to the slides of the tutorials held in the last year: OpenGL Javascript WebGL, Recap Rendering Pipeline Uniforms and Recap + Textures
If you are completely new to javascript you should take a look at some tutorials here as well. In the Tutorial it will no be explained in detail. Some links to get started are listed below.
For Javascript as well as for WebGL it's not a bad idea to read through a textbook or see what kind of online tutorials you find. If you find some great ones, please let us and your colleagues know. There are a couple of things that you should understand and learn during this process:

Debugging

This will occupy some of your time. The main thing is to have a plan on how to debug your program. Start simple and build your program step-by-step, so you can debug each step and figure out whether there are errors in each step before you move on. Always use simple data sets at first. Google Chrome already comes with a set of tools for web development (Tools >> Developer Tools or Tools >> JavaScript Console). Be sure to get familiar with them, they are very handy. There is also a WebGL debugger available, you can download the chrome-extension here.

As a general hint for debugging, there are a few principles that you can follow:

  • Understand the Problem: Try to isolate the problem and to reduce the amount of places in your code that could contribute to the error. In CG applications more often than not you will end up staring at a black screen, wondering why on earth your code does not work. Try to use debugging output to gain some insight, or hook up a debugger to see what is going on.
  • Reduce the Error Case: Try to reduce the error case as much as you can. For instance by commenting out parts of the code. Is the error going away, does it manifest itself in another way?
  • One Step At a Time: When facing an error, don't change the code in a hundred different places and then see if the error is gone. Chances are, some of the changes actually helped, some had no effect and some made it even worse. The problem: There is no way of telling which changes exactly did the trick.
  • Use a Source Control Management Tool: Just like for all the other things use a source code management tool. It allows you to go back a few commits and identify where the error occurred first, track back the changes and maybe find a solution to it on the way. Hint: Commit often!
  • Debugging Shaders: Debugging shaders is a bit different from debugging your standard client code. It runs on remote hardware (we are having a client server model here) and you cannot hook your debugger into it to step through your shader programs. To make matters worse, printf debugging is also not an option. What you can use though is the shaders' equivalent of printf debugging. You want to inspect the value of some variable in a shader? Set the output color of the fragment to that value and see. Hint: Output values are usually in the [0, 1] range, make sure to scale the variables you want to debug accordingly.

The Khronos WebGL wiki has a page about debugging as well.

Links

WebGL

A very good site to get started with WebGL is Learning WebGL. There you can find a bunch of well-written tutorials, and also the source code for them. We will use this examples in the tutorials. Be sure to check out the website's blog/news-page, there you can find many links to WebGL-based eye candy!

The Mozilla Developer Network has also some code snippets and explanations to get started. There's also a list of further resources.

The official WebGL site from Khronos Group could also be of interest (Especially the Specification in case you're looking for parameters etc.). They are also maintaining a wiki with a lot of useful information.

It is recommended to use an existing math and matrix library, so you don't have to code all the math functions your self. We used gl-matrix for our demos.

Many helpful tips on how to gain performance for your WebGL program: Google I/O 2011

WebGL Demos

There is a list of demos in the Kronos maintained wiki.

Shadertoy is an interactive playground to toy around with shaders and realize amazing demos. It is all interactive, comes with (shader)sourcecode to all the demos and illustrates what is possible in shader programming. It might also crash your browser from time to time :D.

Google also has a page with WebGL Samples, and a great webgl-utils lib.

JavaScript

Douglas Crockford is a good source for everything JavaScript. His book is a good starting point JavaScript: The Good Parts and is available in print and all the other digital flavors you'd like.
On his website you can find even more JavaScript related stuff.

To write quality code, having a static code analysis tool can be quite handy. Crockford's instantiation for js is JSLint. It comes in the form of a web base tool, but standalone command line clients are also available. Some of the style decisions it enforces are quite particular, but you can and should tune it to the style you prefer.

To play around a little bit and understand javascript, as well as interacting with css and html JSFiddle is a good starting point. You can interactively change your code, view the results and get some help in finding errors.

In case you do not have programming knowledge background, you could the the Javascript course at codecademy. They also have many other courses on css, php, jQuery,.... For computer scientists as you the lessons will probably be too low level

The binding of JavaScript.

To end this section on a lighter note, this video pretty much summarizes what is wrong with JavaScript. WAT!

Web Stuff

JavaScript wont allow you to read arbitrary files from your hard drive. While this is an important security feature, it gets into your way when writing WebGL applications that require loading resources like shaders and textures.

You can work around this limitation by either telling your browser to ignore this security feature (not recommended) or to simply use a simple HTTP server while developing your application. This page lists a few options you have for ad-hoc servers.

Another thing that might bite you is caching. HTTP allows for some caching at various locations, most notably in your browser. If your application behaves weirdly, try clearing the browser's cache, or maybe even restart the server.

Books

A helpful book on WebGL -- Matsuda, Lea: "WebGL Programming Guide." Addison-Wesley, 2013.

Nice book on JavaScript: Crockford, Douglas: "JavaScript: the good parts." O'Reilly, 2008.



Last modified: February 03, 2017
Lukas Herzberger / a1006039 AT unet DOT univie DOT ac DOT at