search

curv3d / curv

a language for making art using mathematics
Apache License 2.0
1.14k stars 73 forks source link

Export to gcode #22

Closed galex-713 closed 5 years ago

galex-713 commented 6 years ago

As far as I remember, especially for (reprap/free-software only?) 3D printers, there are two formats: the stl format contain the 3d structure (mesh afaik?) and is displayable, and then (inside or before) the 3D printer, stl is converted to gcode, which control the printer head movement and filament deposition.

Due to gcode working being a lot more voxelish than stl, I guess it wouldn’t be too difficult converting curv to gcode, with less precision limitations than stl, possibly controling color or other parameters in a more portable, adaptative or parametric way?

Has this already been discussed? proposed? thought? I’d like to know more

doug-moen commented 6 years ago

Generating gcode is a big job. It's not just slicing the model into layers (which is easy using a volume representation like Curv). It's also motion planning, infill generation, support generation, filament retraction, temperature control for the bed and the extruder, multi-extruder support, multi-colour support and so on. Different gcode is required for each brand/model of 3D printer, and for each type of filament.

I've thought about this. However, I think it makes more sense to do this in the context of an existing open source slicer project. It takes a big community to support a slicer. For example, I thought about making a Curv plugin for Cura.

Multiple people have suggested this direction. I don't personally have time to investigate this deeply: I'm too focused on improvements to the language and the geometry engine for the next year. But this is a green field opportunity for someone else who wants a project.

doug-moen commented 6 years ago

As an alternative, I've been thinking about exporting 3D models to voxel format, and adding voxel support to existing open source slicers. I think this is easier. It's also a more flexible and powerful approach. It addresses the problem of how to get the benefits of voxels when you don't have physical access to the 3D printer, when you are using a service bureau instead. It's easier to support for reading voxel files into a service bureau, than it is to get support for reading Curv files into a service bureau, I would think.

It looks like the 3MF file format will be getting voxel support. They are actively discussing it, anyway. Once 3MF has voxels, I think that's the time to act on this idea.

galex-713 commented 6 years ago

G-code can be the same for a wide area of products, for instance I guess the g-code format for free software implementations on RepRaps are all the same: http://reprap.org/wiki/G-code Wouldn’t it be possible maybe to modify some free software already existing just to add that voxel support, while M3F or some other standard open format isn’t ready yet? would a cura plugin as you said be a such thing?

doug-moen commented 6 years ago

I have a design for my own set of voxel file formats, as a stand in until something more standard comes along. This will help me to make progress on voxel support in Curv.

It would be possible to modify an open source slicer to import these same voxel formats. If it can be shown that you can print models using voxels that can't be printed using triangle meshes, then that would be a really powerful result that could help drive the adoption of voxels by the open source 3D printing community. No need to wait for big industry to adopt voxels first. The current 3D printing boom only happened because of the open source/open hardware community. We provided the innovation, then industry followed. It could be the same with voxels.

doug-moen commented 5 years ago

I have no plans to implement gcode export, so I'm closing the issue.