0
$\begingroup$

Odd question for everyone, hope it has a distinct answer. I'm often printing bone models derived from CT scans (I work in a hospital) and they often have something on the order of 5 million faces +/-. Now, I know from experience that I can decimate them down to 10-20 % of the original faces and they still pretty much look the same, so I often do that to help my computer run faster. I also know that "GrabCad" (the software for my j750) can handle these face counts and the limiting factor is more so the actual physical print resolution. But it got me curious:

Lets say I was using other software. Lets say more universally available software such as PrusaSlicer or Cura. Now obviously if I'm printing on a Prusa I probably don't need to worry about capturing all the detail from 5 million faces because I doubt I can print that intricately, but lets take the actual printing out of it (and I guess even before it gets to the G-code stage).

Can Cura/PrusaSlicer handle that many faces? Is there a limit? Do files get "dumbed down" at all when they come in? What I'm trying to ask exactly is outside of the G-code and actual printing step, can the software side of things handle something with 10 million faces? 20 million? Is there a limit?

$\endgroup$
6
  • 1
    $\begingroup$ I don't see why there would be any hard limit to the number of faces that can be handled, so long as you're willing to wait for your computer to do the work and there is sufficient memory available. $\endgroup$ – Tom van der Zanden Dec 21 '20 at 21:23
  • 1
    $\begingroup$ I can't answer with a specific figure, but from experience, I can tell you I've crashed three of the more common slicers doing as you describe. Many faces means the program is working at an unusual level and as you've noted, an excessive detail reference. When a windows program is "not responding," one might wait and hope, but as soon as another operation is requested, "not responding" is again expected. $\endgroup$ – fred_dot_u Dec 22 '20 at 1:37
  • 1
    $\begingroup$ I have loaded a ridiculous sized STL one. Like, almost a Gigabite. It was processed within some hour and then took ages to slice ("task unresponsive") $\endgroup$ – Trish Dec 22 '20 at 13:13
  • $\begingroup$ @Trish Got ya. So it sounds like IF there is a limit, its so large that in effect it'll never be an issue $\endgroup$ – Joseph Crozier Dec 22 '20 at 13:19
  • 1
    $\begingroup$ @JosephCrozier the limit is not software but your hardware. $\endgroup$ – Trish Dec 22 '20 at 13:28
1
$\begingroup$

As a software developer and 3D printing enthousiast I can tell you that indeed, like Trish said, the limit is your memory (RAM) and loading/slicing time depends on the cpu power.

RAM: keep an eye on the memory usage in the task manager/performance/memory tab. When it reaches the top of the graph, the application will suddenly crash and disappear.

CPU: The application (cura/slicer/prusaslicer) can become "not responsive". This does not always mean that the process hangs. It just means that the cpu is very busy and the program is not reporting the progress to windows. Most probably the application will recover from this if you just choose to wait.

Files do not get dumbed down when imported afaik in cura. They are shown exactly like in the STL. Don't know about other software though, but I doubt this happens.

Like you noted, this has nothing to do with Gcode, which is loaded serially.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.