I uploaded a design to Shapeways for 3D printing. Part of my design will not upload so I asked Shapeways, what’s the problem? They said that part of my design had 0 thickness so it could not be 3D printed. The part that has 0 thickness is a part that I copied and did a negative 1 (-1) scaling to mirror the part. My guess is that the negative numbers makes the part the same as 0 thickness. I there anything I can do fix this??
Albert Drybrae
Exploding the two halves of the hull, and fixing any reversed faces that result, might fix it.
Can you upload your model here? That will make it easier for others to help.
There is a bug that causes -1 scaling to fail in 3d printing. Easiest workaround it to explode it after -1scale and regroup. It will then be recognised correctly.
@Box is that a bug in the STL export in SU? I’ve not encountered it myself, but I’ve hardly printed anything yet from SU2021.
Yes it appears to be in the exporter and has been around since its inclusion rather than the extension version. I have mentioned it many times and they have acknowledged it is a bug but have yet to fix it.
Thanks. I’m sorry that I hadn’t noticed any mention of it, even though I read most of the posts on the forum.
That is new to me too. I’ve never had a problem, but then again, I tend to use “flip along” in lieu of scale -1. The end result is the same is it not? Flip along versus scale -1 ?
Flip and scale -1 are basically the same, but they can be used in different ways, that would be a subject for another time.
The error still happens when you export a flipped object.
You can see here the flipped cube shows Red meaning it won’t print.
@jim4366 if you are using 2017 as your profile suggests then this wouldn’t effect you as you must be using an extension rather than the built in stl exporter that was introduced in later versions.
The bug that Box mentioned does seem to be there, and the work around of exploding that John mentioned does solve the problem. Here’s what the file looks like before and after the exploding work around. In the first half of the video you will see that only the back faces are showing.
The most user friendly workaround is to install the original stl export extension that the team created and use that.
How about users of the Web versions - are they too affected by this? They don’t have the extension option.
Just checked and yes the web version fails too.
Interestingly, if you insert a flipped file into the web version it comes in with reversed faces.
The situation is more interesting than whether the STL has reverse faces or not. The version from the web and from desktop both produce the same issue. The issue gets confusing if you import the STL into SketchUp, because SketchUp does its best to cope, and will show the faces as reversed, which they were not. Viewing the file in Finder, or most other STL tools, will show the problem.
Here is where the problem is:
facet normal 0 -1 -0
outer loop
vertex 10 -10 0
vertex 0 -10 10
vertex 10 -10 10
endloop
endfacet
There is a convention that says that the coordinates of a triangle are listed clockwise as seen from one side, and therefore counterclockwise from the other side. Before there were such things as ‘normals’, 3D programs relied on that to know which was the front or back face.
Normally (pardon the pun) the facet normal and the clockwise-ness of the three coordinates will agree with each other, but in the case where you have negatively scaled something in SketchUp, they don’t.
When they don’t agree, some programs fall back on trusting the order of the vertices, and ignore the normal value. Others trust the normal value. Apparently SolidWorks will use the order of the vertices and still use the normal value to control shading effects.
So, the thing for SketchUp to fix is that when scaling negatively, the order of the vertices should be corrected to match the normals values. In the meantime, exploding does seem to correct things, though you could export as ASCII STL, and manually correct the order of the vertices.
Great. I suppose we can expect a fix any time now, then 
Later today I expect.
Not really (sadly).
Well, now that the bug has been outlined in detail, reproduced, inspected, with a solution for fixing right here in front of us, it might make some sense to address it. Ignoring it isn’t really the right thing to do especially under the subscription model.
What we’ve been told in the past is that the developers have lists of bugs, feature requests, their own ideas for enhancements , etc. and they gather to prioritize items. But they don’t describe the basis of the priority. There are bugs that have been known for years but left untouched.
I looked around for an existing bug, which isn’t an easy thing to do when you’re searching for things like ‘normal’. But, I did find that this exact problem was fixed in SketchUp 3.x, for the export to 3DS case.
The engineer who fixed it doesn’t work at SketchUp anymore, but the QA person does. I will see who could apply the same fix for STL.
