STL plugin

[jason1025]

The irony of having a modeling program with infinite resolution is that its stl export is lower resolution than any of its competitors.

 

Its unfortunate because Animation master could if presented / marketed the right way could have a second wind because of the the 3d printer revolution. within 10 years 20% or more of hose holds could have a 3D printer.

 

The bottleneck right now other than price is lack of easy to use 3D modeling software. But in our case we have the software and know how to use it but we cant get a high resolution stl file to the printer.

 

Most people are using google sketchup, this program takes about 8 minutes to create a wine glass, as seen here

 

 

As you can see AM could have a huge market here and should approach makerbot industries to form a strategic partnership.

On the left is the highest AM can export from the stl plugin. On the right is sketch up

 

You be the judge.

 

Please dont comment and say that the 3d printer does not need that kind of resolution because the proof is in the models it prints and I can tell you and show you it does need high resolution.

 

We are programmed to model with as few of splines as possible in AM, the problem is if you do this the stl export is so low res its useless. The only work around currently is to use an unreasonable amount of splines. If someone could just update the stl export plugin from a max of 64 to a max of 1028 we would blow away the competition in terms of ease of use and resolution.

[largento]

I'm no polygoner, but I believe you'd take an A:M model into one of the others and apply a subdivision command that would create the resolution for you.

 

Can't wait until my hose hold gets a 3D printer.

[robcat2075]

Now a v18 feature request

 

 

I think the subdiv will need to happen in A:M before export because another app will interpret A:M's meshes as straight line edges between CPs rather than still-curved splines when it tries to do its own subdiv.

 

 

On the left is the highest AM can export from the stl plugin. On the right is sketch up

 

I don't see anything.

[thefreshestever]

doesn´t the split-patch plug-in work here? you would just make a copy of your spline-efficient model, apply split-patch several times, and then export it.. shouldn´t be that hard to modify the export plug-in so you could define the number of splits before the actual export...

 

regarding the wine glass in sketchup, i guess it could be done in less than 8 minutes, but it still seems awfully complicated

[jakerupert]

How about doing a highres obj export and do the fixes and stl in meshlab.

It is also free, I believe....

[robcat2075]

doesn´t the split-patch plug-in work here?

 

I tested split patch for this. Unfortunately SplitPatch doesn't take into account the need to adjust the biases as CPs are added to a spline. You do get a denser mesh but it doesn't have the exact shape of the original.

 

I also tried exporting to PLY to use its subdiv ability but what you import back in has many broken splines that would need to be manually rewelded back together.

 

I think just adding more subdivisions to STL should be a feasible thing if Steffen has time.

[Mechadelphia]

Now a v18 feature request

 

I tried following that link while logged into AM Reports but got an "Access Denied" page.

 

Is that link a priviate request where only certain people can view it?

[robcat2075]

I tried following that link while logged into AM Reports but got an "Access Denied" page.

 

Is that link a priviate request where only certain people can view it?

 

It's possible that only people beta testing v18 right now can see those so far.

 

Basically, I described the problem and suggested adding 1024 and 4096 subdivisions as options to STL.

[jason1025]

Now a v18 feature request

 

 

I think the subdiv will need to happen in A:M before export because another app will interpret A:M's meshes as straight line edges between CPs rather than still-curved splines when it tries to do its own subdiv.

 

 

On the left is the highest AM can export from the stl plugin. On the right is sketch up

 

I don't see anything.

 

 

I am denied from V18

[jason1025]

doesn´t the split-patch plug-in work here? you would just make a copy of your spline-efficient model, apply split-patch several times, and then export it.. shouldn´t be that hard to modify the export plug-in so you could define the number of splits before the actual export...

 

regarding the wine glass in sketchup, i guess it could be done in less than 8 minutes, but it still seems awfully complicated

 

when I applied the split path the model got all lumpy

[jason1025]

I tried following that link while logged into AM Reports but got an "Access Denied" page.

 

Is that link a priviate request where only certain people can view it?

 

It's possible that only people beta testing v18 right now can see those so far.

 

Basically, I described the problem and suggested adding 1024 and 4096 subdivisions as options to STL.

 

 

great thank you.

[Fuchur]

I tried following that link while logged into AM Reports but got an "Access Denied" page.

 

Is that link a priviate request where only certain people can view it?

 

It's possible that only people beta testing v18 right now can see those so far.

 

Basically, I described the problem and suggested adding 1024 and 4096 subdivisions as options to STL.

 

 

great thank you.

 

Steffen already plans to insert 256 subdivisions for v18.

That should be enugh for anything to be printed. The value in A:M seems to be connected to the realtime views too.

Till this happens use 64 and just increase the values for lath etc. Before exporting.

 

See u

*Fuchur*

[robcat2075]

Here's a demo of the new subdivs. Clockwise from top left, original spline model, STL 64 (8x8), STL 1024 (32x32), STL 4096 (64x64)

 

 

As The Donald would say, "Your files are gonna be... HUGE!"

[jason1025]

256 will not cut it.

 

For example: If you want to a displacement map for text on a model your printing. 256 will not be enough. A minimum in my opinion 2048.

[robcat2075]

I just tried a displacement map of some text. It is definitely exported in the mesh but for some reason it doesn't shade like it is there in render.

[jason1025]

Why do you suppose there is difficultly exporting to 2048 resolution?

 

We boast how am is resolution independent aka, high resolution so I do not understand the logic in constraining the resolution on output? Large file sizes are not an issue. We live in the year 2013 not 1995.

 

The competitors do not have a problem exporting high resolution. I am successfully printing 0.07mm layers on my 3d printer. 0.10mm is a sheet of paper for example. You would think the real world would be the bottle neck or limit.But no, the limit of resolution is my Animation masters ability to export a high res stl file.

 

Its embarrassing when my none technical wife asks me why the models created from Am look all funcky and the models printed from sketchup a free software look all smooth.

 

I bite my knuckles and say we are working on it.

 

 

So why am I modeling with AM. Am allows you to model organic objects or curved objects better than any package I have played with.

 

So Gerald my best friend and Steffen please consider 2048

[Fuchur]

2048 can not be used, since it is not possible to reach that number with 4ⁿ:

4⁰ = 1

4¹ = 4

4² = 16

4³ = 64

4⁴ = 256

4⁵ = 1024

4⁶ = 4096

4⁷ = 16384

4⁸ = 65536

...

 

In the latest v18 Steffen inserted 1024 and 4096 as options.

But you should not underestimate large filesizes... It is not really the filesize but what is resulting of it.

> Exporting with 2048 instead of 16 > much longer export times. ("A:M is no longer responding...")

> Larger filesize / more polygones > longer slicing-times for Makerware.

> Better resolution while printing > much longer printing times (especially annoying if you are trying to test something out, etc.)

 

So all in all it just takes hours more to do that all together... It depends on you if you've got these hours or not.

I for instance am rarely printing at 0.1mm layerheight (or smaller... some people seem to be able to print at 0.04mm with the Rep2) because it just takes too much time.

In general I use 0.2mm because for most stuff that is enough and it prints twice as fast.

 

I think it is more or less not a big deal for Steffen to insert anything that is accessable by (4ⁿ) there, since it will just be an additional iteration...

When 256 was on the table, Steffen had run into a problem with the exporter splitting the patches in a wrong way. (that is why I was sceptical about anything even above that... it produced bad meshes)

I think he has found a way to fix that (otherwise there would not be the options 1024 and 4096 available), so like that it is no longer a bigger problem.

 

Till v18 is out, you can just increase the resolution while modelling. Using for instance 24 or even 32 lath-intersections instead of 4 or 8 should handle most problems you are facing there. In future it will be easier because with 4096 you can really even use 4 lath-intersection (I tend to use at least 8, but even 4 should be doable).

 

See you

*Fuhcur*

[robcat2075]

I tried putting the new STL plugin into v17 but it didn't work, so you'll just have to wait a few weeks until v18 rolls out.

 

But if you look at the picture above, both 1024 and 4096 work pretty well. I don't think you'll need more or 2048 in between.

[pixelplucker]

Jason is right when exporting out any geometry with displacement maps 256 is just too course. Global nth subdivisions will generally make larger files than necessary. AM does it's subdivsion based on patches rather than groups or angles which also can pose a problem if a displacement map isn't used on evenly tesselated surface, the map will vary in resolution on export so you need to keep that in mind.

 

Not sure if it is possible to use world based resolution to determine divisions instead of per patch?

 

Maybe divide displacements based on material groups?

[robcat2075]

Pixelplucker... what's making the waffle look in those images?

[Fuchur]

Jason is right when exporting out any geometry with displacement maps 256 is just too course. Global nth subdivisions will generally make larger files than necessary. AM does it's subdivsion based on patches rather than groups or angles which also can pose a problem if a displacement map isn't used on evenly tesselated surface, the map will vary in resolution on export so you need to keep that in mind.

 

Not sure if it is possible to use world based resolution to determine divisions instead of per patch?

 

Maybe divide displacements based on material groups?

 

I did not think of a displacementmap... yes if you use that it is not enough. I thought of normal geometry like a lathed cylinder or something like that.

 

See you

*Fuchur*

[robcat2075]

Here's an oddity. This may be a problem with "prop" rendering rather than STL itself

 

I put a map with some text on a torus and exported it to 4096 with "apply displacement to geometry", then imported it back in as a prop.

 

The map appears to be properly converted and the detail looks to be adequate but the raised surfaces don't' shade right in realtime or in render

 

[pixelplucker]

I used my knurl bump map for the displacement. Something I had to make for some tool grips a while back.

 

For 3d printing, most printers even the best out there can't hold the tiny tiny details simply because the feature size isn't there. Mainly because they are built at best .001" layer thickness, most at .004". This sounds pretty thin but it isn't. 2048 should be over kill. Most geometry should print fine at 64, especially those that use fdm like Makerbots.

 

What would be nice it the Variable feature that we have in the obj exporter. If that was added to the stl along with a limit to it won't tessellate more than what we check off. Big trick is how that would handle displacement maps if those are determining the details over a series of patches and not by angle.

[jason1025]

Good to know Gerald thanks

[jason1025]

DO we have apost describing any new features in V18 ?? Or is it a surprise?

 

The only new feature I heard of is the auto five point patch option so you dont have to manually make 5 point patches anymore.

[robcat2075]

DO we have apost describing any new features in V18 ??

 

Not yet. I don't think any particular feature is certain yet.

[robcat2075]

Here's a torture test of 4096 subdivision. Small text on large patches...

 

The top model is just two patches with a displacement map applied to create "Raised Text"

 

The middle is the STL export of the top model, re-imported into a model (not as a prop). 16384 triangle faces.

 

The bottom is the same, but in shaded view.

 

 

 

If there were more patches there to subdivide, the result would probably be smoother.

[jason1025]

Yes that is torture

 

thank you

[3DArtZ]

I've had hundreds (I initially wrote thousands but it hasnt been that many yet lol) of models sent to rapid prototyping machines that have originated in A:M. I don't think I would be comfortable going straight from A:M to printing as something always gets lost or messed up when doing an export.

so I would use the dxf export option and import to a poly sub d modeller and clean it up, if needed.

 

Mike Fitz

www.3dartz.com

[pixelplucker]

I always check the stl in another program before printing no matter what program I generate the file in. STL Aurora is nice and free and for those that have Unwrap 3d it can preview stl files as well as do minor corrections such as weld close points, correct normals, orientation and scale.