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.
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,
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 ;-)
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.
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).
I suggested that to Johnathan, but he didn't want that.I feel that so much work has already been done on the GUI by Daid, and such superlatively excellent codinghas 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.
Hmmm thats a real shame !
Well looks like you need to warm up the Keyboard Nik...
If you do a kickstarter, I will gladly stick in a couple of hundred.
Hmmm thats a real shame !
Doesn't mean that I'm not looking at what I can do without Johnathan's help ;-)
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?'
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.
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
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.
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.
He's working on getting usable profiles included with KISSlicer from the start. He's looking for input over at the forum I believe.
edit: No, it was in the google groups. Yay fragmentation!
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!
I can live without STL rotation facility, but i suppose its to be added to the "nice but not essential" feature list.
Wheras the infill position and slicing speed and large model capability are all on the "essentials".
I would add to the desired list concentric infill!
I would add to the desired list concentric infill!
I think I understand that as a spiral from outside to inside right? that's a good idea, I was pondering better ways to do infill last night.
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.
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.
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.
I would add to the desired list concentric infill!
I think I understand that as a spiral from outside to inside right? that's a good idea, I was pondering better ways to do infill last night.
Yep! Or vice versa, inside to out...
Concentric fill is one of the many nice features of Netfabb that are missing in the free slicers. It's a great improvement to the surface finish on many objects.
Cheers,
Troy.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
31
18
14
13
Popular Days
Nov 19
14
Jan 13
8
Jan 12
8
Dec 5
7
Top Posters In This Topic
alaris2 31 posts
Daid 18 posts
codemaven 14 posts
msurunner 13 posts
Popular Days
Nov 19 2012
14 posts
Jan 13 2013
8 posts
Jan 12 2013
8 posts
Dec 5 2012
7 posts
fluxline 0
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
.
Link to post
Share on other sites