I started the summer off by getting more familiar with the existing p5 WebGL code. I read and watched the documentation created by past contributors. I also did a detailed stepthru of an example inside of the Chrome debug console and I was able to chart the code as it moved through the library.
This exercise was incredibly helpful in getting me up to speed on the existing code. After this was done Kate and I decided to make a document for planning and outlining all of the most pressing feature requests and issues related to WebGL in p5.
It quickly became apparent that we would need to prioritize certain features due to the scope of current requests and issues. Lauren and David helped us select our main goals and priorities based on which contributions were the most requested by the community.
I decided to try to tackle the way that geometry was being drawn. My early experiences with both Processing and p5.JS emphasized the idea of the fill and the stroke. Rich flat colors and high contrast are prominent visual traits of the 2D sketches made by one first learning either of these libraries. And while Processing has stroke and fill as the default drawing style for 3D geometry, p5 had yet to implement any approach to stroking or wireframing.
For my first attempt at this I decided to try using barycentric coordinates to render wireframes. I used an approach largely modeled on this blog post by Florian Boesch. Unfortunately the visual fidelity on models with a high density of vertices wasn't as good as I had hoped. I then switched over to drawing the geometry with GL.LINES instead of GL.TRIANGLES. This achieved the wireframe look but was not a long term solution because of the inability to change the stroke width or change the appearance of the lines relative to distance from the viewport. Still, I submitted a PR for this change because it also included useful changes to how Geometry buffers were being generated and stored which I thought would be useful later. But in order to get the desired results I knew that I would need to create polylines for the purposes of stroking. This was a big task and I didn't feel that I was familiar enough with the code to implement a change that large yet so I decided to handle some smaller problems throughout the library first.
Over the next month and a half I fixed a bug the library was generating in Chrome due to not having default textures bound to the geometry, added a loadPixels function for storing image data from the GL drawing context, created a get function for retrieving specific sections of the image drawn to the canvas, made it so that users can reset the context in order to modify attributes for the rendering context, smoothed the way that light shader was handling lighting when an object is wrapped with a texture, fixed a minor alpha bug, a minor translate bug, and abstracted buffer binding such that both Immediate and Retained mode could share the same function in the Renderer class
I then decided to return to the polylines task and with the help of my mentor and Andres Colubris I was able to figure out a way to take the vertices that make up an object, determine edges that should be lines, and expand those lines within the shader. With this done, I was able to open up the use of noFill(), noStroke(), strokeWeight(), and a few other familiar functions for users on the WebGL side of p5.
I also want to write extensive developer's documentation for p5's WebGL mode with the hope of lowering the barrier of entry for future contributors to the library. Currently Kate and I have put together a general introduction to the WebGL codebase for p5 but it would be great to make a more in-depth version.