Books hidden on Canvas…

by Mike Gleicher on October 21, 2015

You may not have noticed this, but if you are in the course canvas directory, and look under files, you will see all the books we are using in class, and have access to all (or most) of the chapters in one convenient place.

Some of the things that are there (because the names aren’t obvious…):

  1. JavaScript – The Good Parts – a useful guide to becoming a better JavaScript programmer.
  2. Fundamentals of Computer Graphics (our textbook)
  3. Practical Linear Algebra (useful for review)
  4. The Big Fun Graphics Book (the book that John Hart is writing)
  5. Purple – the WebGL “purple book” – “The WebGL Programming Guide” – I’m not sure why it’s the purple book. (I think it’s kindof blue/green). But its a decent tutorial for learning WebGL – we had some chapters from it. It’s an OK reference.
  6. Red – The “OpenGL Programmer’s Guide” – Historically, this was THE way to learn GL. However, with the new edition, the great tutorial aspect is gone, as instead it tries to teach you all the complexities of modern GL (which as we’ve learned, isn’t necessarily designed to be convenient). The examples are all C++ using OpenGL (WebGL is very similar).
  7. RTR – the Real-Time Rendering Book. This is a bible for interactive graphics programmers (like game graphics programmers). Except that the book hasn’t been updated in a long time, and it’s the kind of book that goes out of date. Great discussions of the key (advanced) techniques.

WebGL texturing examples

by Eftychios Sifakis on October 20, 2015

A few examples on texturing from the Tuesday Oct 20th lecture:

Starting point … a pyramid drawn as explicit triangles [JSBin]
Same pyramid drawn using indexed vertex lists [JSBin]
Cube with flat-shaded faces, drawn using indexed vertex lists [JSBin]
Cube with procedural texture [JSBin]
Cube with checkerboard texture, mipmap [JSBin]
A different texture, combined with face colors, mipmap [JSBin]
Options for handling texture coordinates outside [0,1] interval [JSBin]
Using Yusef’s Base64 encoding, mipmap off [JSBin]

From Oct 22nd:

Two textures used at the same time [JSBin]
Texture and lighting [JSBin]

From Oct 27th:

A simple bump mapping example [JSBin] (NOTE: This is intentionally hacky and actually incorrect! Just serves to show you the kind of look that you might obtain)

From Oct 29th:

Starting point for render-to-texture – same effect as previous examples, but avoiding Z-buffer test [JSBin]
Extremely simplified render-to-texture demo (uses previous example as a texture for each cube face [JSBin]

Late update:

Yet another way to read in local images, using the FileReader API [JSBin]

Loading Objects

by Mike Gleicher on October 20, 2015

You may have noticed, designing 3D object is a pain if you have to type in every single vertex position.

We want you to do this once or twice, so you can see how hard it is.

After that, it grows old. And you realize that to make a fancy object what you’ll really do is to make is using some modeling software, or scan it, or find it on the web. This means the model will be stored in some file format. So your program needs to figure out this file format, read it in, and convert it to your data structures.

Learning to understand a file format is good practice (we used to make students do it). But now, we’ll give you JavaScript code that will read in a common object file format. (OBJ files). You can find tons of OBJ files on the web. The reader won’t read them all (it doesn’t have all the fancy features, and a lot of files don’t conform to the specification).

Because of the file loading security issues (the same ones as shaders and textures), if your program isn’t being web served, you can’t load files. So we’re also giving you a web service that will take an OBJ file and turn it into a javascript file that loads the information into objects.

The OBJ Loader (and converter) were written by Yusef Sohail.

 

Loading Texture Images (Server Issues)

by Mike Gleicher on October 20, 2015

Getting image-based textures to work in GL is tricky – there’s the conceptual part (getting the texture coordinates, undertanding sampling, how to have you shaders access texture memory, …) and the mechanical part (how to feed texture coordinates as attributes, how to set up the shaders and get them access to textures, setting all the parameters, …). And then there’s the issue of actually getting the image into you program.

In theory, getting an image into a WebGL program is easy: web browsers are really good at loading images (to show them on web pages).

But, while it’s easy to get an image into a web browser, it’s much harder to get it to give your program access to it because of security concerns. So, the obvious methods for getting textures into your program won’t work. The issue is that your image files and the program that access them must come from the same place. And for some reason, some web browsers don’t consider the local disk the “same place.” This has nothing to do with graphics, it has to do with the subtleties of web security.

Just like with shaders, there are 3 options. None are great for class.

  1. Turn off security. Or use a web browser with different security policies. We don’t recommend turning off security (even for your own programs) because you might forget to turn it back on. While some browsers (Firefox) allow locally read textures to be accessed, there’s no guarantee that they won’t change their mind in the future.
  2. Use a web server. If you put everything on CS.WISC.EDU (like in your handin directory), everything comes from the same place, and all works fine. This is inconvenient for development (since you want to work locally, we assume). Most web developers run a local server. While this is the “right” choice, it is hard for class since we can’t help everyone set up a web server on their own machine. Plus you need to make sure things will also work on the CS web server when you hand things in.
  3. Put the image into a string in your program. This was a yucky option for shaders, since it made them hard to edit. For images it’s hard because you somehow have to pack the image into a string in the format that the browser will unpack. Fortunately, a former student (Yusef Sohail) made a handy utility that will do this for you. You upload an image (or a bunch) and it gives you back a JavaScript program that you can load in and it will have your images in strings. (it will even make the Image objects for you).
    http://graphics.cs.wisc.edu/Courses/559-f2015/Services/imagebundler/bundler.html

For your assignments in class, we recommend using option 3 because it’s easiest. If you use option 2, make sure that you test your program on the CS web server in your handin directory.

The Week in 559: Week 7 (Oct 19-23)

by Mike Gleicher on October 16, 2015

This past week, we learned about lighting and texturing. And you got to try out WebGL programming.

Next week, we’ll dive deeper into lighting and texturing to look at some of the more practical aspects of actually writing the code to do it. You’ll start to work on project 2 (with programming assignment 7). And be aware that the exam is lurking on the horizon.

So this week:

Monday, October 19th: Reading Assignment 7 is due. It discusses lighting and texturing – which we have already introduced in class. So the quiz should be a review. (yes, we’re having a quiz again – it’s good practice for the exam).

Tuesday, October 20th: Lecture on practical issues in Texturing. We’ll see how GL does textures. And hopefully work around some of the web security issues in working with images.

Thursday, October 22nd: Pre-lecture help session. The one last week seemed to work out well, so we’ll try again. Details will be posted soon.

Thursday, October 22nd: Lecture on advanced texturing. And possibly more on getting triangles to the graphics hardware efficiently.

Thursday, October 22nd: Programming Assignment 7 (the first phase of Project 2) is due. Make sure you understand the new handin mechanism. You might want to try it out before the last minute.

The following week…

There will be a Quiz on Monday October 26th. It will be good practice for the exam.

There will be a lecture on Tuesday morning, October 27th, and an evening exam. On thursday, programming assignment 8 will be due (another phase of project 2).

New handin mechanism

by jmishra on October 16, 2015

Hi Students

Looks like the old handin mechanism of uploading stuff to canvas is not working in a scalable and efficient way. So we have already devised a new handin mechanism. You might be aware of the CS ecosystem maintained by the CSL. All files are kept in a distributed manner on top of the Andrew File System (AFS). Your aim is to copy over your assignment files to a predestined location on AFS.

Do you know that each one of you has a CSL id and an email address of the form csl_id@cs.wisc.edu? If not, finding the CSL id is pretty easy. Visit https://csl.cs.wisc.edu and click on Student Info -> Activating your account. Log in using your NetID. It will say “Logged in as: your CS id” on the left hand side of the page. You can change your CS password if you want. Note that this password can be different from your NetID. They are two separate accounts. Now remember your CS ID.

The main motivation behind introducing this new handing mechanism is that uploaded projects can now be accessed from the CS web server in a straightforward manner without going through canvas.

Once uploaded, projects can be accessed online using a web browser from the following location.

https://pages.cs.wisc.edu/~cs559-1/handin2015

This will show you a list of projects. Right now we have only p6 and p7. Clicking on any one of them will take you to the list of students by their CS IDs. By default only the student, Professors and the TA can access a folder owned by a student. You will have to use your CS ID and password to access your folder.

But at this moment none of you have anything submitted in any of those folders. All empty! So let’s get to how to copy your creative stuff to the AFS folders.

GNU/Linux and Mac users can use the terminal to copy files. From the terminal, use the cd (change directory) command to go to the folder on your local disk which has all your JavaScript resources plus a single html file referencing those scripts. No need to zip anything now. We will not accept zip files. Assume your CS ID is teststudent. This is what will do the job.

scp -r * teststudent@galapagos-10.cs.wisc.edu:/u/c/s/cs559-1/public/html/handin2015/p7/teststudent/

Things to note about the above command:

  1. replace teststudent with your CS ID
  2. you can replace galapagos-10 with any CSL lab computer hostname. galapagos-10 will do the job just fine.
  3. replace p7 by the project in hand. Like p8 for project 8

If your submission had an index.html, you can now access it from the following link.

https://pages.cs.wisc.edu/~cs559-1/handin2015/p7/teststudent/index.html

It may ask for your login before giving you access.

If you uploaded wrong stuff and would like to delete everything and upload new stuff, you need to use ssh. This will give you a terminal prompt and you can use regular bash commands to delete or modify your submitted content. To ssh in GNU/Linux or Mac, use the following command.

ssh teststudent@galapagos-10.cs.wisc.edu

This will prompt for your CS password. After getting a terminal prompt, issue a command like the following to change directory to the correct location.

cd /u/c/s/cs559-1/public/html/handin2015/p7/teststudent/

Now delete or change your files. To upload new stuff, first exit the ssh session and then do another scp as mentioned above.

Every student folder for every project has a file called .htaccess which enforces the authentication you go through while accessing links to your project. This is done so that only the professors, the TA and the concerned student can access their stuff. However, if you would like to share your project with a colleague, edit the .htaccess file. The last line of the file lists users that are allowed access. Add your friend to the end of the list like your_friend’s_cs_id@CS.WISC.EDU. Never share your password with anyone. Once your friend is added, she can access your page using her own CS authentication. You may also delete this file so that anyone can access your files (useful if you want to show your stuff to friends outside of CS).

Windows users can use PuTTY for ssh and PSCP for scp.

You still have to post a link to your project in canvas and write a line or two describing it. The link should look like the following:

https://pages.cs.wisc.edu/~cs559-1/handin2015/p7/teststudent/index.html

Don’t ignore canvas completely. The new handin mechanism is only enforced for P7 and further projects. For P6 you will have to use canvas. However, to gain some practice you can also submit a copy of P6 in the manner described above. That way we can also gauge some issues and have them fixed before P7 is due.

Two very useful references

by jmishra on October 15, 2015

I just came across two very useful references for debugging JavaScript and using HTML5 canvas. They are very short and will require not more than a few minutes to go through.

Getting Your Shaders Into Your WebGL Code

by Mike Gleicher on October 12, 2015

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.

Help Session (P6, class concepts, …)

by Mike Gleicher on October 12, 2015

We will have a help session for class on Thursday, October 15th, 10:15-10:45, right in BioChem 1120 before class. (we’re saying 10:15-10:45 so we can have a little break before class, and while people come in for class, but we can keep going until class starts if there is enough interest).

It’s an odd time (but it’s been hard to schedule things), and an odd place (the room is pretty bad for interactive stuff). But, it is convenient for class, and the room is open in the time slot. We’re not sure how well this time slot will work for people, but we thought we’d give it a try.

We won’t have prepared material: please come with questions. If you don’t, we’ll try to guess at things to talk about – but we might not guess right. But, we’ll be happy to talk about any class topic, or JavaScript topic, or graphics topic in general, or…

If this time slot does work, we can make it a Thursday morning tradition.

Grading for Programming Assignments 3 & 4

by jmishra on October 10, 2015

I will start grading programming assignments 3 and 4 at 6 pm on Sunday 10/11. Make sure your latest edits are checked in before that.

← Previous Entries

Next Entries →