Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
alaris2

a brand new slicer - does what YOU want?

Recommended Posts

so it looks like the time has finally come when the slicers available just can't go where I want to go next and I'll have to sit down and write my own.

it will concentrate on multi-extrusion - support + structure, multi-colors, multi-material and fix that annoying and persistent bug of lousy quality top surfaces.

before I set about doing this, I thought I might as well ask if anyone else wants to be involved, or has feature requests, or whether everyone's totally happy with what they've got, in which case I'll just get on and do it.

if there's a high demand, I suppose the question has to be what I do with the software - make it payware like netfabb, free and paid editions like k'slicer, donateware, or completely and utterly free (as in crippled, not beer).

all comments welcome at this time to help me make a decision.

cheers, nik

Share this post


Link to post
Share on other sites

If you make it free, and just concentrate on the slicing and not on the GUI, then we could bolt it below the Cura GUI. (I pretty much designed Cura around the ability to change slicers at some point)

Also, I've been testing out dual-extrusion support PVA prints, and I've learned quite a bit about them. PVA and PLA can be a good mix for soluble support prints, and I can get it to work with SF. But it could be done smarter.

Share this post


Link to post
Share on other sites
I would say do like most others, make it free at first mentioning that the license can change at any time, dominate the market with your better product and then charge like hell ;).

+1 for making me lol ;)

I am tempted to not bother with the GUI, which would benefit Cura - but I suspect there are some stumbling blocks. PVA might be interesting yes,

Share this post


Link to post
Share on other sites
I am tempted to not bother with the GUI, which would benefit Cura - but I suspect there are some stumbling blocks. PVA might be interesting yes,

Note that I wouldn't mind putting some effort on Cura to support your slicer. If I could get rid of SF, that would be awesome. I've even asked Jonathan from KISSlicer if we could make a Cura with a payed licensed KISSlicer as slicing engine. But he told me that he could not do this right now (not sure why)

Cura currently calls it's own slicer as commandline tool, with all the settings as parameters. You might want a different set of settings for your slicer, but that's easy to change. All the magic for this is hidden in

https://github.com/daid/Cura/blob/maste ... liceRun.py

You can even see that there still is some Slic3r code in there ;-)

Share this post


Link to post
Share on other sites

I've been thinking of writing a slicer too... It's a difficult proposition.

I already have code that I wrote for a previous project that can take an STL mesh, break it into a BSP tree, and perform CSG operations on it using BSP math operations. Since it supports 2d planes as a primitive the slicing is simply a matter of doing an intersection operation on the BSP tree, which returns a solid 2d triangle mesh of the slice in a BSP tree. But then the devil is in the details... From here I find that it gets hard.

I've not put any fingers to keyboard yet, so far I've simply mulled it over in my mind... But once I have a list of 2d cross sections actually generating the toolpath is far more complicated than it seems. At least to my mind. Firstly, I get a triangulated mesh. I need to break that down into parimeters and in-fill. The easiest way I can think of to determine what is upskin / downskin is to run through the whole list of slices twice from bottom-up, and then top down. For each slice do a BSP tree intersection between the current and previous layer. This would give me two regions - the overlap region (which would be regular infill) and the non-intersecting region, which would be downskin or overhang. Doing this from bottom up gives me the downskins and then from top down gives the up skins. My BSP math functions are pretty quick so it shouldn't be too bad to do this stage..

Once I have that, then I need to determine the outermost contiguous polyline... Since I will have mesh triangles going into the mesh infill I need to identify which ones are not adjacent to other polygons, sort these, and then form the shortest path across all of these faces.. The actual algorithm to accomplish this still eludes me.

The BSP tree code I have is written in Java... There is still one bug in it somewhere that I havn't found that applies to 3d operations on large meshes over 2000 polygons... It also tends to produce lots of of branches on the tree because there is no optimization in picking the root. Each subsequent BSP operation then causes the triangle count to increase exponentially. I need to add a mesh optimizing function in after every CSG operation or the polygon count quickly gets to the millions for very simple meshes. This was all written for a parametric modelling language I've created similar to OpenSCAD. I'm not sure when (or if) I will ever actually release it.

Cheers,

Troy.

Share this post


Link to post
Share on other sites

I love the idea, but cannot help wondering if the coding people (KISSCLICER, CURA coders and so on) couldnt just all sit down in a room, with some beers we could all come up with a way of progressing using what we have plus some

development, rather than starting from scratch...again.

I cannot help with coding, but here would be my feature requests:

1) Ability to flip STL models around properly. Then I can basically just delete Netfabb

2) Ability to handle large CAD models. CURA currently just cannot cope at all with my

CAD data file size. Which is a massive limitation for real engineering applications.

3) Fixing the issue whereby the infill does not properly touch the walls, sorry but it IS a slicer issue.

4) Making it have the ability to set wall thickness in 3D, so we dont get this staircase effect

giving holes in the top of thin arches, this plagues all current slicers and SUCKS.

5) Ability to print infill in different material from the main body.

6) More options for infill patterns. So square, circle, hexagon, straight lines only, waves.

I feel that so much work has already been done on the GUI by Daid, and such superlatively excellent coding

has been done to slice on KISSLICER....that it seems sad not to somehow team up a bit.

Having said all that, a big lesson is that a mediocre desision tomorrow, is far far better than a perfect descison in 6months. So if all the guys cannot be persuaded to team up anytime soon, then by all means write your own code.

Perhaps KISSLICER could donate the basic slicing engine code, for an agreed slice (sorry had to do it) of the royalties.

I would gladly pay €150 for a really great slicer which complied with my reuqirements. I already did for a rubbish slicer that complies with hardly ANY of my requirements !!! haha (no prizes for guessing which that one is).

Share this post


Link to post
Share on other sites
I feel that so much work has already been done on the GUI by Daid, and such superlatively excellent coding

has been done to slice on KISSLICER....that it seems sad not to somehow team up a bit.

Perhaps KISSLICER could donate the basic slicing engine code, for an agreed slice (sorry had to do it) of the royalties.

I suggested that to Johnathan, but he didn't want that.

Share this post


Link to post
Share on other sites

totally agree SG. i've been putting this off for ages because I felt someone must surely be about to do all this.

except they haven't. :(

Daid's done a nice job on the UI for Cura, and the slicing engine in k'slicer is current state of the art. but you're right, there are features missing, and that's a really good starting list.

for #1 - did you mean flipping normals, or mirror?

#3 - yes I know, there are lots of people in denial still tho.

Troy> I was planning on C rather than Java, do you think (or are you interested in) a port of your algorithms?

Daid> here's a big question. right now, few people know SF exists as the back end of Cura. credit for everything goes to yourself. You're now a UM employee too. This might be part of the reason Jonathon was reluctant to help - how would you envisage credit working between all parties? or paid/free mixing of software? and is your intention that Cura be UM-specific, or for all printers (it now includes a UM robot and UM model by default I see..)

put another way - the UI can control everything the engine does and everything the user sees and experiences (which is hopefully good, but sometimes can backfire) - is there any means in which the engine can exercise some control over the UI?

there's a whole bunch of other things to consider too, but probably best to have this discussion off-line.

let's keep this topic to 'does anyone want a new slicer?' and 'what things do you want it to do?'

Share this post


Link to post
Share on other sites

I dont care about mirror, but its annoying as hell when I cant get the part flat on the bed in the

slicer.

I have one or two that just cannot be rotated properly in CURA, they can be rotated around to all

positions except face down ! Of course I usually try to sort it in CAD before I make an STL, but

sometimes I forget, or have to use an axis system that isnt the "slicing" axis system.

Share this post


Link to post
Share on other sites

Nik,

I would consider a port to C++. As it is, the algorithm would be difficult to port to straight old C but a C++ port should be fairly straight forward. I used to do all of my personal development projects in C++, but these days I'm working with Java at work... I used to hate Java, but it's actually grown on me... I actually decided to do this in Java because I was considering cross-compiling it to JavaScript (as in Google Web Toolkit) and/or running it as a webservice with a web front-end... And possibly an Android port... Though I haven't done any of that and that was all secondary to running it on a PC anyway. The bulk of my Java code is the language parser itself for my parametric modeller. Ultimately, I am also interested in continuing with that project and seeing what I can evolve it into. The problem is that I just don't have much time these days. I only sped a couple of hours a month on my coding projects...

Cheers,

Troy

Share this post


Link to post
Share on other sites

I would say that in addition to what everyone else has said, there needs to be a plan to get some profile inputs from users to get some settings close on a secondary release for people with different machines. Daid did a great job when writing the defaults for Cura to get people fairly close out of the box. KISSLICER kinda works if you know someone that has some decent profiles. If the plan is for utilizing this as an Ultimaker-only slicer, then hey, that ought to be pretty easy, especially if the backend works well enough for people to convert. I think it'd be cool though to get some other machine profiles in there, too.

Share this post


Link to post
Share on other sites

Yes thats a good point. I think that the ability to transfer settings instantly between users is great.

I like the config files that kisslicer uses, except that having 3 seems pretty overkill.

Kisslicer was indeed more of a pain to get a setup from, from scratch. But once you get close its a piece of cake.

I think this mostly stems from it being mostly started off to work the horrid BFB machines.

Share this post


Link to post
Share on other sites

they have 4 config files in the newest release. you're right, one is plenty enough.

Troy> I have the same problem with finding time, and yes sorry I meant C++.

SG> Ahh, I understand what you mean. OK i use repG to solve that problem not netfabb. it's pretty annoying to solve when the file comes from a 3rd party too. definitely on the list!

Share this post


Link to post
Share on other sites

I have a huge list of ideas for a slicer. From easy to complex. But before starting from scratch, look at what is out there. Slic3r is there, but with it's perl based. And still has some design flaws IMHO (not as many as SF).

Cura is currently SF based, and I used to advertise that quite large, but as Enrique has no interest in 3D printing, the code is a huge mess, and I was not credited for updates in SF. I feel little need to credit SF more then I have to. Also, people read "SF" and instantly discarded it as crap.

As for a C++ slicer. First take a look at MircleGrue, it's the C++ OpenSource slicer by MakerBot. They are not using it for high quality prints, but I don't know why. (They still use SF50 for that, without any tweaks that I did to improve SF)

EDIT: Also, I've been quite clear about this. Cura IS and will remain OpenSource, and will remain supporting RepRaps. We will always have a free software option. However, putting the Cura interface on top of a !optional! payed slicing engine is surely an option, as this will give a consistent interface for bot the free and payed slicers. We also think that having a good free option will press the payed option to be even better.

Share this post


Link to post
Share on other sites

thanks Daid. yes the SF comments are very true.

I'm aware of miraclegrue, haven't had time to properly assess the code for worthyness yet. i need to look at the licence too - if it's GPL that's a no from the start.

My current thoughts are to make the software free. because collecting money and arranging licenses and such is just a pain. but even more of a pain is support. so for new features and 'bug' fixes there will be a fee (unless it's a bug in main code and affects everyone in which case it's free).

there won't be a UI (there will be stuff on screen, but not interactive).

the engine will be driven by a single config which can be modified by programs like Cura to be used as the front end.

there won't be any documentation nor source code, but I'll document the config so that people like yourself Daid can interface to it successfully.

I'll maintain the code initially, but in the event I get bored of it for some reason, I'll release it at a future point to whoever is making most use of it from the UI side (probably Daid), although the stipulation will be that there must be no commercial gain (price charged or deliberate promotion of products or inferred endorsement etc) from its use now or ever. (bespoke feature requests are a different matter and may be charged for).

how does that sound?

PS. that also means you're better off putting that list of huge ideas for a slicer in this thread now, otherwise I may consider them bespoke feature requests ;) I'll use this thread as the repository for features people want in the core edition.

Share this post


Link to post
Share on other sites

MiracleGrue is AGPL just like SF and Cura.

Your commercial gain thing could be an issue. It's not that we are selling Cura, but we are using Cura so that we have a better printer as a whole. And Cura has received some Ultimaker branding. So not sure how you feel about that.

Note that without access to the sourcecode (we could setup an NDA) I could be become quite a pest ;) as building bridges works best from both sides.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Our picks

    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!