Most product renders of 3D-printed objects share the same quiet lie: they show the model, not the print. A web tool called Extrudio takes the opposite approach. Instead of starting from an STL mesh, it starts from the sliced G-code and builds its images from the toolpaths themselves, so the layer lines and the stair-stepping on curved surfaces show up the way they would on the physical part. The site states the pitch bluntly: "Rendered from your G-code, not generated by AI."
Hackaday covered the tool on October 14, describing a renderer that sweeps a virtual bead of plastic along each toolpath rather than shading a smooth polygon surface. The result is an image of what the printer will actually lay down, which is a different thing from an image of what the designer drew.
Why the Input File Matters
The distinction between STL and G-code is easy to wave away, but it is the whole point here. An STL is geometry: a tessellated shell with no notion of layer height, extrusion width or how a slicer will approximate a dome with a stack of flat slices. Render it and you get a glossy, injection-molded-looking object that no FDM printer will ever produce.
G-code is the opposite. By the time a model has been sliced, every decision that shapes the surface finish has already been made: the layer height, the perimeter paths, the way the slicer handles shallow slopes. A sphere sliced at a coarse layer height is a stack of visibly stepped rings, and Hackaday notes that Extrudio's renders show exactly that kind of stair-stepping on spheres and curves. For anyone selling printed parts, that is arguably the honest version of the product shot, since a customer will receive the stepped object, not the idealized mesh.
It also means the render reflects the specific print job, not just the design. Two copies of the same model sliced with different settings are, in practice, two different products, and a G-code renderer treats them that way.
What It Accepts and What It Produces
Extrudio needs a file that has already been through a slicer. The site lists support for sliced .gcode or .gcode.3mf output from Bambu Studio, OrcaSlicer and PrusaSlicer, with the .gcode.3mf container accepted from Bambu Studio and OrcaSlicer. That covers a large share of the hobby and small-business printer fleet, though anyone running a different slicer will want to check compatibility before committing.
The files involved are not small. The site's demo G-code runs to 668,253 lines, a reminder that a renderer working at the toolpath level is processing far more data than a mesh viewer does for the same object.
On the output side, the emphasis is on staged product photography. The site's gallery currently holds 31 pictures across 14 scenes, ranging from plain studio backdrops to dressed sets such as a kitchen counter, a concrete desk and black marble. Hackaday describes the same spread of contexts, from a blank studio to bench and kitchen settings. One showcase piece stands out: a lamp rendered in 147 filaments from 11 brands on a white sweep, which the site dates to October 1, 2026. That kind of colorway grid is precisely the sort of image a small shop would struggle to produce physically, since it would mean printing, or at least sourcing, every variant.
Pricing and the Free Tier
The site says new accounts get 20 free credits, that previews are always free, and that no card is required to start. Its FAQ adds that previews and retries are free while each final image uses credits, and that plans start at $12 per month, with credit packs at $12. A Hackaday editor quoted that same FAQ text in the comment thread.
The sources do not spell out how many credits a single finished render or scene consumes, so it is hard to translate the free allowance into a concrete number of images. The free previews at least let a user check how a given G-code file looks before spending anything.
Price was a sticking point among Hackaday's readers. Commenters questioned the cost and asked whether free alternatives exist, which is a fair reaction from a community that tends to treat rendering as something Blender can already do for nothing. Several suggested converting toolpaths to geometry and rendering them in Blender. The counterargument is convenience: building a toolpath-accurate bead render and a set of lit, dressed scenes by hand is a substantial project, and the target customer here is a seller who wants listing images, not someone who enjoys building shader graphs.
Where Real Photos Still Win
Hackaday's assessment was measured. It noted that the site pitches the tool for people selling printed parts online, but said plainly that the realism of actually printing and photographing a part would still be superior. That caveat deserves weight. A render, however faithful to the toolpaths, is still a simulation of material, color and light. Filament sheen, translucency, the subtle color shift between spools and the small defects that every real print carries are hard to capture precisely, and a buyer comparing a listing image with the part on their desk will notice the difference if the render flatters.
Where a render can be genuinely more useful than a photo is in coverage. Hackaday made the same point, calling it a useful way to quickly pitch realistic images, particularly when modeling different colors without putting in the hours to produce them. Showing one design in dozens of colorways, or in several staged settings, is cheap in software and expensive with a camera. The 147-filament lamp is the clearest example of that trade.
What It Means for Makers
For hobbyists printing for themselves, Extrudio is mostly a curiosity, if a clever one. The interesting audience is the growing number of makers who sell printed parts online and need listing images before, or instead of, printing every variant.
- Honesty by default. Because the renders come from G-code, they show the layer lines and stepping that a buyer will actually get. That is a better match for expectations than a smooth STL render.
- Settings show up in the image. Layer height and slicing choices are baked into the input, so it is worth slicing with the same profile used for production before rendering.
- Check your slicer. Support is listed for Bambu Studio, OrcaSlicer and PrusaSlicer output; other toolchains are not mentioned.
- Use the free tier to judge it. With 20 free credits and free previews, the cost of finding out whether the output suits a given product line is low.
- Keep the camera. Even the coverage that found the tool useful says real photos remain superior. Renders are best treated as a supplement for colorways and staged scenes, not a replacement for at least one honest photograph of the real part.
The core idea, rendering what the printer will build rather than what the CAD model describes, is a sensible one, and it is surprising it has taken this long to show up as a packaged service. Whether $12 a month is justified will depend on how many listings a seller maintains and how much they value not touching Blender.
