I've been involved with, wait, I'm Stuart Allen, here, can reach me that email address.
I've been involved with open source since the early 90s, dabbled in Linux kernel development,
but mostly my projects have been stand alone applications and libraries, been the technical
founder of several companies over the last 30 years, and I've managed to thread open
source work through those companies and got them to release pretty significant packages
as open source internal works that have data processing libraries and things like that.
And over the last 10 years, I've become increasingly enamored with the idea of not having to install
software anymore, at least not on the desktop.
So I'm going to walk you through a little bit of back story for that.
I don't like slides, so most of this will actually be a live demo of different applications
walking you through the functionality, but I will walk through just a little bit of the
technology in the back story for that first before sort of hopping into this.
So to be a bit of a high wire act, let's see here, bullet points, excellent.
So this is just the rough order of things that I'm going to talk about.
I'm not good at following directions, even when I've written them, maybe especially when
I've written them.
So I might wander a little bit, keep me on topic if I do ramble a little bit, or if I
talk too quickly.
Definitely let me know.
I'm prone to do that, which is why I didn't have any espresso today, at least not told
this is over.
Okay, so on to a little bit of back story.
All right, since we are talking about maker tools, I wanted to just have a slide about
making, but not dwell on it too long.
While I was organizing these slides, it always turns into something other than what you start
out.
I had an idea when I went to this, and then what came out of it was kind of different,
but the exception of the demo parts.
It occurred to me that the proliferation of really powerful and accessible tools has turned
really everybody into makers.
And this is historically anomalous, like we've had tools in the past, but the kind of tools
we have now are really incredibly powerful.
My starting point as a maker was in the 70s, my older brother purchased a TRS-80 model
3 and abandoned it, so it became mine.
And from that point, I basically learned basic by typing in programs at a bike magazine,
and so I was a touch typist by the time I was 10, because I was like this, trying to
get programs in faster.
And that terminal window was, for me, a portal into an entirely new universe, and I can't
really overstate how profound that was for me at the time as I learned to code, exploring
this whole new world that you could just sort of create on a fly in front of you, and like
you had to use your imagination a little more than you do today, you know, with 3D and all
the great stuff we have, and BR.
So imagination can be a powerful thing.
I've been giving away software since about the time that I learned to code.
Back then we called it shareware, and we used bulletin boards to get our creations out of
their nest at an incredibly slow rate, but they would make it around the world based
on the letters and even checks that I got from around the world at the time.
And unfortunately, I was like 12 when I did this, and I made up a company, and I put it
on the software title screen, and people sent me checks written out to that company.
They didn't exist, and I couldn't cash them.
So lesson learned.
Let's see, back to the point.
The difference in time now in history is that we are all makers to some extent, from I would
say the ridiculous to the profound, as I have here in a bullet point, and I would have said
that before, chat, GPT, mid-journey, and all the other kind of stuff that's out there today,
that just serves to underscore the point, right?
We can all be creators in a way that has really not been possible before.
I guess that's sort of a debate.
Let's see.
Did I miss a slide?
No, I didn't.
This is the first time I'm using this, and the first time I'm presenting in like five
years, so bear with me as I sort of like find my footing.
Okay.
I don't actually read the bullet points.
The things that I say are, these are just inspirational things.
The things that I say are just related to that.
Why are browsers called browsers?
We haven't called PCs word processors since the 80s, and it has to do with where they
came from.
I'm sure that there are a lot of people here who could better tell the story and the history
of browsers, how they came to be, and the motivations of the people behind them, but
I think it's safe to say that the early creators were focused on document hyperlinking, sharing
of knowledge, not progressive web apps, and the browser sandbox, which is where we are
today, many decades later.
The reason it took us so long to get here is because we did start off from a document-centric
view of the web, and that outside of mostly closed self-referential sites like Wikipedia,
I don't think that hyperlinking really is what it was envisioned to be.
Link rot is sort of the order of the day.
What has been far more successful is the evolution of the browser as an application platform.
Okay, so this brings us to sort of the inherent and natural tensions of today.
I've grown skeptical of the way that we distribute software, the software itself, pretty weary
of uninstalling, reinstalling, cleaning up and organizing.
Do you really know what's in the software that you're installing on your machine, what
it contains, and to what extent should you have to worry at all about this, right?
Containerization on the server side has not really delivered us from complexity, which
is totally a topic for another day, but since we are talking about containerization, it's
related.
Decades on, there's still really no cross-platform application development environment that works
really at cross-platforms.
I spent way too much time in the Java world, mostly enterprise, but even their take on
AWT and all the other things that came after that were pretty horrendous.
The toolkits that you can use now and try to get cross-platforms, it really don't work.
So the fact that, you know, mobile tablets, touch, new interfaces, uh, fully complicate
the ability to create applications that run in multiple different formats, and the cloud
has created more tensions around data privacy and questions of individual agency.
So hopefully, let's see if I actually address this in the next slide, this brings us to
progressive web apps.
I don't know if you know, or if you've heard of this term, you know, HTML5 and CSS, progressive
web apps are basically web pages that can be self-standing at the end of the day.
If you add a manifest and some service workers, they'll cache their own data, they can be
installed and run offline.
And so this is why, my background has been in high-performance computing, embedded systems,
but I've ended up on the other end of the spectrum building web-based applications.
And so there are a lot of people who will question the performance of JavaScript, JavaScript
in general, in the browser.
I hope to address all of that.
You know, my coding arc, as I said, started with basic, it went through C, TickleTK, Perl,
other scripting languages, embedded systems, Java for a couple of decades, uh, a D2, D2
tour through Verilog, um, doing FPGAs and some of these real-time systems for quantum
computers, actually, um, before landing on JavaScript, oddly, while doing a prototype
in sort of like the late, or around 2010.
Um, so over the years, I've spent way too much time struggling with cross-platform and
UI issues, um, and I think that open-source progressive web apps are really a solution
for a lot of these problems.
So, um, let's see, they are deemed trusted because they're running in the browser sandbox,
um, and I lost my place on that because I wrote way too many notes for this slide, and
so give me a second while to find where I was.
I'm going to skip this, and I'm going to spend more time on the demo.
You don't want to hear me talk about this much more.
I will say that Android and Chromium are friendlier platforms than iOS, um, Apple is not really
keen on progressive web apps because they compete with the App Store.
If you think about it, if you have really good progressive web apps that you can install
off a web page and run them offline and have access to all the modern web standards like
Web USB and Web Serial and, um, all these other things, you don't really need the App Store
and App Frameworks as much, and so they've done a pretty good job of trying to hobble,
uh, WebKit and enforce its use on iOS, you used to be able to run Chromium on iOS without
WebKit and you had all these things and they thought, like, no, for security reasons we
can't do that.
Well, um, not really a case, but it does serve the purpose of enforcing the sort of the App
Store hegemony.
Um, all right, so all the apps I'm going to be presenting today are single page progressive
web apps, installable, runable offline, fully open source, MIT license, it's been around
for quite a while in some cases.
I'm not sure if I'm going to spend a ton of time on this, just, this is the pros and
cons sort of as I see it.
For me, faster development time is the thing that I care the most about.
Um, it is basically a page load away from testing new code, which is a sub-second process,
uh, for the most part, as you'll see.
Um, I spent a year one day trying to add a small feature to an open source popular Python
package, and the, uh, the dev test restart process took three minutes, and I was like,
this is, this is insane.
Like, I basically modify code, I hit reload, and I'm testing it immediately.
Um, developer tools, especially Chromium are shockingly good, um, I'm just going to leave
it at that for right now.
All right, so before, this is setting up or teeing up the first application that I'm
going to show you.
Um, so I promise I'm almost to the demo.
Um, a lot of my early making was in CNC, solid modeling, electronics, robotics, and things
like that, autonomous vehicles, sorry.
Um, and then around 2012, I started getting heavily involved in 3D printing, and you'll
see a couple of my early projects here.
Slicers of the day were painfully slow, um, they produced output that was suboptimal for
the things that I was trying to make.
Um, and the strength that I wanted, and I was working on engineer materials, scaled sort
of like Lego-like things like this, and, um, I was like, I've been coding for a long time,
how hard could it be to write a better slicer, right?
I sort of like the genesis of why things like this is annoying me, how hard could it be to
make a better one?
Um, and so, you know, I started to build a prototype, and in a couple of weeks, I had
basically a slicer that did everything that I needed to do, which was good for me, and
that was 10 years ago, so you know you're never done with these things.
But just to give you an example, a single cube or block out of this with the slicers
of the time would take 20 minutes to make one of those cubes, and I was doing scaled
up large, large scale models.
My slicer would produce the same part, the output that would produce the same part in
11 minutes, and the part used less material and was more mechanically, was stronger, would
bear more load, and did a lot of things that I wanted, so I was like already success sort
of like two weeks in, again, this was 10 years ago.
Slicers have come a long way since then, and I'm not sure how much I want to get into that,
but again, let's see, I'm going to skip the next slide, wait, this, then this, I have this
dual screen setup, it's hard to know what's going on here because this is not totally
in sync with that.
One timeline of some of the tools I've been building since then, Kirimoto, which is a
multimodal application that runs in the browser, does FDM slicing for 3D printing, does CAM,
does laser, does MSLA, which is for resin printing, does drag knives, that's part of
laser, so basically it's an all-in-one maker tool for most of the things that you would
have commonly used in your maker space.
Because I was doing a lot of large scale printing, I ended up designing and building
my own printer for my printer farm, which is also open source, open design, I ended
up writing my own G-code center for that, and a whole bunch of other things.
And then around 2015, when non-shape came along, so my CAD program of preference was
SOLIDWORKS for 15 years, and those guys left and started on-shape, and just a little bit
back story there, SOLIDWORKS promised since the very first day they came out that they
would eventually have a Mac version of their software, and they didn't deliver on that
after 15 years, so the guys left, created on-shape, and now it runs on a Mac, in a browser, and
is better.
So they opened an app store, and I was like, this is perfect, I could integrate Kirimoto
into on-shape accessor APIs and have a connection between CAD and CAM in one thing.
And I did that, got accessor APIs and integrated it in 24 hours, and the next day they called
me and they're like, hey, that was awesome, we've never seen anybody integrate in less
than 30 days, do you think you want to do a CAM package?
And I was like, huh, 3D printing, CAM, additive, subtractive.
It's interesting, I did it for a long time, how hard could that be?
So I ended up adding CAM in 2016, again, had a prototype working in about two weeks, and
here we are six years later, and we're really just getting into the interesting stuff on
that package.
So this is the interface for different modes of Kirimoto.
This is the GitHub repository, and I'm going to jump into a demo of this.
Application is called Kirimoto.
Most people call it Kiri or KM when you're typing it out.
The back story on that is that when I was building this, I was building two applications
at the same time.
One was the slicer, and the other one was actually a modeling program.
I wanted to do CAD modeling in the browser, and again none of the other tools really existed
at that time.
This was 2012-ish, and I started to build a block modeler that was sort of a combination
of Minecraft and blocks that you could skin things and connect them, and you could create
blocks to create blocks.
So I called it Metamoto, but this ended up taking all of my time, and I never got a chance
to really finish that.
I ban in it.
But now I have the tools to actually maybe go back and finish that if I have time, which
is doubtful, it seems like.
Okay, the app flow, this is a really short and quick slide, all with different modes
have the same workflow.
Whether you're an FEM cam laser or MSLA, you basically have your arranging it on a workspace.
You're doing a slicing pass, and the slicing pass is the crude pass that basically just
says, I'm deconstructing geometry.
I'm creating the rough paths that I'm going to be following, but I'm not doing things
like path routing and other complex stuff.
That's the prepare step, which basically takes the raw slices and then does path routing.
And path routing in the 3D world for 3D printing and CNC and laser are all different, which
is why it's abstracted out.
And each of them has their own different views, and you can do different things in different
views based on that.
And then the last pass is basically exporting to your device target.
I'm going to export G code or an SVG or, in the case of MSLA printers, massively large
binaries for no reason.
Yeah, all right.
Let's see if there's something I missed here, didn't miss here.
All right, the code structure, again, this is all running in the browser, 100%, JavaScript
unless I say otherwise, and I will denote when that happens.
There is a little bit of WebAssembly in there, and I plan to add more WebAssembly in the future
as to accelerate things.
The major libraries that I'm using are 3JS for the 3D, Clipper for polygon offsetting,
and very recently I added Manifold for a 3D Boolean engine.
It's used in one small place, but in the future I probably want to use it in other places.
It's actually an incredible library.
Storage on the right, these different blue boxes are different workers, different thread
contexts, so you've got the UI context.
And then all the work is done in workers to keep the UI responsive while all the heavy
lifting is happening.
There's no lateral communication between the workers.
It's all hierarchical, top down.
There's a reason for that.
I don't know if I have enough time to actually really talk about it today, but denoted each
of the boxes or the languages that are being used, languages and or libraries.
All right, and I'll just hope to remember to show you all that stuff in the demo.
So I'm going to hop into the demo now, start with Kirimoto, show you different parts of
that integration with Onshape, and now I have to switch up the UI interface or rather the
this thing here.
I have to go to mirror display so you guys can see what's happening.
Great.
Now I have to go find my browser, let's just do it here.
All right, this is not good.
That's better.
I am running this live on the network here which is found to be spotty sometimes during
the day-to-day, sometimes it's great, sometimes it gets a little bit of trouble.
So right off the good space you can launch these applications directly.
Because it's running in the browser, actually hold on a second, I need to get my, because
I no longer have speaker notes, I'm going to use my phone.
That way hopefully I won't forget major important things to discuss.
All right, you can launch these things directly from here.
This allows you to launch any of the major modes or just hop right into the application
by clicking on it there.
And there you go.
The whole thing is loaded.
The footprint of this is under four megabytes compressed and usually loads in under a second
with a cold cache, maybe about two and a half seconds to load the entire application with
all the different modes and everything else that's in it.
So it's quite small in terms of footprint for the code.
More slicers, if you go to download and install them, are going to be in the two to 500 megabyte
range for the same, for the similar code size, for similar functionality.
And I'm going to bring up on the right-hand side really quickly just to show you what's
going on under the hood.
On the right-hand side, I don't know if you ever brought these up, you can look at the
different threads or thread contexts that are down here and the interface, you can turn
on and off threading, which will start and stop the workers on the right-hand side, which
sort of eludes the previous slide that I showed you.
So these are the distributed workers that will be doing all the heavy lifting sort of
behind the scenes.
And you can turn it on or off because some browsers, like Safari, don't allow you to
do nested workers, they have to only work in a flat space, it's just one of the most
of the web standards they refuse to support properly.
And so it'll still work that way, it's just going to be slower.
All right, typical slicer interfaces, the original interface for QerMoto was very much
like the slicers that you see today, Cura and Prusa and all that kind of stuff with
essentially a tree of a thousand parameters.
This interface is slightly more opinionated and cut down.
And so you'll see that you've got a lot fewer parameters for your model.
But that's not really a problem.
I would say that most parameters and most slicers are designed to help you deal with
crappy 3D printers.
And it makes sense because most 3D printers are crap, to be honest.
And they don't have good software or they don't have good hardware or they don't have
both.
So there's a lot of stuff that you can fix in software with a crappy 3D printer, even
if your firmware is junk.
And a lot of printers actually are capable of running better firmware than they are delivered
to you with.
And it's just beyond most users to change out the firmware for a custom one and tune
it the way it needs to be tuned.
And so a lot of that stuff gets pushed into the slicer.
And so the slicers will give you a thousand parameters, thousand parameters, 900 of those
work against each other.
And so slicer profiles become a religion where it's all about, oh, mine works perfectly,
tweak a few things, something breaks.
And so you're like, you can't correlate why this thing is breaking this other thing.
Because this whole project is just me, I'm forced to be basically really brutal about
what is in and what is out.
And I'm doing heuristics for 99% of the stuff that's out there.
Like, it's going to work for most cases.
And under the hood, in the engine, or all the parameters that would be in other slicers,
I'm just not exposing them to you.
Because I don't really believe that's helpful.
And again, if you run into a corner case where you just can't do the thing you want
to do with your favorite parameter, just go use the other slicer or commit some code.
Because this is open source, it's all on GitHub and has been for a long time.
Let's see, there is, before I actually get into really demoing this, I wanted to show
another thing.
Because this is running in the browser, this is used pretty widely in not just in 3D printing
but CAM and everything else in a lot of classrooms.
Because it is one of the only pieces of software that runs on Chromebooks, it doesn't have
to be installed.
You can basically run it in classroom, Google Classroom, and other places.
You can configure everything on the URL.
So you can create profiles and put a bookmark somewhere and somebody can click on it and
it'll open up the profile.
And it'll be pre-loaded with everything that the student needs for that class.
The device profiles, even loading up objects into your workspace.
So it's pretty easy to do that kind of stuff.
And the fact that you can basically export your workspace, open a private browsing tab,
import it.
You can use this as a way of getting your data around from browser to browser.
Or again, for testing and debugging.
People send me workspaces all the time, I open a private browsing tab, I import it,
I replicate whatever their problem is immediately, and I'm able to fix it right away.
So from this interface, usually it comes up like this.
You can click on the docs grid space, it'll take you to this page here where it shows
you everything about different ways you can do shared profiles, which I just alluded to,
GCO macros, and different ways to embed or otherwise use the API for this.
So to show you a quick, let's just open up something which is sort of like your basic
3D printing thing here, the Benchy.
If anybody's done any 3D printing here, in the slice mode, you go in here and you're
going to have the ability to look at different slices, ranges of slices like this.
And the reason that there are two different modes, most slicers will basically take you
right to the path-routed version of a sliced object.
The reason I put you in here first is because you might want to modify parameters for ranges.
So in this case, I could just say I'm going to turn off the infill for that bottom part,
and then I have a range here that shows me that I've done that here and I've overridden
the fill amount.
And if I reslice that and go look at this the bottom up, you'll see that there's no
infill down here, and then all of a sudden it switches to the normal view there, and
then you can go and look at the preview, and this will show you the path-routing, path-routing
in view involves also determining the speed at which those layers or portions of layers
are going to be printed, and you can turn things on and off like moves.
So you can look at the moves, I realize that aspect ratio is a little funky maybe here.
Typical stuff that you would see in a slicer, nothing really amazing there.
What is a little bit more interesting about Qimoto, and this isn't really specific to
3D printing, and I'll get to this more later, is you can go in and change the version on
the fly because I'm hosting the last 10 versions of the software, I'm working on the beta channel,
I'm pushing out software two to five times a week depending on how active development
is going with major releases about every four to six weeks.
And so if there's a bug in the current release, you can go just switch to the previous one,
your workspace will be preserved, and it will bring you back into the same workspace that
you were in before with all of your data and all of your everything.
All of the stuff is persisted live in the browser, so again everything is just like reload
the page, and you're back where you were before, screwed something up, reload the page.
So there are three ways to import and export files really quickly, you can just drag and
drop stuff into the browser.
There are different formats you can support, so like in this case I can just drag in this
file here which is something that some users really love to use as a benchmark because
it's got about a million polygons, and it slices pretty fast.
There are some users of the program who really helped me with performance because they care
a lot about it, and have benchmark carry against Cura and Prusa and a bunch of other kind of
stuff like that.
And million polygons slicing this thing at the end of the day is about as fast as Cura
was, at least last year, that was the last time we looked at this, fairly well-optimized.
And again, this is pure JavaScript, there's no WebAssembly or anything else happening here
under the covers.
What else was I going to show you here, I'm not sure how important that is, but anyway
the version switching is nice, and then there's a pluggable language, if anybody wants to
contribute languages, it's pretty easy to plug in a new language into the interface, and
again you just reload the page, and you've got another language with the same interface
that you had before.
And here we can go through, look through this, look through anything else.
So typical stuff there, interesting thing to note about this is that once you've sliced
this thing, we're now looking at about 25 or 30 million polygons in WebGL, and it's still
fairly responsive, I mean it's not as fast as I'd like it to be.
So future work is actually writing custom shaders, which I think would help with this.
This is not a case where you can basically de-res or hide stuff on the fly, because if
somebody goes in to look at the interior of this object, you can't just hide and then
show that thing.
There's always a possibility that interior features are going to be shown through the
shell, so you can't hide them.
There's no, everything that's in this, every path that's in this thing has to be shown
at all times.
And so this is an area where I would, if there were graphics experts, this is not my field,
would love to have some feedback on this at some point.
And then you can just export the code.
A nice thing about this is that Qmodo also has a gcode, and again I'm not sticking to
my script here, there's the things I want to talk about, but you can export the gcode
and then once you've done that, download the gcode.
You can also send directly to printers.
I have a spooling agent that allows you to print, to send directly from Qmodo in the
browser to Octoprint.
So if you like use Octoprint as a back end, there's a way to send directly from the browser
to your printer.
And that's fairly well documented, and I have other ways of doing that for some of my own
printers.
Download the gcode.
Qmodo also has a gcode renderer built in, so if you get some rando gcode and you want
to bring that in, you can actually bring in the gcode back in, oops, let's find the downloads
and bring that back in.
And it will re-render the gcode.
This works in all modes, so Qmodo will render gcode from CNC, laser, FDM.
And so I'll get into it in the CNC section, I'll show you that as well.
And then there's exporting and sharing of workspaces.
So for example, I go into a private browsing session.
And the internet's great, let's try it again, great, private browsing.
I can import something like a CNC job.
And it will switch modes, bring it in, tell me, give me a screenshot of when a workspace
was created, and then bring everything in with it.
So this is an example of the fourth-axis lathe work that's happening right now in the cam
mode.
This isn't fully baked yet, but it's the next thing that's coming out with the next release,
which is fourth-axis CNC was the thing I added in the last release, and this just sort of
gives you the ability to do some fun stuff like this.
But that's just showing you importing, exporting, and sharing of workspaces.
Cam mode, let's just hop into cam mode real fast, CNC mode.
So you'll notice when you change modes, your device list changes, and the platform changes.
It's adapting on the fly to whatever the new mode is that we're working on.
I got this new CNC mill, make our car vera, and it got rid of all my other mills because
it does everything that I need.
And so that actually leads to another project that I've been working on.
I'm going to bring in a workspace for that.
This workspace that somebody sent me, they're like, hey, I have a problem with some anomalous
cuts happening here.
So in CNC mode, you get a new bar at the bottom.
These are reorderable operations because CNC is a set of operations.
Each operation may or may not use a different end mill, and then you can hover over each
one and change the settings for those, and you can enable and disable them like that.
And I'm just going to go ahead and slice through this and give you an idea of what the slice
view looks like.
I can turn on and off the different operations to look at what they're doing, or I can go
through them like this.
But this doesn't involve the routing.
This is just, again, the pure slices.
We go to preview this.
It's going to show us the path routing that's a little aggressive on the hover.
But once you've done this, we can go to an animation mode.
And now this is the first time we're doing something actually pretty interesting, where
on the back end, there is a shared array buffer, which is a relatively new technology in the
web standards.
This shared array is like a shared memory, but having shared memory and JavaScript is
cool.
This is a new thing.
There's access to one shared pool of memory.
They're all rendering into it simultaneously.
And the front end 3JS engine is rendering the same buffer that's being rendered into
by the workers on the back end.
So I can go through and I can run this animation, and I can speed this animation up.
And so all of this is actually happening in real time by the workers on the back end.
And I got this workspace that says, I have this anomalous cut right here.
What's that all about?
Well, I'm not going to walk you through the great details, but they had one thing incorrectly
set in one of the settings.
I figured that out, sent it back to them with the correct settings, and they're off the,
you know, it wasn't a bug this time.
Oops.
It looks like, you know, that's fortunate.
My hand touched my phone.
All the notes disappeared.
It looked like I deleted them magically, but it didn't.
It just created a new note that was empty.
Okay.
So here, this is a fixed workspace.
Let's see.
Can we also do other sort of import, export?
It can import SPGs and extrude them.
It can import images and turn them into height maps.
So one of the common things people do with CNC is they'll do reliefs.
And so I can bring in a relief, like an image of a flower, and add some parameters to that,
and actually I want my stock to be offset, and then I want to resize this thing because
it's kind of too large.
So this is sort of a common use case.
People want to do reliefs.
Reliefs are a pretty, like I said, a pretty common thing.
This came from this image right here, which I grabbed off the internet this morning, but
just to show you that it will import things like that, and it will also import SPGs.
So if you have an SPG, this is more common with lettering.
If you want to do like lasering or CNC of lettering or things like that, you want to
bring in an SPG, and you've created another 2D program, and I can do that.
It'll bring it in.
That's too large.
I can delete pieces out of it and scale it because that's, again, too large.
So then just delete and add some new operations there.
This is actually a good segue into the laser mode.
This is actually really too large now, again.
Let me scale that guy down.
And in laser mode, you're creating, let's see, I don't want to use this.
I'm going to use a different cube.
I'll just show you this.
So by default, in the laser mode, when you slice, it basically looks at all the different
Z changes, and it will, if you say nothing for zero for the height, it will basically
find all the transition points, and it will create a slice at that point.
The assumption there is you're going to slice a thing into a stackable layer, and you're
going to basically do stacked, registered slices with a laser cutter.
You can do something a little more complex.
You can choose the slice height.
These are, but like lettering, the things I showed you before, we're basically going
to bring in a 2D thing usually, and then slice that and set like an offset.
Offset is a kerf for the laser, and that'll tell you how far the line is going to be set
off in the part, so that when you take into account the width of the laser, you get the
size of the part that you want.
It has some other interesting features, like a drag knife.
You can turn on drag knives.
Drag knives will do the radial cuts, so that you can basically, if you're cutting vinyl,
for example, it's very similar to laser cutting, but you're dragging a rolling surface, and
so 15 minutes, thank you, I'm rambling.
Drag knife support, I'm going to quickly just go through the last mode or two here, and
then show you a couple other things.
Resin printing, also known as usually MSLA, which is masked SLA, as opposed to actually
resin printing using a real laser, which is tracing something, 2Dbox owns that market.
I bought a couple of resin printers, and I used them before I figured this out, that
all of the file formats for resin printers are pretty much proprietary.
They all contain the same information, which is basically a stack of images, but because
2Dbox sells the hardware, they force everybody to sign NDAs and make everybody have a different
file format.
What's out there today is all reverse engineered.
I haven't put a lot of effort into MSLA since then, but it's really, really brutally simple.
It doesn't even have the problem of path routing, because you're really just doing layers.
You're slicing into layers, you're generating a bunch of bitmaps, you're encoding them into
a file, and you're throwing that at your resin printer.
The one thing that really doesn't make sense about this is that resin printers take so
long to cure each layer that a microcontroller could render and raster each next layer, and
it really should just be a stack of SVGs instead of 100 megabyte.
This would be like a 100 megabyte file going to a resin printer.
Should be 5K.
It makes no sense, and I'm done ranting on that for today.
The next way that you can access Kirimoto is through the engine.
There is an engine API and an engine example.
This is the pure API not associated with any UI or anything like that.
You can run it standalone, you can run it in a browser.
Here I'm actually going to just slice an object and generate out code in the browser.
This is just using the engine directly.
There's one more API which is actually used by, so the engine API and the frame API are
used by a couple of different projects, even a commercial product.
This is an API driving a frame.
You can embed Kirimoto in a frame, in your site, and drive it through an API.
This is automatically the API interaction.
You can skin it, you can remove any UI elements you're not happy with, you can use a 3D part
of it, so you can basically create your own engine for this, your own wrapper for this,
and put it anywhere you want.
That's just another sort of interesting way to access the interface.
I'm going to show you the integration into Onshape if we've never used it before, browser
based CAD, love it, can't send up nice things about it, it's not open source though, obviously.
Go in, open a model, in this case I actually did a YouTube video demoing this, creating
a CNC job to mill a guitar neck, so you go into Onshape, this is the model in Onshape.
Kirimoto is a tab over here, you basically just say add Kirimoto, it shows up here,
it's in the app store, and then inside of Onshape, because you can see I'm iframed right here,
I bring in the guitar neck, and it imports into my workspace, and I can start to go into
CAD mode, and start adding operations to mill this thing, export the gcode, all in the same
interface.
If I update the model over here, I can come over here and refresh the model in place.
So if I have things that are referenced in the model, and I'm doing some milling stuff,
and I've changed the model, I can basically just re-update it in this tab.
So that's really the beauty of having this integration done in the browser through their
APIs.
It's the only case where this isn't a fully standalone application.
I have to have APIs on the server that talk to their APIs using Elwalth and a bunch of
other stuff.
So I'll leave it at that, since we're running out of time, the last two things that I want
to show you are, if I go back to grid space, mesh tool, in the slicer world you get a lot
of crap models from Thingiverse and other places like that, non-manifold objects.
And I kept adding more and more features into Qerimoto to manage those problems and try
to heal those objects and clean them up.
And eventually I'm like, I don't want to crowd the interface in Qerimoto with a bunch
of stuff that really I used to use Blender for.
And so I created my own tool for that.
This was beginning of last year, I think, ending of last year.
You can come in here and you can bring in any, so one of the things people do commonly
with, oh, I didn't even show you the belt printing.
So I will say that one of the things that Qerimoto did before most other slicers was
add belt printing.
So if you're not familiar with belt printers, one of the reasons I'm going to show you that
is that belt printers are, you would think very similar to bottoms up 3D printing.
They're not.
They're completely different.
They're similar in some ways, but basically if you think about it, every layer has a first
layer problem.
At 45 degrees, every layer has a first layer problem.
And you have to deal with the fact that your bed is not rigid.
It doesn't like a lot of materials, and you have a really hard time enclosing that thing.
Having said that, if you can get your print job to work on a belt printer, it's phenomenal
for lots of things.
Why do you like to print swords?
The problem with swords is they don't lay flat on the belt.
So one of the things you can do in this tool is you can go in and split a sword.
And there I have half a sword.
Now the problem with that is that it is not manifold.
It is open.
So in here I can go to a pair, patch.
I now have a sword which I can flip over, put on a belt printer and print it, which is something
that people do pretty commonly.
I'm not going to spend a lot more time in this tool other than it's something that
I would love to improve over time and add a lot more features into over time.
I think it's a tool that we should have running in the browser.
There are some other things that are similar out there, but again, there's no cloud involvement
for any of these programs.
They're all completely standalone running the browser.
And the very last thing, which I will show, because we're totally out of time now, is
card control, which is a sender.
I can't actually show you this because I have not connected via serial to a CNC mill, but
this runs in the browser, uses web serial to talk to your device directly, locally it
can talk.
It's abstracted so that you can talk over USB serial or you can talk over the network
to the device.
But what's really cool about this is that if you get a mill and you go to your first
time set up and you plug it into your laptop, you can click the serial button right here,
it will find your mill, you will connect to it and start controlling it immediately when
the browser without having to install any software.
What led me here was when I got the mill and tried to install their software, it didn't
work on any of my computers.
It didn't work on Windows, it didn't work on Android, it didn't work on Mac.
Now they fixed most of these problems, but again, it was like the software's not complex.
I've written senders before.
How hard could it be?
So the cool thing about this software is actually that it shows you, uses 3JS, will render and
show live in 3D what the mill is doing, so it's tracking in real time the G code against
what's happening on the mill.
All right, go to good space, you'll find links to the forums, docs, discord, all that kind
of crap and now I can take questions.
If anyone has questions, send over the microphone, yes, on that side, yeah.
Hey guys, the room is full of makers.
I, oh yes, yes, I found one.
Hey, thanks for the talk.
What are the techniques you're using for the workpiece simulation that you demoed in the
CNC workspace?
What's, what, the question is what, what, it looked like maybe you're using just a height
map?
Oh, for that, for that, yes, modeling this, correct.
In the three axis CNC mode, it's rendering a height map because you can't do undercuts
or side cuts or anything like that.
In four axis mode, it doesn't use a height map.
That's way harder to deal with.
That's actually the only place I'm using manifold currently, and so it actually does 3D subtraction
in real time of the tool geometry against the geometry.
It's far more computationally intensive, but yeah, and I didn't have time to show that.
Is manifold like robust mesh booleans?
It is, so it's, it's a relatively new project, it's really exciting, written in C++, compiled
into Wasm, and then loaded in as a library to run in each of the workers.
Again, it's web assembly, so it's pretty fast, but it is a proper, it is a proper like manifold
library for doing booleans.
And I did contribute to that project because their initial API was too slow for what I
was doing.
They weren't producing arrays properly.
I rewrote their JavaScript API for import, export of those and made it like 200 times
faster, so that got accepted recently.
Another question?
Hiya.
Thanks for the talk.
I found it really interesting.
I was wondering, I might have missed it, but I don't think you mentioned where you used
WebAssembly in the product, and I was looking at the, WebAssembly, Wasm, and I was curious
because looking at the slicer algorithms for FDM, they must be pretty computationally
intensive, so how do you get that to work fast enough in the browser to be usable?
So none of the slicing that you saw, none of the cam stuff, none of that used WebAssembly.
Nothing that you saw today used WebAssembly.
That's all pure JavaScript, which I know is probably upsetting for people.
Funniness.
Yeah, I'm surprised it's fast enough.
It's impressive.
So part of it is I did spend decades doing high performance computing, and I'm a bit
of a performance nut, you know?
So why would I use JavaScript?
I mean, I did my prototype in JavaScript, and I'm like, this is just too easy, right?
I started, like I said, it was like more than 10 years ago, and I was like, it worked.
And my intention was to rewrite it in a real language, because I spent most of my life
writing in real languages, and now I spend all of my time writing in JavaScript with
a little bit of WebAssembly and some other things like that, and totally hooked on it.
You can totally do some pretty amazing things in JavaScript if you decide you want to.
Cool.
Thank you.
All right.
Hello?
Yes.
We can see.
Hello?
Do you want me to draw with you?
Can you handle it?
One you can.
please.
come.
I am open.
Please.
Come in the ce subtle.
What is it?
Welcome.
The last thing you enter out.
You are the first one to do this?
All right.
Welcome.
I had another talk and I also had a talk with you.
So just, yeah, that's right.