VU Graphics

Lab 0

Due: Sunday, March 17th 2024, 23:59

Start Early!!!

Objectives:

To understand the Web GL pipeline initialization.

Do the following before you proceed:

Get a copy of the required book
Find it's online repository and study the practical examples.
You have a fridge full of nutritious food.

Goals:

Create a simple WebGL application. The focus is on setting up the Web GL pipeline and writing all the boilerplate code so that you can dive into the next lab without having to worry about Web GLs initialization.

Tasks:

Follow this guideline step-by-step. Make sure that you thoroughly test your program after each step so that you can find bugs easier and quicker.

Programming

Set up a basic WebGL program, which initializes the drawing window. Draw a simple triangle. (This will not be checked for plagiarism, feel free use code you find on the internet, however make sure you understand it)

Administrative

Provide proof that you have a copy (physical or digital) of the required book (Please do not submit the entire book, just cite a paragraph of you liking, Chapter + Page)

Tutorial

Provide a link to your favorite WebGL Tutorial and submit a paragraph of what could be improved about this particular tutorial

Helpful Links

WebGL

A very good site to get started with WebGL is WebGL Fundamentals. There you can find a bunch of well-written tutorials, and also the source code for them.

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

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.

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

There are countless tutorials and resources for learning JavaScript accessible for free on the internet. A comprehensive tutorial that covers basic and advanced concepts can be found, for example, here.

Having a useful IDE or text editor can greatly enhance your productivity and help you find simple errors more easily. Most people already have a strong personal preference when it comes to IDEs - if you are not sure what to use, you can take a look at this site.

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.

The binding of JavaScript.

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, textures and object data.

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. One of the easiest ways of doing this is using Python, see this page for more info.

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.

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.

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.

Submission

Be sure to double check your final submission by unzipping it in another directory on a different computer
Be sure to submit any comments or remarks in a 'readme.txt' file.
Submit your files on Moodle.
Include everything required by your program in your submission including: objects, textures, etc...

Grading Criteria

Grading the labs will be based on the following:

100%: Correctness and adherence to assignment specification.
up to -10%: Bad readability and structure of code, no use of comments, bad indentation, etc.
up to -5%: Bad efficiency and speed (only an issue if its very inefficient)
up to -5%: No adherence to lab procedures (submitting, naming conventions, etc)

In order to get a full mark, you need to do all of the assigned tasks AND adhere to lab procedures while creating readable and efficient code. I.e. if you accomplish only 70% of the tasks correctly, but you do not adhere to lab procedures, your final mark will be 70*(1-0.05) = 66.5%.