Suggestion: Improved gcode generation

[wijnen]

I have two suggestions to generate better gcode:

Use a modularized approach, like skeinforge does. There are several things to do, each of which can be implemented by one or more modules:

1. read stl (or other format) file into triangles.
2. convert triangles to slices with polygons
3. convert polygons to areas (either "shell" or "inside"; best would be to have shell on top and bottom of a region as well).
4. convert areas to polygons (head movement)
5. convert polygons to gcode

For any conversion, there must be exactly one option selected. Between conversions, there must be a defined format which can be modified by filters. Between conversions any number of filters may be added. For example, a towering filter could be added just before converting to gcode; it would reshuffle the polygons.

Because building this, and in particular implementing all the filters, will take long, and because skeinforge is very good: allow external gcode generators to be called from the gui instead of the internal one.

I think the start of step 1 is not so hard. Just split stl.cpp into several modules. Everything is already in there. All intermediate storage types must be defined. This is important, because filters will work on them. It's not very hard, but it must be done well.

If anyone dislikes this approach, please speak up; I don't like to spend time on things which aren't used. :-)

[hurzl]

I dislike skeinforge not only because it is slow but because the code and the interface are both a terrible mess. I think it is overcomplicated in the attempt to handle hardware (printer) defects.

I think the user should select features of the print and not select modules he has to configure separately. Internally a modularization would probably help but I am not even sure of this.

It is helpful to serialize the process as you do in your steps, but I would rather have options in these steps (internally) and not have of a bunch of modulues handling a single step one after another.

So I vote for serialization, but not modularization.

[hurzl]

There should be two levels of options:

1. that I can change from print to print (layer height, fill ratio)
2. that are "good for my printer and material" as layer thickness to width ratio etc. - set once and forget. These parameters have to be independent of the primary options (layer size and such, which is probably the main problem of skeinforge)

[wijnen]

I think I have the same problems as you with skeinforge. It's very slow, but I can live with that. However, the fact that I still don't manage to generate usable gcode for my printer with it, after several days trying, is a serious problem. I think this is because of the extremely complex interface, which doesn't try to split configuration and state (which is what you correctly suggest). It really should. Also, the interface sorts all modules alphabetically, while it really should hide all unused things and show the rest in the order it uses them.

Anyway, I'm not in favour of using the skeinforge code. Not at all. ;-) So let's not worry about its bugs.

I think for the conversions, not having choice which converter to use is fine. They can indeed be controlled with some options and that's all. However, I think making it easy to plug in filters has added value. It means there's a clear separation of tasks.

Note that I'm not saying any of this needs to be in separate programs. I like to have the available filters in lists in memory, and the build will call them (if enabled). Writing a new filter means implementing a new class and registering by adding pointers to those lists.

So the word "module" was probably misleading. I'm not in favour of modules which can be built separately and used without recompiling repsnapper. I would like to have a gui widget which shows all filters though, with the option to switch them on or off, and possibly configure them.

[mmeeks]

Hi Bas,

I like your idea; and it'd be good to improve the code

structure around gcode conversion.

It'd be nice to get the fast vs. Logick shrinkers sorted out

as well. The way we tie everything together into one ball of baler twine - from slicing through rendering is really unhelpful.

If your modularised approach works well, please go for it &

push patches preferably in reviewable increments as you; if something goes the wrong way, we can back it out later of course ;-)

Personally I'd suggest that we create a module flow based on

skeinforges' since that seems to work well - but not change our UI in any way that makes it closer to the abomination that is skeinforge ;-)

Finally - another advantage of better modularity may be

threading. If we can clean eg. the slicing code to return a well defined state that can be message-passed cleanly and as a whole to another thread - then we could easiy have slicing be done in another thread (ditto - if the data structures are designed to be self-contained messages) for the other phases. Even my atom netbook has two cores, and would get a nice / linear speedup for that.

All the best,

    Michael.

[mmeeks]

urk - that came out badly, ignore the bits with tabs before lines- comes of loosing the first chunk of comment to the browser, then writing in emacs and pasting ;-)

[hurzl]

In any case I think it is a good idea to break up stl.cpp, there are so many different things in it

[wijnen]

I've just committed a start to my branch. It's a split of stl.cpp into slicer/*.cpp. It doesn't do anything special yet, but it makes it possible to more easily hack on one item.

If you like it, please merge it into master.

[mmeeks]

Thanks for that - I was wondering why you were doing it on a branch :-) Anyhow - I cherry picked and manually pushed the commits (with your authorship) - to avoid further complicating the history of master ;-) hope that's ok. Also - it seems you did a German translation [ which is sexy :-] - but perhaps forgot to git add the po/de_DE - it'd be just great to have that.

Nice work !

[mmeeks]

and close.

[wijnen]

I'm happy to work directly on master, I just followed your (IIRC) advise (in another issue report) to do everything non-trivial on a separate branch.

I didn't do a German translation. I was sort of planning to do a Dutch translation, but didn't even start it so far. No idea where the German came from.