# Changing Plot order for 3D printing

Alright, I got a my first 3D print done of a pseudosphere using parametric plot and a deflated sphere using a contour plot, but when I try

ParametricPlot3D[
{Cos[v]*(3 - u) + .25*Sin[4 u],
Sin[v]*(3 - u) + .25 Sin[4 u],
u},
{u, 6, 13}, {v, 6, 13},
PlotStyle -> {Thickness[.3], FaceForm[Yellow, Blue]},
PlotPoints -> {50, 50}, MaxRecursion -> 0, Mesh -> All]


it gives an error about triangulation self-intersects. I do not have the exact error code because I'm not in charge of the MakerBot. It makes the first round and then stops.

I noticed that the estimated time was 50 times longer than it took for that first loop. Is there a way to fix that, and maybe a changing plotting order would be more machine friendly?

-
You mean something is wrong when you try to print it with MakerBot? –  xzczd Feb 17 '14 at 7:07
Yes, please provide more details, especially the way you exported and post-processed the plot data. –  Yves Klett Feb 17 '14 at 8:33
Closer inspection shows that your parametrization is generating a huge overlap which is most likely the reason for self-intersection. You need to choose v very carefully to generate a closed volume. –  Yves Klett Feb 17 '14 at 9:03

I guess I know what you've encountered. The model doesn't print correctly though it looks OK in Mathematica, right? Specifically speaking, nothing seems to be wrong when you plot the object in Mathematica:

ParametricPlot3D[{Cos[v]*(3 - u) + .25*Sin[4 u], Sin[v]*(3 - u) + .25 Sin[4 u], u},
{u, 6, 13}, {v, 6, 13}, PlotStyle -> {Thickness[.3], FaceForm[Yellow, Blue]}, Mesh -> None]


(Notice I've changed the options a little to show that Mesh doesn't influence the quality of the object at all, while PlotPoints do influence the quality but it's not the main issue in this case. )

And it still looks good after you export the object to a STL file and open it with your MakerWare:

But you'll find it fragmented as soon as you export it to a X3G file if you select Preview before printing:

I encountered similar issue several days ago. The reason for this error is probably mentioned here, you can have a look. (To be honest, I myself haven't fully understand it 囧. ) And after some communication with Makerbot Support, I think I know how to fix it now.

The easiest tool is this one:

http://cloud.netfabb.com/

Just upload your STL file and it'll be repaired automatically. This tool seems to be enough for your model, according to the preview:

Another choice is the meshmixer:

http://www.meshmixer.com/

This tool is harder to use, and I don't know how to repair your model with it right now. (According to my test, Analysis -> Inspector -> Auto Repair All is enough for many cases, but sadly this doesn't work for your specific model. )

So long I haven't found a way to repair models with Mathematica only.

Edit 1

OK… Yves Klett has found the way to repair your model with Mathematica in the comment above: just change {v, 6, 13} to {v, 0, 2 Pi} and the defect in the preview disappears.

Edit 2

I've figured out how to fix the model with meshmixer. What you need is just Edit -> Make Solid -> (Modify the settings if you like) -> Accept:

This time I tried to print it:

……At least the defect disappeared.

-
Did you mean {v, 6, 13} to {v, 0, 2 Pi}? –  Yves Klett Feb 17 '14 at 10:15
@YvesKlett Yeah, fixed, thanks for pointing out! –  xzczd Feb 17 '14 at 10:16
Thanks for pointing out the actual values and the links for mesh repair. The whole area is still a minefield and repairing complex models sometimes a true horror. –  Yves Klett Feb 17 '14 at 10:20
That is exactly good then. And yes, it is a nightmare. Engineering mathematics is a growing field, so I see hope. –  Teg Feb 17 '14 at 11:18
@Teg Thanks for accepting, well, in fact you can wait for 24 hours or even more time before accepting an answer so your question may attract more and better answers :) –  xzczd Feb 17 '14 at 11:26