8:00 – 4:00 FP

• Looks like I’ll have the CSIP project to charge to soon. Woohoo!
• debugging RightHand::drawPrimitive() – fixed. Passing by value rather than by reference. D’oh.
• Shiny hand model! Now I need to wire the graphics to the FingerIO classes – partly done, waiting on putting in the CollisionCube.
• 
• Tried adding the FingerIO classes directly to RightHand, but the class isn’t instanced by the time show() gets called in KF_GUI. So the FingerIO classes went back to the KF_Hand_window class, and I added pointers to the RightHand class. Not really happy with this, but it will do for now as I get all the other pieces working. And better than the alternative of grabbing the parent of the window class while still reaching into the RightHand class.
• Next, put all the changed code back into the fluid code – done
• Adding CollisionCube drawableObject – most pieces are in and I need to test.

4:00 – 5:00 CSIP

• Spent about 45 min talking CSIP with Ed.
• Start figuring out drools, with particular emphasis on creating xml that can be ingested and used to create running rule sets. Note that RulePoint could be a starting point for look-and-feel, as this may be the basis for the request for the system.

8:00 – 3:00 FP

• Now that the basic framework is put together, adding in the hand. Starting with making shiny cubes and cylinders.
• When making textures, *don’t* compress your tga files!
• Added a color modulated reflection shader. This will probably be our main shader for charts, too.
• Need to add a bit of lighting to the shiny objects. Going to finish building the hand fist.
• In the process of debugging RightHand::drawPrimitive().

8:00 – 5:30 FP

• Spring! That bears repeating. Spring!
• Working on the hand
• Building a new FLTK widget to show
• Communication with Arduino
• Force on each finger
• Volume for each finger
• Sound for each finger
• Hand view
• 
• Now I need to wire up the controls
• Added pointers to the pressure and volume sliders as well as the sound text within the FingerIO helper class. Works well.
• Wiring up the text output – done. Wound up using a simple multiline Fl_Output class rather than a Fl_Text_Output because when I tried to add a buffer, the code kept crashing trying to create a callback. Not sure that I was making the call in the right place?

8:00 – 4:00 FP

• Back to commenting the shader library. Done. Now I need to create the standalone documents and fix the commenting as needed.
• Downloaded and installed Doxygen from here
• Here’s the documentation!

8:00 – 4:30 FP

• Happy PI day! I wonder if there will be bigger celebrations in 2015?
• There is some planning for this: https://www.facebook.com/events/328804572620/
• Back to building libraries.
• Release Library is done.
• Adding test project to solution that tests the library
• Discovered that a dll was probably not the way to go, so changed the project settings so that it now generated a static library. For once, that was pretty straightforward – Properties->Configuration Properties->General->Configuration Type and select from the dropdown.
• Everything is compiling and linking, adding some actual content now.
• Well I’ll be damned – everything works (In debug and release mode!).
• Same old picture, but with much better foundations:
• 
• Installed AtomineerUtils, a nifty plugin if Visual Studio that generates documentation frameworks

8:00 – 1:00 FP

• Working on turning the base classes of ShaderLearning2 into a library
• Creating DLL and static libraries in Visual Studio 2010: http://msdn.microsoft.com/en-us/library/bb384835.aspx
• Adding copies of headers and libs to the dll project. Trying to make this self-contained.
• Added include directories to properties
• Added lib directories to properties
• Added the following additional dependencies under Linker->Input->Additional Dependencies:
• opengl32.lib
  glu32.lib
  fltkgl.lib
  FLTKD.LIB
  WSOCK32.LIB
  gltools.lib
• Yay! My test (Dprintf) is compiling and linking. Onward!
• Added the following to the “Ignore Specific Libraries”
• msvcrt.lib
  LIBCMT.lib
• Done with the debug version of the library, need to verify that it works, then do the release version.

1:00 – 4:00 VISIBILITY

• Demo – 2, actually. It went well, though we do need to add a ‘loading’ screen to the main project screen. It hung for an awkwardly long time.

8:00 – 1:00 FP

• DST == sleeeeeeepy
• Class from 10:00 – 12:00
• Going to start converting the hand to the new framework. I need to put some of these parts in a library.
• Cool thing for the day: http://vimeo.com/36579366

1:00 – 4:00 VISIBILITY

• Demo prep. Need to build a spreadsheet that has projects and timelines on them. Have a “most recent issue” column. Maybe a “number of times underbudget”  and “number of times late” columns as well
• The demo is now tomorrow at 2:00, though Dukes will not be there. So it looks like we will have an additional meeting/demo.
• Spent some time walking Sherry P through VISIBILITY and created an account for her on fgmdev Viztool

8:00 – 3:30 FP

• Uniform Buffer Objects! Whee!
• Urk: “Any type consuming N bytes in a buffer begins on an N byte boundary within that buffer. That means that standard GLSL types such as int, float, and bool (which are all defined to be 32-bit or four-byte quantities) begin on multiples of four bytes. A vector of these types of length two always begins on a 2N byte boundary. For example, that means a vec2, which is eight bytes long in memory, always starts on an eight-byte boundary. Three- and four-element vectors always start on a 4N byte boundary; so vec3 and vec4 types start on 16-byte boundaries. Each member of an array of scalar or vector types (ints or vec3s, for example) always start boundaries defined by these same rules, but rounded up to the alignment of a vec4. In particular, this means that arrays of anything but vec4 (and Nx4 matrices) won’t be tightly packed, but instead there will be a gap between each of the elements. Matrices are essentially treated like short arrays of vectors, and arrays of matrices are treated like very long arrays of vectors. Finally, structures and arrays of structures have additional packing requirements; the whole structure starts on the boundary required by its largest member, rounded up to the size of a vec4.“
• Need to write up a class that handles shared objects. Should be a variant on the dictionary pattern
• DataElement class includes name, type, size, etc
• UniformBlock class
• Defines the name of the Uniform Block
• Makes sure that there is room for this block, and the binding

  glGetIntegerv(GL_MAX_UNIFORM_BUFFERS)
  glGetIntegerv(GL_MAX_UNIFORM_BUFFER_BINDINGS)

• allocates the memory
• gets the block index

  glGetUniformBlockIndex(GLuint program, const GLchar * uniformBlockName);

•  returns pointers to data
• handles the writes into memory
• bind to the shader program (I think)

  void glUniformBlockBinding(GLuint program, GLuint uniformBlockIndex, GLuint uniformBlockBinding);

• Advanced Geometry Management (Chapter 12)
• Queries (picking, hopefully)
• Questions in OpenGL are represented by query objects, and much like any other object in OpenGL, query objects must be reserved, or generated. To do this, call glGenQueries, passing it the number of queries you want to reserve and the address of a variable (or array) where you would like the names of the query objects to be placed:

  void glGenQueries(GLsizei n, GLuint *ids)
  Gluint myQueries[10];
  glGenQueries(10, myQueries);
  for(int i = 0; i < 10; ++i){
      if(myQueries[i] == 0)
          // throw an error
  }
  // run queries
  glBeginQuery(GL_ANY_SAMPLES_PASSED, myQueries);
  glEndQuery(GL_ANY_SAMPLES_PASSED);
  
  // usually this should be available immediately, but be careful to handle the case if it isn't
  glGetQueryObjectuiv(myQueries[0], GL_QUERY_RESULT_AVAILABLE, &result);
  if(result == GL_TRUE)
      glGetQueryObjectuiv(myQueries[0], GL_QUERY_RESULT, &result);
  // do something based on the result
  // then when done...
  glDeleteQueries(10, myQueries); // free up space for more queries

• So the way picking would seem to work would be to set the viewport so that it’s slightly larger than the cursor, then render bounding boxes (using glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE)) inside a loop of questions, then read back (and wait for) the results of the question. If the object is visible in the small FOV, then we can regard it as picked.
• Setting up picking:

  	GLint viewport[4];
  	float ratio;
  
  	glSelectBuffer(BUFSIZE,selectBuf);
  
  	glGetIntegerv(GL_VIEWPORT,viewport);
  
  	glRenderMode(GL_SELECT);
  
  	glInitNames();
  
  	glMatrixMode(GL_PROJECTION);
  	glPushMatrix();
  	glLoadIdentity();
  
  	gluPickMatrix(cursorX,viewport[3]-cursorY,5,5,viewport);
  	ratio = (viewport[2]+0.0) / viewport[3];
  	gluPerspective(45,ratio,0.1,1000);
  	glMatrixMode(GL_MODELVIEW);

• The source for gluPerspective() is here
• Another way of doing picking – http://www.gpucomputing.net/sites/default/files/110606_picking_1.pdf

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.