I’m an MIT-trained engineering leader in the SF Bay Area. By day, I build, manage, and scale high-velocity software development teams. By night, I keep my technical skills honed by programming a range of side projects. Some of my projects and experiments follow.
You’ll see some themes: Visual Flow Programming, 3D Geometry / CAD, Web Browsers doing things servers normally do, and connections to my computational design master’s work. Most are demo-able in some way. If something catches your eye, please reach out.
Orchestra has two especially interesting areas technically.
First, the workspace view. Proofs of concept using simple svg or canvas rendering showed that the curved wires connecting components became untenably slow for even very small Orchestra projects, perhaps with only a few dozen components in the workspace. So I switched to WebGL rendering, which enables me to zoom, animate, and selectively redraw wires performantly. However WebGL makes other display requirements harder. Simple CSS styling is helpful, but for a project where users need to read and type input text as well as trigger numerous browser-like interactions such as hover, click, and drag, writing everything in WebGL implied a step function in complexity, given the free stuff that comes with normal DOM elements and CSS.
Orchestra uses both simultaneously. A WebGL layer and CSS layer with normal DOM elements are superimposed, and controlled simultaneously by threejs. CSS transforms allow the HTML to zoom smoothly, while WebGL allows very large workspaces to render without performance hits.
Secondly, Orchestra tackles the challenging problem of tracking changes that occur anywhere inside the user-generated “graph” so it can understand (even without understanding Python) when components will require recalculation and updates. It does this using the idea of a “pulse” that propagates though the graph from any input that changes. As the pulse propagates, it counts the number of times it sees each component so that later, during the recalculation phase, components can ignore change events that would trigger duplicate calculations.
Documentation for the installation and use of Orchestra exists at the Github links below.
Dates:2017 – Ongoing
Explorations:Superimposed DOM and WebGL zooming user interfaces; Graph mapping by “pulses” to prevent costly extra calculations
The rare open-sourced work project! I was its sole contributor, one of my last projects before leaving. The STL Thumbnailer is designed to create fast previews of user-supplied STL files. The previews are simple wireframes, without lighting or textures (limitations imposed by the dependency Node-Canvas), but they come back fast. Very fast. Autodesk’s “Forge API” has a service that provides thumbnails. They do have lighting and textures but they look terrible and take a very long time (usually 5-6 minutes). By contrast, this open-source NPM package returns nice-looking wireframes in high resolution in fractions of a second.
It works by creating a ThreeJS scene, importing the STL, then rendering it using Node-Canvas, and returning the image to the user (in this case, a node developer). It’s possible, using this package, to create a simple “STL Thumbnailer” service in a matter of minutes. Instructables uses this for all user-uploaded STLs to create friendly previews before loading the full 3D view of the model.
Explorations:Server-side creation of WebGL scenes, sans GPU
Quarto was born of a surprising problem: my wife and I, both architects by training, were unable to find a simple iPad app that served our needs for an architecture portfolio. We wanted an app with absolutely no cruft that could safely be handed over to an interviewer without worrying that they would push the wrong button (ie, zeroadmin UI). Similarly, all of the interactions needed to be completely expected. It should work like the “Photos” app, but give better controls for organizing which photos appear and, ideally, be built on a laptop and sync’d to the iPad (rather than trying to build on the iPad itself).
My work involved creating a build process for Jimp which would allow it to run in the browser, in a web worker, so that I could use it in Quarto (and save having to pay for a real server!). This actually works surprisingly well. Though it pushes the bounds of what browsers can do these days (and indeed, I see occasional browser crashes while uploading large numbers of large image files), client-side image transforms turn out to be a practical reality in cases where upload speed is critical (time is saved because there’s no “processing” step) or server-side resources are limited. Performance is considerably better than canvas, and not as crash-prone.
Explorations:Build libraries intended for NodeJS to run in web workers. Self-guided product management. Direct-to-S3 uploads using signed PUT URLs to S3, so that large data never touches the small server.
Github:Closed source, but if you’re really curious let me know.
Finally, Orchestra3D employs an especially rigorous approach to the hardest problem in flow-based programming: management of lists of data. Orchestra takes its cues from Grasshopper, a tool used for flow based programming in CAD (Rhinoceros 3D, specifically) where list management is fully and thoughtfully resolved. Orchestra3D mimics grasshopper behavior carefully. I built close to 100 unit tests based on expectations manually lifted from grasshopper, then worked to ensure they all passed in Orchestra.
Orchestra3D is my “forever project”, one which started years ago with my work on the design and fabrication of the “Soft Rocker” exhibit for MIT’s 150th birthday. From there was born the desire to take an extremely expensive and complicated 5-axis milling process based on professional CAD, and make it possible to execute on an inexpensive 3 axis machine, with no CAD expertise. I’m surprisingly close. Ask me about it!
The server side of this application does comparatively little, serving mostly as a CRUD API for project data and providing basic authentication and notification services required of most web apps.
Dates:2012 – 2016. Forked and continued as Orchestra Data Science.
Github:Repo includes the entire application, including cross-compiled SISL, Orchestra itself, and the Web App in which in lives. (TODO: Separate the parts)
Live Demo:Some examples are available for playing around without logging in. A video of Orchestra3D in use is on the homepage. Because this project remains unfinished, I’m not currently allowing new account creation at this time. Create new components by typing in the “new component” field,
and seeing what comes up. Absent tutorials, Orchestra3D is hard to use. Try Orchestra Data Science if you really want to learn it!
Through associations while working at Pier 9 / Instructables, I became involved with a non-profit called the E-nable Community Foundation which provides low-cost 3D-Printed Prosthetics to those with limb differences. I was involved with the non-profit only for about a year until my son was born. During that time I provided the base proof-of-concept for their now-product, Limbforge, which enables browser-based configuration of the Printable Prosthetics.
Though I really only did a few night’s work for Limbforge, the technical architecture is what they still use today. Prior work had attempted to parameterize every model in code using OpenSCAD on the backend, but it created serious problems for the project:
Prosthetics CAD Designers were unfamiliar with programming, so could not express their designs in code. Programmers were then required for even the smallest change to the models, which were complex.
Generating each model on the fly was slow
Visual feedback needed to be rendered before results could even be evaluated by the user
The new approach generated hundreds of “pre-baked” sets of parameters by scripting for Fusion 360, the CAD program in which models were originally parameterized. My work essentially became a 3d model viewer that allowed selection of parameters that would “choose” a file that already existed, and show it immediately.
Explorations:Changing technical approach from a prior iteration of the project. Zipping combinations of files and triggering the download entirely on the frontend.
After acquisition, Instructables moved to Autodesk’s Pier 9 where thousands of monthly visitors need an introduction to what Instructables is. I was commissioned (outside of work) to build a large (52″) touch-screen display. I used the web browser as the display platform both for its familiarity, and its portability. A web-based version was easy to make public.
An extensive writeup of how the Galaxy was developed is documented in the Instructable. This was an early journey into WebGL for me (my first, I believe), so it included a lot of learning along the way.
The big challenges, once I chose WebGL as the path forward, related to figuring out how to make the Galaxy look natural and move fluidly without animating each star separately. I ended up creating several “clusters” of stars that move together, but along slightly different axes and in different directions.
Other interesting explorations: procedural code that can draw something that feels like a constellation connecting an individual author’s stars (hint: no overlapping lines, mostly closed shapes but occasional open edges, no more than five connections to any one star). Other procedural code (written in processing) to make “nebulous” looking background images. Collecting data from Instructables APIs to represent approximately 20,000 of the most popular projects (written in Python, but not part of the repo).
Dates:2012 – 2013
Explorations:Particle Systems in WebGL, Vertex and Fragment Shaders, Suggestive Constellations and Clouds
Github:Repo includes the entire application, excluding bits that touch private Instructables APIs
Live Demo:https://galaxy.phil-seaton.com/ Search for an author to see their projects (try “randofo” or “pseaton”) in a constellation. From a project click its category to see the cluster of related projects light up bright!