Curious About STL Export 'Coarse' 'Medium' 'Fine' For 3D Print

larry_hawes

Other than what might appear to be obvious what are the technical difference between the 3 export resolutions?

If I export in coarse, versus fine, will my 3D print be noticeably 'coarser'? Or finer with a 'fine' export resolution?

Or is it a distinction without much of a discernable difference when the rubber meets the road in a 3D print?

Thanks

billy2

fine, that's what I use

larry_hawes

billy2 said:

fine, that's what I use

I just started using fine as well but was wondering what, if any, difference one might notice between fine and coarse? I may try a test piece to see that the diff might be..

billy2

if you have a 320mb floppy it's important.

Fine is good enough for most stuff, if it's important, send a step and let them define their own resolution.

larry_hawes

Maybe my question wasn't that clear. I export from OS to my 3D slicer (Simplify 3D) as an STL file then to my 3D printer as gcode via an SD card. Maybe the resolution isn't relevant? But curious about its effect and if one can discern any difference between the settings.

brian_jordan

Interesting question @larry_hawes. I have just experimented by exporting stl files of the same model in all 3 resolutions and the first thing that I notice is the significant difference in file size for the different resolutions. I imagine the bigger the file the more information for your slicer to chew on, probably not significant for simple shapes but the more intricate the model probably the finer the resolution the better. As I say this is my best guess - like @billy2 I just use fine.

Later - after more experimentation I think I have discovered some of the answer, try this:
1 Export an stl with the resolution set to fine.
2 Start another export of the same model but this time using the "Custom" resolution option.
3 Note down the numbers pre-filled in the 3 option boxes (You don't need to complete the export having noted these numbers).
4 Repeat 1-3 for medium and coarse resolutions.
When I did this I noted significant changes in the resolution of the different files which I suspect were pre-filled when the previous option was selected.

Disclaimer: I am a rank amateur at all of this, if what I have just written is a load of tosh please be gentle with me!

larry_hawes

brian_jordan said:

Interesting question @larry_hawes. I have just experimented by exporting stl files of the same model in all 3 resolutions and the first thing that I notice is the significant difference in file size for the different resolutions. I imagine the bigger the file the more information for your slicer to chew on, probably not significant for simple shapes but the more intricate the model probably the finer the resolution the better. As I say this is my best guess - like @billy2 I just use fine.

Later - after more experimentation I think I have discovered some of the answer, try this:
1 Export an stl with the resolution set to fine.
2 Start another export of the same model but this time using the "Custom" resolution option.
3 Note down the numbers pre-filled in the 3 option boxes (You don't need to complete the export having noted these numbers).
4 Repeat 1-3 for medium and coarse resolutions.
When I did this I noted significant changes in the resolution of the different files which I suspect were pre-filled when the previous option was selected.

Disclaimer: I am a rank amateur at all of this, if what I have just written is a load of tosh please be gentle with me!

VERY interesting observation and I think what one would expect when choosing different resolutions. Big differences between Coarse and Fine. Don't understand the terms but don't see any reason not to use fine unless, as you say the model is really big. I'm just a hobbyist but have 3D printed many models from OS with fairly good results.

Here's the settings I found using your suggestion...

Angular Deviation - Coarse 12.5
                              - Medium 6.25
                              - Fine 2.5

Chordal Tolerance - Coarse 0.009449
                              - Medium 0.004724
                              - Fine 0.002362

Minimum Facet Width - Coarse  - 0.025
                                    - Medium - 0.010
                                    - Fine - 0.001

owen_sparks

I'm another member of the stick it in fine mode and leave it there club.

Don't forget you can import STL files into OS so you might see the difference by exporting using each setting and then bringing them back in to inspect.

Cheers Owen S.

brian_jordan

@owen_sparks That's an interesting idea - I was just wondering what to do this morning. ;-)
@larry_hawes I get exactly the same numbers a you for Angular Deviation but slightly different for the other 2 with yours giving smaller numbers; maybe OS is selecting values according to model specifics?

larry_hawes

Just tried your suggestion Owen and it's easy to see how much more detail the fine setting gives.

http://www.youtube.com/watch?v=kpIcHLOeVgQ

larry_hawes

brian_jordan said:

@owen_sparks That's an interesting idea - I was just wondering what to do this morning. ;-)
@larry_hawes I get exactly the same numbers a you for Angular Deviation but slightly different for the other 2 with yours giving smaller numbers; maybe OS is selecting values according to model specifics?

Interesting but does that make any sense? Dunno why those settings would change but again pretty interesting stuff.

owen_sparks

Nice job @larry_hawes, thanks for taking the time to put up the video.

Cheers,
Owen S.

larry_hawes

owen_sparks said:

Nice job @larry_hawes, thanks for taking the time to put up the video.

Cheers,
Owen S.

Yeah, fascinating stuff...

owen_sparks

One other thought, can you derive STL files? If so it be nice to see a partstudio with both files side by side for direct comparison, even just as a still screen grab.

Ta, O.S.

larry_hawes

owen_sparks said:

One other thought, can you derive STL files? If so it be nice to see a partstudio with both files side by side for direct comparison, even just as a still screen grab.

Ta, O.S.

Dunno, but STL's are very limited in their usage in OS and deriving anything makes me nuts - never understood it.

I have a feeling OS is working on a way to use STL's as true solids in OS, or convert them like a few other software programs will do and build models off of them.

Considering there are thousands upon thousands of STL's used for 3D modeling it seems like a useful feature missing in OS.

brian_jordan

owen_sparks said:

Nice job @larry_hawes, thanks for taking the time to put up the video.

Cheers,
Owen S.

What he said! I have just come in from a long walk and was going to embark on something like this - you have saved me the pain!
Thanks again
Brian

owen_sparks

Hi @larry_hawes

I agree that the current implementation of STL could be extended a bit.  There is an IR here you may wish to add your vote to.  The thing to bear in mind though is that as we've seen here converting to STL is a lossy process.  The output is just an approximation of the original CAD.  As such I'd always rather have a parasolid or a step file to import, but as a last resort it would be nice to be able to edit an existing stl.  I've had some success reverse engineering parts from stl files.  The three point circle is for example spoilt for choice on points to pick up on!

With regards to "derive" I highly recommend getting to grips with it. It's the feature that lets you grab parts you've designed elsewhere and drop them into your current design.  (Either from a library file or just something you did previously and want to reuse.)  

You can do the same with creating an assembly and then using in context editing but that's waaaay harder.

With derive you're just telling OS to "go and get me one of those".  It's usually a 2 step process as It'll come into your partstudio in the location and orientation of the source file.  So the 2nd step is a "transform" to move it where you actually want it.  I'm a big fan of explicit mate connectors defined in partstudios so I usually accomplish this move with a transform by mate connector function.

One word of caution on their use.  They're "expensive" from a computational point of view.  (To derive a part OS has to rebuild your working partstudio and the one you're deriving from.)  As such it's good practice not to have many parts all together in one partstudio if you intend to derive from it.  Also beware of linking derives, it's easy to get carried away and create documents with long chains of derives!

Hope that helps, and always a pleasure to chat.

Cheers,

Owen S.

larry_hawes

brian_jordan said:

owen_sparks said:

Nice job @larry_hawes, thanks for taking the time to put up the video.

Cheers,
Owen S.

What he said! I have just come in from a long walk and was going to embark on something like this - you have saved me the pain!
Thanks again
Brian

No problem. Love discovering details like this...

Of course I tried it with a simple cube and as you could guess there were just the simple 12 surfaces (2 each side) defined in both coarse and fine settings.

larry_hawes

I've added my support to that IR already and I too would choose STL as the last type of file to import and convert but sometimes that's all there is available from an outside source. It would be nice to simply have that STL become a part of a part studio to build a model off of. It doesn't have to be perfect but trying to mirror features of an existing STL (depending upon its complexity of course) can be exhausting.

And yeah I should learn and become more comfortable with all of OS's features but I get overwhelmed at times with derives and edits in context and multi part and on and on. I derived a part in an important doc and still cannot figure out what I did or what effect it ultimately has on my part - or the original.

...and sitting through an hour long webinar to find a simple explanation of same is pretty painful.

larry_hawes

Interesting. Found this still shot in THIS VIDEO @53 min. regarding Derive. The last bullet point stood out a bit. Not saying it's not a great feature (as this thread careens dangerously off course) but I have never truly understood it and have avoided using it. 

And as is the case with many videos about software features the presenter assumes way too much knowledge and familiarity with a feature to truly teach a new and unfamiliar user about that feature. I still have no real idea how or when to use derive, and now know just a little bit less after watching that video again.

owen_sparks

I'm betting that is a Philip Thomas slide  he's very cautious about the pitfalls of bad practice modelling (to his credit).  Derive was introduced long before In Context Edit so ICE does indeed replace its use often, but for simple things you can't beat it. 

larry_hawes said:

And yeah I should learn and become more comfortable with all of OS's features but I get overwhelmed at times with derives and edits in context and multi part and on and on.

Yeah, I was lucky in learning OS a while back when there were way less features so it was a shallower learning curve.


It's your thread so you can chose to send it off at whichever tangent you see fit 

larry_hawes said:

I derived a part in an important doc and still cannot figure out what I did or what effect it ultimately has on my part - or the original.

OK lets break this down.  The flow is only downstream so there is no upstream change to the original to worry about.

(a) Lets say you open a partstudio and design a single part that happens to be a carboard box.

(b) I open a part studio and design a Coffee Mug. (The song was wrong, we don't need "the air that we breathe and love" we need copious amounts of caffeine.)

(c) You derive my Coffee Mug into your part studio.  This results is your PS containing your un-altered box and also my coffee mug. (Two independent parts)

Things to note:- 
(1) You can edit the mug and it'll have no effect on my original.
(2) And this is the clever bit, I can update my Mug , save a version of the doc and yours stays the same, but shows you an icon to say there has been an update to this part and giving you the choice to update to the new part or leave as the original.
(3) You can derive from the same document if you wish.  

Used sensibly derives are awesome.

Owen S.

larry_hawes

owen_sparks said:

I'm betting that is a Philip Thomas slide  he's very cautious about the pitfalls of bad practice modelling (to his credit).  Derive was introduced long before In Context Edit so ICE does indeed replace its use often, but for simple things you can't beat it. 

larry_hawes said:

And yeah I should learn and become more comfortable with all of OS's features but I get overwhelmed at times with derives and edits in context and multi part and on and on.

Yeah, I was lucky in learning OS a while back when there were way less features so it was a shallower learning curve.


It's your thread so you can chose to send it off at whichever tangent you see fit 

larry_hawes said:

I derived a part in an important doc and still cannot figure out what I did or what effect it ultimately has on my part - or the original.

OK lets break this down.  The flow is only downstream so there is no upstream change to the original to worry about.

(a) Lets say you open a partstudio and design a single part that happens to be a carboard box.

(b) I open a part studio and design a Coffee Mug. (The song was wrong, we don't need "the air that we breathe and love" we need copious amounts of caffeine.)

(c) You derive my Coffee Mug into your part studio.  This results is your PS containing your un-altered box and also my coffee mug. (Two independent parts)

Things to note:- 
(1) You can edit the mug and it'll have no effect on my original.
(2) And this is the clever bit, I can update my Mug , save a version of the doc and yours stays the same, but shows you an icon to say there has been an update to this part and giving you the choice to update to the new part or leave as the original.
(3) You can derive from the same document if you wish.  

Used sensibly derives are awesome.

Owen S.

Thanks Owen, That actually answered a couple questions I had re: derived parts. So I guess it's the persistent link between original and derived parts that gets 'expensive'?

owen_sparks

larry_hawes said:

Thanks Owen, That actually answered a couple questions I had re: derived parts. So I guess it's the persistent link between original and derived parts that gets 'expensive'?

Groovy.

Yes it's the fact that the derive has to go off and rebuild the part studio that serves as the source for the derive.  So in an ideal world that source PS will only contain a single part, preferably modelled about the origin (just so you know where to look for it after you derive it in.)  Once loaded it's done so it's only really the initial document load time that may suffer.  For simple stuff you won't even notice the difference in speed.  

Cheers,
Owen S.

MBartlett21

owen_sparks said:
So in an ideal world that source PS will only contain a single part, preferably modelled about the origin

Or some master sketches, especially if you are working in sheet metal (I try not to do lots of sheet metal in the same part studio. If id do, regen time goes up drastically (!!!))