Picking up the project again after a couple months off.  I went through Jamie King's game engine programming playlist, and I picked up some good ideas even though it ended before the engine was completed.  The first major change I did was to unignore the VS project files.  Those are necessary so that someone who uses this code can have the files organized in the same way that I do now.  Without them the user will have to piece the files together by guessing, and that is not ok.
Added a 3D triangle to my shape generator.  I worked it out on paper and then wrote the data into my program.
Failed attempt to incorporate vertex array objects on top of my existing code.  I may have to check back with previous code, hence my commit.
In the process of re-writing how the transformation matrix is used.  I can't figure out a way to continue to use it as it's own stand-alone vert buffer object (I think that there were some shady shenanigans happening anyway with the vertex buffer object bindings), so I am adopting what Jamie King did in the video 'OpenGL Vertex Array Object' and changing it to a uniform.
After much turmoil, I got the program into a state in which I have to bind the array and element buffers and set the attribute pointers for each cube and arrow that I draw.  I had a subtle error in my attribute pointers that tripped me up for a couple hours.  Next is array objects.
Finally fixed the vertex array object (VAO) problem.  My issue was that I had accidentally tried to initialize the VAOs before the vertex and index buffers, so the VAOs were getting initialized with NULL data.  This explains the memory access violation at 0x00000000.
Merged the cube and arrow vertex data into one buffer object and the index data into another buffer object.  This cuts my buffer count in half.  In this project that doesn't mean much, but it does in larger projects with hundreds of objects.  I had to adjust the vertex attrib pointers and the glDrawElements(...) call to compensate for the new data layout.
Added glDeleteBuffers(...) calls to the me_GL_window destructor to clean up after ourselves.
It took a few hours, but I finally debugged how to draw a plane of varying size that is centered on the origin!  As is usual with such calculations, the result was rather simple and my first go at it was almost correct, but it took a few hours plus dinner for me to find my mistakes and come up with proper variable names that facilitated understanding.
Changed my vertex structure to only use vec3s instead of vec4s.  I will leave the specification of the w (allow translation) / a (alpha channel) to the vertex and fragment shaders, respectively.
Added and adapted Jamie King's primitive generators for the sphere, torus, and his adaptation of Mark Kilgard's teapot generator.  The sphere and torus are currently commented out pending additional adaption, but the teapot works!
Changed camera default position to look down on origin instead of being at the origin itself.  Also, normals were added to the my_vertex structure last commit.  I forgot to mention that.
Got the sphere working.
Refactored Jamie's torus and got it working.
Enabled backface culling, but I had to adjust my torus index generation so that the face normals all faced outwards (I was at half-inwards and half-outwards).
Rotated the teapot so that it was right-side-up.  Also changed the the shape names in the me_GL_window.cpp code from 'cube' and 'arrow' to 'teapot' and 'torus', respectively, because that is what I am now drawing.
Added a plane (and adjusted the plane's index generation so that I had all forward faces instead of half forward and half back) and adjusted the teapot's and torus' locations and the plane size so that it was a good setup for the lighting stuff to follow.
Added an ambient light, enabled the normal vectors with glVertexAttribPointer(...) and the vertex shader, and started setting up the diffuse light.
Added a diffuse light, but it's calculation seems wrong because I have to move the light by quite a bit in order to center it over the plane.  I am investigating the plane's creation now.
The plane's construction is fine, but the dot product is somehow spitting out negative values and it changes from positive to negative in a linear fashion.  It should instead be transitioning from positive 1 directly below the light to nearing 0 far away from the light but never reach it, much less go negative.