8:00 – 9:30 VISIBILITY

• Checking up on email, trying to get access to the presentation slides for the demo, etc. I won’t steal Mikes thunder about progress with getting VISIBILITY swfs running

9:30 – 4:30 FP

• Advanced Shaders (Chapter 11)
• Geometry shaders run once per primitive. This means that it’ll run once per point for GL_POINTS; once per line for GL_LINES, GL_LINE_STRIP, and GL_LINE_LOOP; and once per triangle for GL_TRIANGLES, GL_TRIANGLE_STRIP, and GL_TRIANGLE_FAN.
• GL_LINES_ADJACENCY, GL_LINE_STRIP_ADJACENCY, GL_TRIANGLES_ADJACENCY, and GL_TRIANGLE_STRIP_ADJACENCY allow the geometry shader to get at the vertices that are adjacent to the particular piece of geometry that we’re interested in. I’d assume  that we can also manipulate those pieces, though I’m not sure that’s a good idea.
• Convolution filters can be generated as a texture (even an image), and then used to modify what’s being rendered. For example, the following should be usable as a blur filter, assuming that the weights add up to 1.0 (which could be done as a pre-processing pass on the data before the texture is made):
• 
• Got the demo that uses a fragment shader to draw a Julia Set kind of working.
• Tried to start Uniform Buffer Objects, but discovered that my brain was full.

8:30 – 1:30 FP

• Really good page: http://www.opengl.org/wiki/Common_Mistakes
• Advanced buffers – done
• Fragment operations (Chapter 10)
• Order-independent transparency using multisample buffers. Looks pretty straightforward. Need to add that. Possibly to ScreenRepaint?
• Advanced Shader Usage (Chapter 11)
• Physical simulation, such as meshes. Should be nice for network visualization…
• Found the reason for why screenwidth must be a multiple of 4 (from http://www.opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads):

• Texture upload and pixel reads

  You create a texture and upload the pixels with glTexImage2D (or glTexImage1D, glTexImage3D). However, the program crashes on upload, or there seems to be diagonal lines going through the resulting image. This is because the alignment of each horizontal line of your pixel array is not multiple of 4. That is, each line of your pixel data is not a multiple of 4. This typically happens to users loading an image that is of the RGB or BGR format (in other words, 24 bpp image).
  Example, your image width = 401 and height = 500. The height doesn’t matter. What matters is the width. If we do the math, 401 pixels x 3 bytes = 1203. Is 1203 divisible by 4? In this case, the image’s data alignment is not 4. The question now is, is 1203 divisible by 1? Yes, so the alignment is 1 so you should call glPixelStorei(GL_UNPACK_ALIGNMENT, 1). The default is glPixelStorei(GL_UNPACK_ALIGNMENT, 4). Unpacking means sending data from client side (the client is you) to OpenGL.
  And if you are interested, most GPUs like chunks of 4 bytes. In other words, RGBA or BGRA is prefered. RGB and BGR is considered bizarre since most GPUs, most CPUs and any other kind of chip don’t handle 24 bits. This means, the driver converts your RGB or BGR to what the GPU prefers, which typically is BGRA.
  Similarly, if you read a buffer with glReadPixels, you might get similar problems. There is a GL_PACK_ALIGNMENT just like the GL_UNPACK_ALIGNMENT. The default GL_PACK_ALIGNMENT is 4 which means each horizontal line must be a multiple of 4 in size. If you read the buffer with a format such as BGRA or RGBA you won’t have any problems since the line is already a multiple of 4. If you read it in a format such as BGR or RGB then you risk running into this problem.
  The GL_PACK_ALIGNMENT can only be 1, 2, 4, or 8. So an alignment of 3 is not allowed. You could just change the GL_PACK_ALIGNMENT to 1. Or you can pad your buffer out so that each line, even with only 3 values per pixel, is a multiple of 4.