suggestion: 4- or 5-axis printing

Consider 4- and 5-axis mills that support rotation of the workpiece around X and/or Y. If we did something like that for an FDM printer, it means you could have filament paths that are fully supported but not planar, i.e. you can construct an object out of arbitrary paths. This would have a number of advantages:
- some dramatic overhangs are no longer overhangs at all; you can build arms out radially from a core
- aliasing issues seen on sharp external edges (eg visor on Marvin keychain) go away because perimeter extrusions can happen at any angle
- filament paths can be optimised for more tensile strength in Z

The drawback to trivially converting a bridge to a column is that it weakens, but the "slicer"/CAM could avoid that problem by weaving layers at different angles, or by building shorter (and weak) support buttresses instead of full-height towers, then laying on filament in the bridge in the bridge's primary axis.

I do realise that generating the G-code for this is really really hard. I don't expect to see it happen in the reprap world in the next 5 years but if/when it does, it would be a quantum step up in print quality without the expense of SLS or mess of resin. Printer build cost might go up by 50% to add 2 rotation axes to the bed.

Edited 1 time(s). Last edit at 10/06/2014 01:53AM by polyglot.

Have you seen the Sextupteron that Nicholas Seward has been working on. There is a short write up in the last Reprap magazine issue.

---

[scara3dprinter.wordpress.com]

The machine isnt the issue, it reasonably easy

The slicer/tool path software is the issue.

I hadn't seen the Sextupteron. It looks like it would be good for milling (where gravity is irrelevant), but what I'm suggesting is to rotate the printed item in X and/or Y while it's being printed. The sextupteron doesn't help you much with printing protrusions out into space because it rotates the tool not the workpiece.

Imagine putting the heated build plate on a gimbal; it's mechanically a bit messy but not particularly difficult. Actually you could probably do it with an upside-down Sextupteron moving the print bed and using a fixed print head.

Yes, the tool-path generator is the hard part, especially designing it to get the most out of the machine, i.e. optimising part strength. I imagine that it would start out like the 5-axis mills did, with special-purpose code written to generate tool paths for specific shapes like turbine blades, rather than a general-purpose STL-to-G-code conversion.

For example, consider a propeller. We can sort of print them now and hope the underside of the overhang doesn't become horrible, but imagine a machine where the process to print a blade is:
- build a tower upwards/outwards from a core (radially weak, but clean with no overhangs),
- rotate part 90 degrees so that arm is now horizontal
- print some radial filament on one side of the blade (for radial strength),
- rotate part 180 degrees
- print radial on the other side

et cetera. That's just one special-case but if people are willing to write code that writes G-code instead of draw models, it's doable. Given that people happily write SCAD now, I don't think that's too far-fetched.

The general case would have to evolve and optimise over many years, just like slicers are currently doing and other CAM tools already have been doing.

... my company sells separate 4+5-axes and software for synchrone 5-axis-milling - [www.imes-icore.de]

It's not so big a problem to change the path-generation from subtractive to additive - but the controllers, axes and software are not meant for DIY price tags

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

RepRap is not a Multi Million Dollar Company that could afford to pay a development team to produce something in 5 years.

To move this good Idea forward we need to split it up into smaller projects. So that we can find projects that can be accomplished by motivated RepRappers right now. Those projects can then lay the foundation for the next Projects.

So what could be the simplest possible modifications be to make the first step in this direction?

Simplest step forward is a single-axis roll stage under the heated bed. One stepper, a couple of bearings, some framework and a printed 600-tooth GT2 gear Probably under $50 in mech parts assuming there's a spare stepper driver on your controller board (e.g. RUMBA has 6, which means 2 spares on a single-extruder machine). Then the hard work and experimentation begins, e.g. trying to print a dome where the top surface is sliced in Y not Z.

Im sure it would a nightmare to develop the firmware, but could you use something like a robotic arm?

There are already those large industrial size robotic arm printers, do I dont see why (apart from firmware) it can't be implemented on a Reprap scale.

---

greghoge.com

HUGE 3D PRINTER PARTS SALE!!!

... when 7 years ago I've presented my 'tripod', the greatest problem was the software

Now the deltas/rostocks/kossels are all around and several of the firmwares can be changed for parallel kinematics.

So yes, with time and some skilled people, this should be the same for 4, 5 and more synchronized axes ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Like the Hardware the Software is not a one step thing. More than that the first step to change the software needs to be a clear view of what is needed.

For example the Idea with a dome surface sliced in Y and not Z: You probably don't want to do that if the dome is a ball (underside of the ball. If the dome sits on top of a Tower, where should be the switch between slicing in Z and slicing in Y. If the Model hat two such towers of different hight how should that be handled. Printing in Y on the lower tower while printing in Z on the higher tower? Printing everything in Z and then come back to print all the Sliced in Y parts?

or the other Example the propeller. What exactly should be printed before the turning. How should that surface that then will get the winds printed on it look like. What about the infill ?

If you and others are really interested in this then start a Wiki page and write it down. Put it clearly down what a slicer should do, how you want the G-Codes to be generated. Define which surfaces should be sliced in Y, explain how the Sliced in Z part of the model needs to be for the Sliced in Z Part to fit in perfectly,...

All this information, and all these decisions will have to be made before a new Slicer can be created. You don't need to be a programmer to collect that information or make those decisions. And it will make it easier for the Programmer to i9mplement that.

And having a Wiki Page that several people work on will help find a programmer motivated enough to just implement it.

Talk is cheap, show me the Wiki page!

A modified version of Slicer could make the job with it's "modifiers" function to position the print head with another direction than vertical
- Import volumes overlaping your part in areas where you want to change the print head's direction. The intersecting surface must be flat.
- Set how much space must be left around the head --> for colision dectection between the head and the bed or part, display colisions in the 3d view
Slicing :
- Slice the vertical part
- Slice one layer on each modified volume with the head normal to the intersecting surface, and so on

One way of doing the mechanics would be to use a Stewart platform. Like a delta printer, this has the advantage of regularity - you basically need to make 6 linear actuators with universal joints at the ends. If someone with mechanical skills can work out how to do this cheaply, I'd have a go at the kinematics software (I recently finished implementing precise, segmentation-free delta movement in the firmware for Duet electronics, so I need another challenge). But IMO the slicing software is the bigger problem, as others have already said.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I'm skeptical that additional axes will be useful for a 3d printer. Milling machine tools can be long and thin, but an extruder is extremely bulky and would have a hard time with many geometries, especially close to the build platform. You have the heater cartridge, heatsink, fan, and sometimes a mess of tape and wires as well.

There are arguably some strength/asthetics advantages to be had with 5 axis printing, but frankly it will make the process enormously more complicated and making use of those capabilities would require manual input to the toolpath generation process. A second extruder with support material is a hell of a lot cheaper than two rotary axes and matching software.

Don't underestimate the difficulty of building an accurate rotary axis either. On a linear axis, 0.01mm of error is 0.01mm of error. On a rotary axis any error is multiplied by the radius of the part.

@polyglot: Gravity has nothing to do (or very little to do) with FFF printing. I regularly print upside down and sideways just to prove that point. Check the CoreXZ video in my signature if you want proof.

Great News!

I have a student that has made a generalized nonplanar slicer.


I wouldn't say that is ready for prime time but it is a good proof of concept. Right now we used a 3DOF but now that this is done we can just make the nozzle stay normal to the surface when we migrate to a 5DOF printer. We also need for it to intelligently pick the layers so it can reduce the staircase effect on top layers and can reduce support structures.

I now have an awesome BBB with a CRAMPS shield that not only has enough stepper drivers but also can run machinekit which will allow my to deal with the kinematics of the Sextupteron.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

I agreed with 691175002, one of the biggest issue you will have to deal with in a 4 or 5 axis printer would be the hotend, you would have to shrink it to needle size and make it long to work without crashing issues, also some geometries will be difficult to work with (selecting best axis to be printed on).

No doubt once all bug worked out it will be an amazing printer, but I doubt it will be at the regular reprapers monetary grasp.

I would think that companies like Stratasys and Z corp, with all their capital and resources have already come up with that, but they haven't. You make your own conclusions.

Quote
ggherbaz
I agreed with 691175002, one of the biggest issue you will have to deal with in a 4 or 5 axis printer would be the hotend, you would have to shrink it to needle size and make it long to work without crashing issues, also some geometries will be difficult to work with (selecting best axis to be printed on).

I wouldn't underestimate what can be done with standard hotends. It really just becomes a software problem. The software has to know the shape of the hot end and plan accordingly. Software is hard but ultimately cheap. (For the technical types, the hot end will define the max allowable curvature of the layer. I think you might be surprised at how tight the curvature can be for a fairly blunt hotend.)

I am working toward getting the software done. Eventually, I will build a Sextupteron (link below) which won't be much more expensive than a standard RepRap machine. Time will tell.

I just want to point out that the fact that it hasn't been done before is just as much a reason for doing something as it is for not doing it. Someone has to be the first or there is no progress.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

6-axis 3D Printer from 2013 [www.youtube.com]

After seeing this 5 axis 3D printing video here the ideal 5 axis printer would probably be a rotating print bed. That way you can disobey gravity, even though it's the law

Maybe a delta with a 2D rotating print bed? Adhesion would have to be really good. Maybe a print bed with something like an inverted delta that can 2D rotate and lift? (3 linear actuators, one center up/down one with saddle joint and two X/Y rotation arms with ball joints). Or just print bed mounted on a 6D stewart platform and the hotend is fixed (would allow for a lot of weight e.g. 4 direct extruders for mixing).

The software would have to be very clever indeed. It would have to figure tool paths according to strength and gravity and overhangs. Like trying to sort a bowl of wet noodles! And it is probably impossible to create a "closed" surface finish because you can't easily trace the outline of a horizontal slice. Instead you would have to "infill" outside surfaces where your have sharp angles. Ideally you would need varying extrusion thickness.

Hmm... I've once read a paper which might help, something about texturing 3D models to create minimal distortion in texture mapping. One idea would be to start with the outer surface and initialize through simply horizontal paths. Then calculate mechanical stress for all the surface points and try to optimize a globally error function through iterative local refinement. You'd probably have design the algorithm with parallelism in mind and later implement it on a GPU to get a reasonable fast "3D slicer". Basically load the 2D slicer output and then try to optimize the tool paths for:
1. Stability / criss crossing extrusion paths
2. minimal distortion
3. Overhang stress
4. Avoid hotend crashes

Hmm thinking about this it might be easier to design and build an SLS printer and have all the overhangs you could possibly want

Edited 1 time(s). Last edit at 04/04/2015 04:32AM by Dejay.

@Dejay. I would like to note that gravity has very very little effect on how a printer works. Take any rigid printer and flip upside down for proof.

The 5D slicing that I am working on doesn't concern itself with mechanical properties but it will likely make the part stronger. The secret will be to make it just as easy or easier to use than a 3D slicer.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Yeah sorry for some reason I didn't read the whole thread properly before replying. Printing overhangs and just adding a pause to let it cool might work even better than moving the build plate around all the time.

My guess would be as soon as you even vary the orientation of inner and outer layers a little bit you will get far stronger parts. Or even just a wavy print like your picture should be much stronger in Z.

Building a 5-axis printer isn't "hard" in any meaningful sense. All the hardware design requirements, forward/inverse kinematics, numerical path solution techniques, and even force dynamics for hexapods, rotary tables, etc are perfectly well-documented in readily-available sources. It's all in the robot control academic literature. MachikeKit has some code modules that already do limited 5-axis control, such as maintaining constant plasma cutter angle around an XY curve to produce a nice curved bevel.

For a super easy hardware implementation, a simple column hexapod can be build on a column delta type architecture, but with three more columns. It's trivial to build. You could design and assemble such a hexapod over a weekend. And then controlling it is a bit more work, but it's really just implementing some additional kinematics and dynamics code based on published algorithms, perfectly doable for a decent programmer.

The big, hairy technical problem is getting the slicer to make decisions. Today's 2D slicing is more or less deterministic. Convert the 3D shape to a series of planes, outline and fill each plane, done. Sure, you've got special rules for things like support and bridges, but those are pretty simple ad hoc heuristics. (If the surface polygon normal is angled so and so, add a tower under it.) That's the stuff computers do well. 5D slicing is a lot harder. It's easy for a human being to say "I would slice that overhang using an angled motion path" or "this arc would print well if the tool paths traced the lower edge" but that's actually an extremely challenging form of recognition and judgment for a computer.

5D slicing with manually-defined tool paths is good for tech demos, but to make it useful in a mainstream sense, you need automated 5D slicing that uses some sort of judgment based on shape recognition to generate non-planar tool paths. That's big. It's arguably an AI application. To date, anyone putting that much effort into the software is selling it as a commercial CAM product, not giving it away for free.

So, my question is, what "baby step" applications can we come up with for 5D tools that would be reasonable to implement in slicers? Top surface contouring is the best thing I can think of. What else can 5D printers do that wouldn't be hard to program?

Quote
RCarlyle
So, my question is, what "baby step" applications can we come up with for 5D tools that would be reasonable to implement in slicers? Top surface contouring is the best thing I can think of. What else can 5D printers do that wouldn't be hard to program?

What would we actually want from the slicer? I can think of three main requirements:

1. improve part strength in the z axis by not having all extrusion parallel
2. reduce staircase effect
3. print overhangs and print partially "top down".

Can anyone think of any other?

1) The first one is probably the easiest. Cross stitching would be ideal but very hard, for example printing a cylinder from the inside to the outside but one layer parallel to the build platform and the next layer orthogonal. But adding a simple "wave" pattern like shown above in the slicer by nicholas' student might already be sufficient to increase strength in the Z axis significantly. More might not actually be feasible for most parts because of the limited rotation of the hotend and the size of the nozzle. Or maybe you can limit the cross stitching to the inside of the part.

2) The second one alone could probably also be done rather easily. To reduce the staircase effect you might do with simply angling the hotend along the surface normal and adjusting layer heights. You would basically add additional but thinner layers. You could take a space deformer (e.g. a 3D space grid deformer or a thin plate spline) and stretch / deform the model in Z so that the top surfaces are flat, then slice it normally and transform it back, reducing the layer sizes. Not sure if I explain this very well. Imagine a cube with a sloped top surface. You would stretch the cube so that the top surface is parallel to the print bed, slice it and then reverse the transformation. You would still slice the normal deterministic 2D way just on a deformed model to create "additional" layers so that the top comes out even.

3) For the third one you could break up a 3D model where overhang would have to be printed from a different orientation. Similar to algorithms that create convex parts out of a concave mesh. Stuff like that is used in game engines for rigid body physics. So you have to generate a kind of "seam line" where you would want to "attach" an part that is an overhang. For example the arms of a figure you would make a cut on the shoulders and leave the arms out first, then rotate the tool head to attach the arms from a different orientation. This wouldn't work for all cases (e.g. two overhangs facing each other) but probably for some practical cases. But even something simple like printing a window or a straight table with four legs won't really work. Something like an easily dissolvable support material would work much better.

1+2+3) Of course ideally you'd want a kind of global optimization over a lot of tool paths (big bowl of spaghetti!). You could initialize using the result of the standard 2.5D slicers and then try to optimize incrementally. You would calculate a local and global error value and try to nudge the pathes into a better shape. But using the "hamfisted" methods above might actually lead to better results because a local optimization could easily fall into a local optimization. Or it's simply way too expensive to calculate even in parallel on a GPU.

Maybe 5D printing is simply not really practical because of the limitations of FDM printing?

On the other side maybe you could implement portions of 1 and 2 even without additional axis? Even if the toolhead isn't angled to the surface normal you might be able to significantly reduce the staircase effect on the top layer by adding thinner layers. You'd simply have to adjust the extruder speed to the layer height. Maybe a dome shaped hotend nozzle would help with "ironing" the top layer more flat. And only adjusting layer height on the top surface alone (without any fancy deformations) could reduce the stair case effect.
And the wave pattern shown above should already increase strength of the part in the Z direction.

Well, just some crazy late night ideas! Hope any of it makes sense

Edited 1 time(s). Last edit at 04/18/2015 04:23PM by Dejay.

Hmm, I think you need to separate this out into two separate issues:
1) Non-planar slicing with traditional 3-DOF XYZ mechanism printers (eg what Topolabs and Nick's student are doing)
2) 5D slicing with 5-DOF XYZAB mechanism printers (AB here meant in the CNC sense of rotary axes about X and Y, not just extruders)

You can do a lot of stuff with just non-planar slicing. I think it can do anything you'd want to do in the, say, 0-20 degree tilt range. That's where the stair-step effect and overhang droop are the worst. This is entirely a slicer issue. No new hardware or kinematics required.

I'm curious where the true 5D slicing would actually be really useful. Stuff like helically wrapping cylinders is cool, but how often are you really going to want to do that? It's hard for me to imagine an application that really justifies the development energy (at least compared to plain-jane non-planar slicing, which definitely seems worthwhile).

Here is another result of my students generalized nonplanar slicer. He is planning on making it open source although it isn't polished enough for a product for those that don't want to dig in the code.

I personally am trying to hobble together a nonplanar slicer for html5.

My baby steps in no particular order are...
1) Allow wavy layers for fun. (Nick Parker test the strength and didn't get much of an increase in shear strength. More testing is required.)
2) Smooth out top layers.
3) Angled bridging
4) Slightly increase in support-less overhang angle. (At least until I upgrade from 3D to 6Dprinting.)
5) Print on arbitrary surfaces.

If I keep 5D printing in mind while I implement all of these for a standard 3D printer then the transition should be smooth. (pun intended.)

I know the argument against this is how to do this well you will have to make the software similar to CAM software for 5D mills. (It is a steep learning curve.) However, I have pretty good algorithms to solve all 5 of the problems above. To switch to 6D I will just have the printer's nozzle remain perpendicular (withing an allow deviation range) to the local normal of the layer. Once, I do that then I can do crazy things like print a part like below with only one exposed layer.



Edited 1 time(s). Last edit at 04/18/2015 05:38PM by nicholas.seward.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Wow! Now that's just awesome! Thanks for sharing

And html5/javascript as a web app for a slicer would be a great platform as well.

@nicholas.seward what is the reason to choose html5 for the slicer?

I disagree with @Dejay on this. I don't think that html5 is a good platform for a slicer. I think that if you compare Skeingforge to Cura in speed you will see why.

Maybe you can save some time in slicer development if you start by extending CuraEngine ? There is no value in reinventing the wheel all the time, right?

@JustAnotherOne:

1) Speed is not really an issue. Cura is a great example of a high level language implementation that is fast. With smart algorithms and data structures many operations can be O(1) or O(log(n)). I never used Skeingforge but I suspect that it does many things with O(n) complexity or worse.

2) I will look at Cura but remember that it was designed for planar printing. There are so many way planes simplify slicing that I would be suprised if it wasn't baked in.

3) HTML5 is cross platform, social, accessible, extendible, etc. If you want a desktop app use it as a standalone chrome app. It is all client based so the server only has to send the script. It is easy for others to steal my code for integration into other online workflows.

4) You can also inject custom user code into app. Writing a user script to print some layers at .2 and others at .4 based on rate of cross section change would be a few lines of code. Particularly useful hacks can be sent to me for consideration as a standard button feature.

I hope I have made my case but we won't really know until I build it.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Quote
nicholas.seward
@JustAnotherOne:

1) Speed is not really an issue. Cura is a great example of a high level language implementation that is fast. With smart algorithms and data structures many operations can be O(1) or O(log(n)). I never used Skeingforge but I suspect that it does many things with O(n) complexity or worse.

I agree that speed is not the most important issue. But Slicing the same Model on the same PC took 20 minutes with Skeingforge compared to 1 second with Cura. That is a rather substantial difference. And it would be sad if we would loose this benefit.

Quote
nicholas.seward
2) I will look at Cura but remember that it was designed for planar printing. There are so many way planes simplify slicing that I would be suprised if it wasn't baked in.

It is open Source and modular. I only wanted to suggest to not start completely new, but to use the code that is already available. If you manage to make your changes as a CuraEngine plugin/Extension then even better.

Quote
nicholas.seward
3) HTML5 is cross platform, social, accessible, extendible, etc. If you want a desktop app use it as a standalone chrome app. It is all client based so the server only has to send the script. It is easy for others to steal my code for integration into other online workflows.

"social, accessible, " That is bullshit. Then you can say the same about C++. C++ is cross platform, extendable, you can do desktop apps, it is all client based and the server does not even need to send the script. And the code is easily reusable.

Quote
nicholas.seward
4) You can also inject custom user code into app. Writing a user script to print some layers at .2 and others at .4 based on rate of cross section change would be a few lines of code. Particularly useful hacks can be sent to me for consideration as a standard button feature.

I hope I have made my case but we won't really know until I build it.

Cura has already a finished Plugin for such things. So for do something at layer X you need no code at all as the plugin is already done.

If you say that C++ is not your language and all you can code in is JavaScript, then do it. But just for being "social" I think the speed penalty that will probably be in the same order of Skeinforge compared to CuraEngine is too much. But that is only my opinion, you may have your own.

@JustAnotherOne: By speed not being an issue, I mean that JS can be just as fast as CURA (or faster). Cura and Skeingforge are both written in python. JS usually benchmarks above python (that is even before stuff like asm.js that will get you to within a factor of 3 of C performance). However, that is not the point. My claim is that with smart algorithm and data structure choices (similar to what Cura has done) you can be as fast as you need to be in even slow scripting languages (like python).

With an HTML5 approach, all I have to do is give someone a web address. They can have a phone, tablet, mac, pc, linuxbox, etc and it will just work. I could even give a link to it preconfigured if I am helping someone. People could share configs for different printers and different prints. It isn't so easy to do all that unless it is web based.

I agree that Cura is amazing. They got it right. I will be spending a lot of time studying their code. If it is possible to sanely make it a plugin. I am pretty sure that Cura hasn't provisioned for allowing nonplanar stuff in any meaningful way. (I have seen the wavy print from cura but those are still very very far from what I am trying to do.)

Bottomline: A nonplanar slicer doesn't exist and its codebase will be substantially different from a planar slicer.

I should also not that there are projects like pypy.js that could allow me to port Cura into HTML5 and make it faster with minimal changes. (I am not saying that is how I am going to go but it is certainly possible.)

Edited 2 time(s). Last edit at 04/19/2015 12:41PM by nicholas.seward.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

@nicholas.seward : I don't see the need for slicing on a phone, thats probably me growing too old.

But more important you misunderstand Cura. You are right that the GUI is Python just as Skeingforge but the fast Slicer is C++ !

Cura == Python == GUI
CuraEngine == C++ == Slicer used by Cura

So with JS being as fast or faster than Python you will be as fast or faster as Skeinforge.

The speed difference between Skeinforge and Cura is simply the difference between compiled code and interpreted scripting languages. The Code of CuraEngine might also bee smarter than Skeinforge. I don't want to step on anybodies toes here. But the huge difference is not smarter code.

From what I know about slicers it starts with reading the Model File. With STL Files the next step is decoding the triangles, checking for manifold, direction of normals (where is outside), fixing inconsistencies,... There are a lot of malformed STL Files (And STL generators) out there and Cura has different mechanisms to deal with many of these problems.

And it ends with translating the calculated path into G-Codes and writing the G-Codes into a File.

I don't see the big difference between nonplanar and planar slicers in those two parts. But I'm just trying to be helpful, so just ignore me if I'm wrong.

@JustAnotherOne: Yeah, you are right. I looked up CureEngine and it is indeed C++.

There is no magic wand of compiled vs scripting languages that will account for the difference between the runtimes of Skeingforge and Cura. It is all about smart design. (For some perspective, my student's code initially took hours to do his nonplanar slicing. It now takes less than a minute. I also know that he has not optimized many things that are hurting his performance. His code is written purely in Java.)

You are right about things a slicer does. However, the middle part where you define the layers is defined by one number in Cura. In a nonplanar slicer it will need to adjust to the model and it will need the engine to have helpful tools to decide on how to warp those layers. Even the gcode generation at the end will have to be redone. You will have to continuously look at how far layers is are from the layer below (because it is always changing) to adjust the extrusion amount. It all goes to shit if you allow layers that aren't functions of x,y. (A vertical line can go through more than one point of a layer.)

To be clear, I will do a design review of all the open source slicers I can find before I start in earnest. If one can be modified with less effort than building a new one then I will. Additionally, even with the c++ backend of Cura it could be ported to HTML5. PNaCL

I understand that you are trying to be helpful and trying to push me toward Cura is a smart thing to do. I just know how I would optimize a slicer for planar layers (Cura) and many of those optimizations would prevent the use of nonplanar layers. Again, I will read through the code base and hope to be wrong.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ