Message Boards Message Boards

8
|
6384 Views
|
5 Replies
|
21 Total Likes
View groups...
Share
Share this post:

Vote here for better support of .stl export

Posted 10 years ago

Mathematica supports Export of to the .stl format used by many 3D printers....up to a point. Recent posts explain that .stl can only take graphics files made up of triangles. The posts provide workarounds for special cases. But the user has no way of knowing what graphics objects can be exported or what workarounds might have a chance of being exportable. When a graphics file is not convertible, the sole information the user receives is "$Failed".

The only way to get a successful export is to monkey around blindly or to acquire a developer-level knowledge of Mathematica. This has been the situation through at least one major release, viz version 10. And it remains the situation in the face of exploding need for 3D printing graphics. Mathematica developers could improve the situation greatly by replacing the "\$Failed" and "Graphics3D contains no data that can be exported to the STL format' by something more informative. A list of graphics constructs that are .stl exportable would be helpful . And naturally a utility that converts non-exportable graphics to exportable ones would be the proper way to address this issue.

Do you know of such a utility within or outside the Wolfram universe?

Is Mathematica support of .stl a priority for you?

POSTED BY: Tom Witten
5 Replies
Posted 5 months ago

3D support appears to have gone in the opposite direction. I have code that ran perfectly well five years ago to output .ply files. Now the same code has odd diagonal artifacts that are not in the data. Instead, I'm using .stl format for export. Code that five and ten years ago ran in reasonable times, now takes: an stl file that has 1.5 million faces took twenty hours to export. One that has six million faces is still running, and I expect it to take 80 to 100 hours. Ten years ago the same program took about eight hours.

POSTED BY: Howard Fink
Posted 10 years ago

With respect, Vitaliy, I ran your code on my I5 laptop, just up to exp = Show . . .

It took 20 minutes, and this just to tessellate a simple solid which was only a composition of rectangular solids -- a trivial job. None of my real applications are so limited. For any meaningful STL export, Mathematica needs a fully functional tessellation capability for solids with curved surfaces. A first step is to be able to handle all the solids which can be generated by Mathematica 3D primitives. But what is really needed is to extend that to all solids defined by closed parametrically defined surfaces.

This does not cover export of solids to modern CAD standard formats such as STEP, IGES, and Parasolid. For this there may well be a restriction requiring the solid to be a composition of accepted primitives. But this needs to be undertaken before WRI claims to be capable of interchange with current standards,

Kind regards,

David

POSTED BY: David Keith

Thank you all, we appreciate your feedback very much! Please continue sharing your thoughts – this is very important to us.

I would like to point out that our intent for the development in this area is obvious. With recent introduction of Geometric Computation we now can do quite neat things. And more things are coming and we do listen to your suggestions.

I’ll give you a simple example of Boolean geometric computation exported to .STL format that is instructive:

R1 = ParametricRegion[{u, v, w}, {{u, 0, 2}, {v, 0, 2}, {w, 0, 2}}];
R2 = ParametricRegion[{u - 1, v + 1,  w - 1}, {{u, 0, 2}, {v, 0, 2}, {w, 0, 2}}];
R = BooleanRegion[\[Not] #1 \[And] #2 &, {R1, R2}];
dr = DiscretizeRegion[R];
exp = Show[BoundaryMesh[TriangulateMesh[dr]]]

enter image description here

And here it is exported to .STL in an alternative viewer (please explore Geometric Computation and try many other things!):

Export["test.stl", exp]

enter image description here

POSTED BY: Vitaliy Kaurov

@David I'm 100% with you. And I confirm the need for Parasolid import and export. Some CAE softwares are based on it, and many have it as an import/export format.

This type of functionalities are typically perfect for intern projects, which should easy the constant updatings that are needed to follow the formats revisions.

Very soon, with the handheld 3D scanners that will come with future revisions of phones and tablets, everybody will be manipulating 3D models, printing things at home after having scanned them, with their phones, in the middle of the street, or integrating into their daily work activity some of the engineering stuff that is currently only available at a high cost, to people that pay the thousands of dollars that cost a scanner, and that carry it around with huge operation manuals... This is going to change the way we register the world, in the same way the everybody has a camera in the pocket has changed the way we take pictures. Just imagine arriving at home and printing your kid, riding a pony, playing the piano, etc.

So, tomorrow, we will need cloud of points processing capability, automatic fitting of primitives into the scanned cloud, importing and exporting capabilities that keep track of the texture information (since that even the first versions of phones and tablets will come with "color" scanning), etc. This means that we need extremely good 3D models import and export, and I can confirm that this is currently not the case (even DXF had text problems not so long ago, and probably still has). We will need surface wrapping algorithms (balloon meshing), to correct gaps on imperfect meshings, or directly on clouds, etc.

To add to this, the impressive geometry functions addition we had on the latest version of Mathematica, to cover the FEM necessities, etc, has approached Mathematica a little closer to the needs of the engineer. And so, we are in need of dynamic rotating pivot point manipulation (to be able to zoom a 3D graphics, and still rotate without getting dizzy), dynamic change of rendering options without resetting the plot definitions (wireframe, hidden lines, shadow casting, etc). etc etc.

@Tom I'm sorry for taking profit from a moment of enthusiasm, going a little outside your initial post, but I think that these topics are inline with the necessity of taking 3D engineering serious (since 3D for enthusiasts is closer than ever). Not having a perfect interaction with ray-tracing capable renderers, or omitting major CAD formats is so 90's...

So, +1 for perfect STL support, and everything that brings engineering topics to the world of Mathematica

(also, these kind of improvements fit well on the new trend of having a more continuous product evolution, which is the same to say: WR, can you please push this kind of updates as soon as they are available, instead of in major releases?)

PS - by the way, does anyone knows if there are projects working on multiple POV cloude of points scanning/filming synchronization? That is, if in the future I have 2 or 3 iPhones 9, scanning a scene at the same time, from multiple angles, will I be able to spin the live action scene looking at a 4th device? The future looks promissing!

POSTED BY: Pedro Fonseca
Posted 10 years ago

+1 from me. I have tried to use Mathematica to generate stl files for use in both FEA (Comsol) and optics (Zemax). Without much success.

I suggest that the issue be expanded to ask for support for CAD files in general. I frequently see claims in WRI literature that Mathematica supports the major CAD formats, such as:

"The Wolfram Language supports import and export of 3D geometry from all standard formats - with its symbolic representation of 3D objects allowing immediate faithful interchange."

But it doesn't. The list of supported 3D CAD formats is really a list of obsolete or very specialized forms. Any such support would include STEP and IGES, and perhaps Parasolid. These are "standard" 3D formats in solids modeling.

POSTED BY: David Keith
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract