reduce resolution

[arhi]

I have STL that is "too high resolution" and I need to print it on a "coarse" print settings, so rather fast. S3D is creating too many short segments on the curves. Now I know I can reduce the resolution of the STL but in most slicers I have a way to tell slicer to not generate this many moves. I think there was a way to do this with S3D (iirc 3.0.1 came with that option) but I can't find it. The Advanced/Single Extrusion/Minimum Extrusion Length seems to affect only single extrusion filling and not general G-Code. Who remembers how to tell S3D to reduce resolution of the print?

This is what for e.g. CURA has in "mes fixes"
- maximum resolution
- maximum travel resolution
- maximum deviation

or SliC3R / Prusa Slicer
Slicing / Resolution

I'm sure I seen this somewhere in S3D but can't find it for hours

[archester]

My suggestion is to select "fast" in the auto-configure for print quality panel ( in the editing process settings menu).

Here is the official video tutorial from Simplify3D: www.youtube.com

Hope it helps

[arhi]

My suggestion is to select "fast" in the auto-configure for print quality panel ( in the editing process settings menu).

that just changes predefined profile, I use advanced options to setup stuff, I want to setup resolution like I can in other slicers

[PicoTreed]

Hi,
there's no such thing as an "Resolution" option in S3D, you have to play with the usual parameters in order to speed up the print (maybe try also to increase the minimum lenght deposition value for infill and single extrusions.)

I'm sad, but you are tied to the approximation-intepretation chain that lie between the STL resolution, S3D decisions and firmware rasterization.

[greybeard]

I've gone through this exercise so many times to produce parts for 3D-printing and CNC milling...

Here's the upshot (IMO)

I make my own models (generally using FreeCAD or SolidWorks). The CAD software is where the Resolution is dealt with (though some slicers have limited capability, too. Including S3D !!)

But, frankly there is Minimal benefit to reducing the resolution. Print-time is not reduced very much (though, I suppose on a print that takes 24 hours, you may save 20 minutes).

Example 1:
Comparison of a Model with two different resolutions and the S3D Pre-Print output.
Resolution was set in CAD with a difference of 'One Magnitude' (i.e., 0.2% and 0.02% Tesselation's).
Note the difference in File Size and that only One Minute was saved on a 1 hr print.

Example 2:
Resolution reduced in S3D using the feature "Mesh Reduction" Look at your Meubar/pull-down's (also the Mesh info shown).
Though the Model's mesh count was reduced (resulting in destroying the shape - obvious deformations) the, pre-print shows no benefit in Time or Filament used....

[PicoTreed]

Hi greybeard,
if you try to export a single layer (ex 0.2 mm) cylinder in different STL resolution you will observe that S3D will not mantain a linear relationship between the number of triangles of the cylinder surface and the number of G1 instructions. Slicing a perfect cube is also an illuminating example.

Sadly we don't know the S3D's algorithms and how the software internally answer the question: "Was this tessellated surface a curved surface or an intentionally tessellated shape?" So we have nothing but closing our eyes and press the "slice" button.

G-code is an obsolete solution (at least for FFF) because it contains machine instructions instead of objects description, hence the origin of all our problems.

Happy printing!

[arhi]

Most of the stuff I don't agree with but never mind, S3D can't do it, so in those cases I have to go with other slicers that do know what resolution is

@greybeard, I do most of my design myself and there I don't have a problem, but sometimes parts are not generated by myself and sometimes those parts are POS and I have to deal with them. Now I have to load them in mesh editing software and remesh to remove excess resolution in them, then I need to fix all kind of %#$^^^@ that process can introduce, and it always does on complex parts, and then I need to get S3D to accept that file and it's alll waste of time while I load the same object in another slicer and select a resolution and voila, in three clicks insted of 700MB G-code file I get 600kB ...

Anyhow, reducing a mesh is not always an option, in my case it's almost never an option, and I have netfabb professional with the usb dongle and all and many other "smart tools" to do it ..

Slicer is where you convert your "object" into paths for FFF and that's exactly where the resolution should be handled as part is a level higher than G-Code, at least in my opinion.

@picotreed, I disagree strongly, none of the machines operate much differently, the machine will run G-Code or some other machine path execution code, the format is irrelevant (BGC, GCode, XDF, UBF, those spreadsheet files sent by some machines where you don't even send paths but individual steps...) nor they should. You handle generating a path file for your machine. GCode is not universal file, nor it should be, for that you need layer above (object file, like STL or OBJ or even better STEP, IGES..) ... what is a problem is that apart from KISS none of the slicers, including fusion360 slicer that handles solids like STEP/IGES will generate optimized paths with curves (G2 and G3 codes). From all available "hobby" slicers KISS, and only in beta, support G2/G3 path generation and that is a proper way to handle curves. There's a work being done now as a postprocessor plugin for octoprint that will postprocess g-code and try to match curves and generate gcode with G2 and G3 and so far the results are freaking awesome, you take megabytes of g-code and convert to kilobytes and the output is identical or better. Better in case where firmware on the printer is not able to handle that many instructions so it choke parsing the code and that introduce artifacts on the print. S3D had serious issue with too many super small moves including 3.0 and 3.1 fixed some of those issues, enough that 32bit boards can usually cope with s3d g-code, but 8bit boards can still have serious issues parsing too much useless g-code.

So, no G-code is not obsolete for FFF, it's perfect for FFF and not much different than rest of the solutions, G-Code is not universal and was never supposed to be universal but is machine specific and the slicer is where "Smarts" need to be, not the printer. The problem here is that S3D ignores some of the machine properties as resolution of the 10x10x10cm printer and 10x10x10m printer are probably not the same, and you can't calculate resolution by nozzle only and that looks like what S3D is doing since 3.1 (before 3.1 it looks like they never had a concept of resolution so they were literaly converting intersection of the plane and object into gcode.

Anyhow, TLDR version, S3D can't do it

[PicoTreed]

Hi Arhi,
I'm into this kind of research and my opinion on this subject is totally different.
It's ok to say that G-code is not an universal file, but in the real life we use it more or less in that way. Only the machine firmware is able to know where the machine "sweet spot" lie, but we operate a double rasterisation process instead of doing it once. Provokingly I say that firmware and slicers should be ideally the same things.

what is a problem is that apart from KISS none of the slicers, including fusion360 slicer that handles solids like STEP/IGES will generate optimized paths with curves (G2 and G3 codes). From all available "hobby" slicers KISS, and only in beta, support G2/G3 path generation and that is a proper way to handle curves.

Status quo is not synonymous for the right thing, often it hide technological stagnation and Autodesk is running very fast on this matter.

There's a work being done now as a postprocessor plugin for octoprint that will postprocess g-code and try to match curves and generate gcode with G2 and G3 and so far the results are freaking awesome, you take megabytes of g-code and convert to kilobytes and the output is identical or better.

I'm well aware of it, but… what a stupid way to do things!
First we destroy CAD information by exporting in the STL format, then we degrade them more by slicing, and finally we try to reconstruct those information by a sort of reverse engineering.
I truly hope that this mindset will stay out in the future of FFF.

S3D ignores some of the machine properties as resolution of the 10x10x10cm printer and 10x10x10m printer are probably not the same, and you can't calculate resolution by nozzle only and that looks like what S3D is doing since 3.1 (before 3.1 it looks like they never had a concept of resolution so they were literaly converting intersection of the plane and object into gcode.

Read my incipit.

To conclude, in the FFF world today G-code is underused and often badly generated, so fixing that will permit years of happy printing.
But the G-code is not able to meet the rising needs in the professional FFF field (ex. FGMs) and future lies elsewhere.

Thank you.

[arhi]

It's ok to say that G-code is not an universal file, but in the real life we use it more or less in that way

that is simply not true, if one is trying to look at g-code as "universal file" one lack basic understanding of the technology where g-code is used. neither in FFF nor in milling g-code is considered universal, not even between identical manufacturers and identical models of a machine, let alone between machines.

Provokingly I say that firmware and slicers should be ideally the same things.

You have that on a number of printers. On the cheap side, TT printers are like this. It is not a very bad solution but it is a solution huge amount of ppl are paying money to leave (replace existing electronics to be able to use a slicer of their choice, like for e.g. S3D). Look at the SLA market, again it's more/less this situation, slicer+firmware are a single unit. They are spread between printer and computer but just 'cause printer don't have proper UI nor cpu capability to do preprocessing but in reality they are the same unit split into two machines. What's the most common complaint from SLA users - that's BS, they want to be able to control the process the way it is controlled now on most FFF with slicer and gcode interpreter being separate. Prusa is entering that field wide with PrusaSlicer support for his SLA machine, open-sourcing his SLA machine.

So IMO there's nothing "ideal" about joining them, it's actually easier to vendor-lock user so one can use only your filament and only your resin and only buy stuff from you but brings nothing to the table for the user. And again, even in that case, the preprocessor and the executor talk language, wether this language is g-code, spreadsheet or something else it's completely irrelevant

what is a problem is that apart from KISS none of the slicers, including fusion360 slicer that handles solids like STEP/IGES will generate optimized paths with curves (G2 and G3 codes). From all available "hobby" slicers KISS, and only in beta, support G2/G3 path generation and that is a proper way to handle curves.

Status quo is not synonymous for the right thing, often it hide technological stagnation and Autodesk is running very fast on this matter.

how are you reading me saying that's a problem with satus quo ?!
that's a problem, ppl are working on it, too bad not many ppl are working on it but it's not an unknown problem with no possible solutions
1. there is already a slicer that does it
2. there's already a patch for multiple slicers (slic3r and cura) that kinda does it (not really, but good start)
3. there's a postprocessor in the way that's being heavily developped that's showing a lot of promise

so things are of course moving forward

I'm well aware of it, but… what a stupid way to do things!

did you ever try to write a FFF slicer your self? from STL or from Solid model? Ever?
dod you ever try to write a multiaxis cam for milling, from any format, ever?

First we destroy CAD information by exporting in the STL format, then we degrade them more by slicing, and finally we try to reconstruct those information by a sort of reverse engineering.

until very recently huge (5-6 years ago netfabb did a research and it was 80+% in the all 3d printing world, so commercial + hobby) % of the objects shared in the 3D community was designed using MESH editing tools so there's ZERO information loss there, further more, out of 100% parts created using SOLID modeling tools over 80 was "touched" in MESH editing tools before being printed due to mesh editing giving easier tools to perform some operations, so again, no information loss.

now, even if everything is done solid, and you have all your info, you again have to match the curves, and matching them on solid or on mesh is not very different (except where you actually have circles, then matching solids are super fast and easy but that's an insignificant amount of cases)

so I come back to the same question - have you ever tried to make a slicer?

[PicoTreed]

So IMO there's nothing "ideal" about joining them, it's actually easier to vendor-lock user so one can use only your filament and only your resin and only buy stuff from you but brings nothing to the table for the user. And again, even in that case, the preprocessor and the executor talk language, wether this language is g-code, spreadsheet or something else it's completely irrelevant.

I'm speaking about ideas.
Bad or good implementation is another matter.

did you ever try to write a FFF slicer your self? from STL or from Solid model? Ever?

The short answer is yes.
Anyway I thought we were discussing ideas, not people.

until very recently huge (5-6 years ago netfabb did a research and it was 80+% in the all 3d printing world, so commercial + hobby) % of the objects shared in the 3D community was designed using MESH editing tools so there's ZERO information loss there, further more, out of 100% parts created using SOLID modeling tools over 80 was "touched" in MESH editing tools before being printed due to mesh editing giving easier tools to perform some operations, so again, no information loss.

In my views the current situation is not an arrival point, but always a starting point.
I do not use mesh editing tools, I'm losing a lot of precious information and this is not good (and not just for the sake of it.) Glad to know that a lot of users are happy with the actual work process, but not all users have the same purposes.

Anyway, apart from my work on this matter and the current processes, the idea of G-code overcoming is certainly not new, ask Siemens or (more recently) Boeing and Airbus.
We'll talk again in ten years, meanwhile the users will get their own idea by reading our opinions.

Happy printing.