New Slic3r

@Sublime: Like I said, I don't know/care about the status of Slic3r, what you said might have been true, might have been you being honest, however, it was your point of view. As much as you have issues with it, others might not have any issues, and when they say "no, it works perfectly", it's still their point of view. Your position was "I speak the truth, everyone else is a bullshiting liar and I will yell at them until them admit it". I took the time to write my message because maybe you aren't even realizing it.

Either way, you didn't have to explain to me the issues with slic3r, because whether or not what you said is true/honest/bullshit/whatever, it does not matter since that wasn't the subject of my post. What I was criticizing was your tone and the way you express yourself which is nothing short of bullying.
I know what it is to have a product, to have users, to maintain a forum, to answer questions, etc.. (I've done that for over 10 years) and I know how annoying it can get and how irritable you can become at the slightest question. But when that happens, you better stop and do something else with your life before it turns you sour.
You didn't attack me in your reply, and yet your tone was not right. Starting your reply with "I actually don't care what you think of me" is a good example of how little respect you showed me. Sure, you have no reason to respect me, but if you hold honesty as such high esteem, you should do the same with respect. If you don't respect others (or show lack of respect in the manner that you speak to them), then all your honesty loses its power and meaning.
Anyways, I don't want to start any flamewar. I gave my opinion on how your posts appear to an external observer, you are free to do with it what you want. I do not have the pretense of educating anyone in anything, I am merely stating my opinion, and I hope it helps you somehow.

Good luck with everything.

Welcome to the Internet. You are not going to like everything and everyone you come across. It is your choice to keep reading and make your own decisions. I am not here to make friends or sell machines, I am here to build the best machine I can and that is what I did. You do not need to like me to use the machine or build one as you never ever need to deal with me unless you want to, that is your choice.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Don't worry, I've been on the internet before And no, I don't need to like you, just like you don't need to accept anything I've said. I'm looking at tantallus now (and you seem nice in the videos :p), and I have to say I'm impressed by your work, so congrats on that. You're clearly talented, it just sucks that you were acting like a jerk :p
Anyways, let's conclude this by quoting something I've said so many times to my own users : "If you don't like it. Don't use it", that's part of your freedom too when it comes to free software, right?

p.s: A clarification. I just realized this is the tantillus forum and not a slic3r forum, and someone asked if they should use the latest slic3r, and your replies were initially normal until you exploded after Sound wrote a comment.

Quote
nophead
> I have never understood why slic3r doesn't simply
> do what its name implies. I.e. slice the object
> you give it and use that as the outline for each
> layer (offset by the filament width of course).

That's what Slic3r does - except it offsets the outlines by half the extrusion width, but I'm sure you know that.

Quote
Sublime
> I will not be spending the time to test Slic3r
> 0.9.8 after these renderings made with Repetier
> host were posted in the Slic3r thread showing that
> Slic3r 0.9.8 can not slice a simple shape (cube
> with one rounded corner) and produce smooth sides.

Unfortunately, it looks like there's a rendering issue in Repetier-Host that produces that result when a G-code file is generated with the randomize starting points option because of the different place loops start.

I'm attaching a stripped-down G-code (manually altered for clarity) that you can open with your text editor and check that layers are totally aligned, but still produces that messy effect.

Corners where the loop starts/ends are truncated this way, and when randomized the truncation doesn't happen always in the same corner:


Same comparison from top view (this shows the different shading):


Overall result showing the inconsistent effect:


Still, the coordinates in the G-code file are all aligned (check yourself). I'll report the issue, which I expect to be some annoying OpenGL artifact, to the Repetier-Host author.

The comparison you're showing is not correct, as the KS one wasn't using any point randomization (AFAIK they don't have that feature but it's in their wishlist :-D) and thus it doesn't trigger this visualization effect.

Quote

> This is all the proof I need to say that after
> Slic3r 0.7.2b Slic3r fails at consistently slicing
> things accurately. This eliminates all the
> possibility that the issues are caused by hardware
> and show it is at the time of slicing the problems
> are created. No more need to discuss it.

Fail. You owe me a beer ;-)

Quote

That's what Slic3r does - except it offsets the outlines by half the extrusion width, but I'm sure you know that.

What about mitre limits, different hole sizes and all the spiky artefacts people keep reporting?

---

[www.hydraraptor.blogspot.com]

Quote

> What about mitre limits, different hole sizes and
> all the spiky artefacts people keep reporting?

Miter limit is one of the parameters controlling how the offset algorithm works to take extrusion width into account (the offset works on the extrusion path centerlines, and it doesn't take width into account by default). For example, look at this picture [sheldrake.net]: the original slice contains a very pointy feature, where the two parallel sides are very close to each other. The offset algorithm is not collapsing them because their distance is still > 0, but they will be physically unprintable because the widths overlap. (Also look at this useful chart by Joergen Geerds: [picasaweb.google.com] - it shows how Cura and and old Slic3r handle(d) the issue; current Slic3r behavior is more like this [a248.e.akamai.net])

Regarding "different hole sizes", I'm not aware of any problem. Many many months ago I tried to implement Adrian Bowyer's algorithm for hole compensation, but that only appeared in one Slic3r development snapshot and was completely removed thereafter.

Regardings spikes, they were caused by a bug introduced in the upstream C++ library we use (Clipper), that had problems at offsetting very dense polygons. Thanks to the work of its author (the good Angus Johnson) and Mike Sheldrake it was fixed.

Sound Wrote:
-------------------------------------------------------
> Regardings spikes, they were caused by a bug
> introduced in the upstream C++ library we use
> (Clipper), that had problems at offsetting very
> dense polygons. Thanks to the work of its author
> (the good Angus Johnson) and Mike Sheldrake it was
> fixed.

Hi Alessandro - I did spot some odd spikes while doing some tiny printing last week, this was with the 0.9.8 release, I hope they are just Repetier rendering errors.I can't really tell at this size if they are causing printing issues, but I am still trying to track down a Z axis issue (appears like a half Z axis move using when using lift) that could be linked to these? still not sure.

I have tried decimating the more complex models, still get the spikes and even some very simple models do show some spikes at some level or another.



These are really tiny ones on the side of the Owl.



Just one on the heart box


Some on the small gears, not always in the same place when I make a plate.

I have attached the Heart box and gear plate Gcode, they are small enough for this forum, Owl is quite a bit bigger Gcode.

Hope it's of some use.

Cheers,

Rich.

---

[richrap.blogspot.com]

Sublime Wrote:
-------------------------------------------------------
(slic3r 0.9.8 on Wheezy)

> Actually if fails 9 out of 9 tests and does not
> work.

That is unusual. We actually run it here on a half dozen+ or so different machines running Wheezy (not all identical). We have it on Squeeze too. I wonder if something else is going on.

jebba Wrote:
-------------------------------------------------------
> Sublime Wrote:
> --------------------------------------------------
> -----
> (slic3r 0.9.8 on Wheezy)
>
> > Actually if fails 9 out of 9 tests and does not
> > work.
>
> That is unusual. We actually run it here on a half
> dozen+ or so different machines running Wheezy
> (not all identical). We have it on Squeeze too. I
> wonder if something else is going on.

Its 64bit and running the Kernel from the experimental branch because the computer is brand new and the video card is an Ivy bridge which was not supported until very recently. If there is a way to give you the output from the test install I could try sometime and post it for you. Right now the error is longer than the terminal screen.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
richrap
> Hi Alessandro - I did spot some odd spikes while
> doing some tiny printing last week, this was with
> the 0.9.8 release, I hope they are just Repetier
> rendering errors.

Hello Rich,
these are indeed rendering errors caused by some wild mitering in RH/OpenGL :-) taking place when infill has acute angles.

This is the layer containing the spike, I chose the "lines" rendering mode to get the image on the right and you can see the path is correct:

Great news, but it does now mean I need to do some more printer tuning if I can't blame the slicer

And I fixed the Z axis issue, that was mechanical

---

[richrap.blogspot.com]

Hi,

Richrap,

Please could i get your email address i would like to contact you about a project we are working on.

All the best,

Perry

perry_buckler@hotmail.co.uk