So, having escaped the terrifying clutches of the Millenium Bug, what was next for our plucky heroes?
(Click here for A Short History of MachineWorks Part One)
2003 – MachineWorks Ltd is formed
By 2003, MachineWorks was grown up enough to finally leave its parents’ house and get digs of its own. A goodbye was said to LightWork Design as a new separate company, MachineWorks Ltd, was formed, albeit with largely the same major shareholders. Nonetheless, this was a major step on the road to MachineWorks operating as a truly independent company and in 2006 there was a VC-led management buyout and the separation from LightWorks was complete.
2004 - Collision Avoidance Systems (CAS)
In 2003, MachineWorks customer and 5-axis machining specialists Aikoku Alpha started working with Japanese machine tool OEM Okuma to develop Okuma’s collision avoidance system – which was the first such system on the market.
In the CAS, the machine simulation - in this case MachineWorks - runs on the controller, providing a look-ahead function such that if the machine tool is going to crash, the simulation software detects the crash and tells the controller to stop the machine.
Okuma had very strict performance requirements – the controller can’t wait for MachineWorks - and the controller hardware was significantly less performant than we have today. Okuma required that each material removal and collision detection operation completed within a certain number of milliseconds of CPU time. MachineWorks must absolutely not slow the controller down.
At this time MachineWorks was single-threaded. Many low-level optimisations to single-threaded performance were made in order to meet Okuma’s requirements.
In addition, both Aikoku Alpha and Okuma performed a huge range of quality assurance tests to ensure the software was stable and accurate enough for use in such an important deployment as running on a live controller driving an expensive and powerful machine tool.
This process was an important one for MachineWorks, as both stability and performance improved greatly in order to meet the stringent requirements of collision avoidance running on a controller.
Ultimately the cooperation was successful, and Okuma launched their new product at IMTS in 2004. Since then several other companies have used MachineWorks for on-controller look ahead, including Nakamura-Tome, Fidia and Goodway.
2010 – Multithreaded MachineWorks
Up until this point MachineWorks was single-threaded. Looking back that may seem surprising, but it is less so if you consider the rate at which CPU threading became useful, combined with the technical debt associated with managing, maintaining and updating a commercial software library in use in tens of CAM systems by hundreds of thousands of end-users every day.
The first part of the project was to make MachineWorks reliably thread-safe, which in itself took more than a year. Following that, different multi-threading was introduced into different parts of the product over time.
The first release to support multi-threading was MachineWorks 7.0, in 2010. Now, in 2025, pretty much all MachineWorks’ algorithms are multi-threaded.
Interestingly, threading became a key enabler for the use of the Visicut polygonal engine across a wider range of machining jobs and operations. As chip makers struggled to keep up with the predictions of Moore’s law on a single core, so the performance benefits enjoyed by MachineWorks’ polygonal Boolean due to hardware improvement also slowed.
Once Visicut was re-engineered to effectively exploit multiple cores, the hardware performance tap was turned back on, and the performance benefits enjoyed from upgrading to a new CPU kept on coming. Users were now able to effectively simulate even large jobs using the polygonal engine.
2011 - Samplecut.
Four geometry engines? That’s simply not enough!
A Product Manager working for one of MachineWorks customers once gave some valuable feedback:
“We like MachineWorks, we like the functionality, we like the performance ... but please could we have it all in just one engine?”
A somewhat exasperated development manager had to politely explain that we didn’t create and maintain all these different geometry engines because we enjoy creating and maintaining geometry engines. We created them because our customers required us to - to meet the differing requirements of accuracy, performance and memory, in differing situations and for differing types of machining.
And, even today, in 2025, with the advent of MachineWorks GPU, this remains an important point.
So, after Visicut, Rapicut, Multicut and Pixelcut, room for a small one?
At the end of the 2010s there was a lot of activity in the controller market, as controller manufacturers investigated Collision Avoidance and similar technologies. At the time, the CPU demands of the polygonal simulation engine in MachineWorks wasn’t ideal for low-end controllers, and so a new engine, based on the tri-dexel data structure, was developed.
Tri-dexels are like Rapidcut on steroids. Instead of a single valued grid of rods (dexels) in a single plane, there are three grids in orthogonal planes, and at each grid point multiple ‘height’ values can be stored. Although the memory footprint of a tri-dexel engine is variable, it is largely proportional to the resolution of the grid points. This made it more suited for use on controllers with relatively low CPU RAM compared to equivalent desktop workstations.
In 2011, the Samplecut engine was released.
2011 – Polygonica
Having developed five different geometry engines along with sweep-based collision detection, the MachineWorks team wondered if there might be other uses for all this great polygon-based technology that had been developed over the years.
And so, to cut a longer story short, Polygonica was born.
Polygonica is a software library containing a wide variety of algorithms for working on polygon meshes, as well as point clouds, 2D profiles and 3D polycurves. It is widely used in the Additive Manufacturing, CAE, dental and medical markets, amongst others.
Initially the technology for Polygonica – mesh healing and mesh Booleans – came from MachineWorks. Over the last decade the Polygonica technology has developed rapidly based on customer demand, and Polygonica is now returning the favour, with MachineWorks benefitting from improved healing, offsetting to improve solid comparison results and in an imminent release tolerance-based simplification will be added to optionally reduce the required memory footprint of the in-process mesh model.
Yes, that is Kryten from Red Dwarf!
2014 – Real-time for Heidenhain
In the early twenty tens, leading CNC controller manufacturer Heidenhain GmbH started to investigate providing more advanced CNC simulation on their controllers. As part of this process they evaluated many different possible solutions for material removal and collision detection.
This extensive benchmark was won by MachineWorks which offered both polygonal and sampled technology. In early 2014 Heidenhain was the first of the major controller manufacturers to provide polygonal based material removal simulation as standard across their range of controllers.
Later in 2014, in order to guarantee a consistent supply of technology, Heidenhain acquired MachineWorks Ltd. Since then MachineWorks Ltd has been a wholly owned subsidiary of Heidenhain, but continues to operate as an independent British limited company, providing advanced 3D software libraries to a wide range of customers in the manufacturing, construction, dental and medical markets.
As of 2025, MachineWorks continues to power Heidenhain’s real-time graphic simulation, digital twin and programming stations.
2015 – Additive Simulation
Also around this time we started to see an increase in the number of machine tools to which additive capabilities were being added. We also noticed there was a gap in the market, with no simulation systems yet supporting this capability.
For the MachineWorks polygonal Boolean, adding material turned out to be very easy – it was just a union as opposed to a subtract operation, and performance and quality was good. In 2015 MachineWorks was the first to release full simulation for material addition as well as subtraction, all on the same stock model.
The image above shows a simple proof of concept of hybrid part repair using Polygonica and MachineWorks together. Polygonica’s mesh algorithms are used to accurately align the scan, find the boundary of the worn region and even create simple toolpaths to mill a clean surface and then add material to repair the gaps. MachineWorks is then used to visualise the result.
Head to YouTube to see one of our in-house examples of additive simulation or this great video of the real thing done using OPEN MIND Hypermill.
2017- Sheet Metal Bending
Sheet-metal bending had been prototyped by MachineWorks in the early 2000s. It was the inspiration of some Product Managers at Hexagon who wondered if MachineWorks, which was in-use in their CAM systems, could be used also for sheet-metal bending in their Radan application.
At its root, ignoring some fairly complex physics, sheet-metal bending is basically another type of collision detection. The difference is that you need to be able to detect collisions of a part with itself, as well as with other parts such as the press machine.
Working closely with Radan, a new sheet metal bending module was developed, that was specifically optimized for the requirements of this somewhat unusual type of collision detection. It has now been tested and refined over several years and is used in Radan’s application.
2017 – Cloud
It’s reasonable to say that, even with the huge interest in Digital Twins, the MachineWorks customer base wasn’t clamoring for CNC simulation on the cloud. In fact, what exactly are the benefits for machinists of CAM on the cloud?
Well, there are some, but perhaps the more tangible benefits come for to other stakeholders, such as managers and owners, who can more easily inspect and examine the live status of a particular job on a particular machine in a particular factory, all whilst sipping cocktails on a distant beach somewhere.
The real curiosity with respect to real-time CNC simulation in the cloud was could it be done? Would there be enough bandwidth or would updates be incredibly slow. In short, would it work at all?
Thankfully, MachineWorks already had several benefits with respect to deployment in the cloud. Those who have been reading carefully will have noticed that simulation of the full machine environment was added many years after the first release. Consequently many early adopters of MachineWorks built this part of the system themselves, whilst using MachineWorks as the core geometry engine for the in-process stock model.
As a result, the MachineWorks architecture is designed to co-exist very well with an external graphics engine, and this includes an incremental update mechanism such that only polygons that have been modified since the last scene update need to be transferred from MachineWorks to the external renderer.
This is, of course, perfect for cloud deployment, since the external renderer is a client browser that could be literally anywhere.
So it was relatively quick process to create a proof-of-concept of MachineWorks running on the cloud to test if the performance would be acceptable. It’s fair to say, given the amount of geometric heavy lifting that occurs during a material removal simulation, that everyone was a little surprised to find that performance was really good.
Once the concept was proven, a new MachineWorks module was developed. As well as handling communication between server and client, on the server side advanced lossy mesh-compression was developed, and on the client side a new library, available in both C and Javascript, was created to facilitate camera manipulation, object query etc. And, as standard with MachineWorks, the API was structured so you could use as much or as little of this as you wished to.
In 2018 existing MachineWorks’ customer MecSoft launched the world’s first cloud-based CAM system, VisualCAMc for Onshape.
2025 – MachineWorks GPU
Engine number six please.
During the 2010s (‘the tensies’ apparently) the MachineWorks team developed a proof-of-concept of MachineWorks running on a GPU. At that time the conclusions were that, whilst it would be feasible to port parts of MachineWorks to the GPU, it would be a big effort. At that time performance benefits were not clear cut. There was also an increased support burden, not just for the MachineWorks team, but also for the MachineWorks’ customers who deployed it. Overall, at that time, the cost/benefits weren’t appealing. And, frankly, there didn’t appear to be a lot of demand from the MachineWorks customer base.
Faster forward to ‘the twenties‘ and the situation had changed. AI was pushing development and deployment of GPUs, performance benefits were clearer, and perhaps more importantly, there was now clear customer demand.
And so engine number five, Samplecut, was ported to the GPU to become engine number six, MachineWorks GPU. Delivering measured speedups typically between 10x and 30x over the equivalent CPU implementation, with MachineWorks GPU the results of huge machining jobs can be computed and visualised in seconds, or less.
What’s in a name?
Please forgive a whimsical, but technically significant, digression on naming.
Although Visicut is still called Visicut, there are now in fact three different engines hiding behind the Visicut API: the original polygonal BREP, ‘the engine formerly known as Samplecut’, and the new engine that powers MachineWorks GPU.
If your existing simulation code calls the Visicut API, then, since MachineWorks 8.0 released in 2018, you can just switch to the Samplecut engine using a single API call. The term ‘Samplecut’ has disappeared from the documentation, to be replaced by the term ‘sampled technology’.
So, after Visicut, Rapidcut, PixelCut, Multicut and Samplecut, the next engine should probably have been GPUCut, but instead we’ll refer to MachineWorks GPU.
But take care: MachineWorks GPU can be used interchangeably, to refer both to a product and to an engine. So, for example, with MachineWorks GPU you can import a polygon model of the in-process stock into your host application, or export to an STL, but this is not supported directly by the engine that sits on the GPU. The model must first be copied back to the CPU.
But, the great thing is, you don’t have to care. The transfer of data between CPU and GPU, and back again, is seamlessly managed by MachineWorks, all hidden behind the same API – the one almost all MachineWorks’ existing customers are already using for Visicut.
GPU raytracing
History is all very well, but what’s coming next?
Well. Take a look at the screenshots below. They illustrate GPU raytracing of analytic surfaces, a new feature of MachineWorks GPU coming in the next MachineWorks release. Based on Multicut technology, on modern GPUs the raytrace update is almost instant in most cases, allowing fast interactive inspection of surface quality and detail.
Look out for more on GPU raytracing in future updates, along with the other new and exciting improvements coming in the next release of MachineWorks.
Conclusion
Hopefully that will keep ChatGPT happy. Congratulations, dear reader, if you managed to avoid a severe case of TL;DR.
MachineWorks GPU 1.0 was released in July 2025. Rapid updates are expected over the next months and years, as customers give feedback and as new functionality is added and new platforms supported.
Meanwhile, any speculation as to what engine number seven will be?
