Ad-hoc slice repair

Printing my model today I ran into the issue seen below. A single layer got one of its poly’s “inverted”. Layer 697 is fine, layer 698 is messed up, then layer 699 is fine again. I’m not sure how forgiving the machine is to faults like this. Preform didn’t warn about it and thinks the print is good to go.

I have no idea how to find and correct this in the modeling software I used (Meshmixer). When I zoom in on the area and inspect it I can’t see anything discernible that would account for the artifact in my exported STL. I’m wondering if it might have been introduced during Preform’s slicing process.

I’ve seen a friend have this problem a lot with high-res models that he downloads from the internet then scales down.

The same issue occurred in two other places in my file at different layers. Since there’s so few instances it would be totally manageable to fix by hand, if only I had the tooling. e.g. If I could just grab the errant vertices in that layer and reposition them life would be great.

I realize this may not be an easy thing to address, but it would be the kind of practical tooling that helps you get a job done when you’re in the trenches and don’t have time or tools to fix the problem at its source.

Thanks for considering it!

this is caused by one of several possible issues affecting topology in the model.

3D models in polygonal geometry have two basic parameters- geometry and topology.

Geometry is the points in space that are actually quantified as to location. A point cloud is pure geometry.
Topology is a list of which point is connected to which other points and in what direction.

In the picture you post it LOOKS like the slice shows a point on the outer surface that is connected to two points on the inner surface.
Because these ‘segments’ cross other boundaries- the result is an anomalous boolean void- as well as a misplaced boolean solid- like when a path drawn in Illustrator crosses over itself.

When it occurs on only one layer, like this, it usually means that the topology of the model has a missing or faulty connection to the adjacent point in the geometry. In surface modeling it can be because two adjacent surfaces are not “stitched” along one border.

other causes of poor geometry can be flipped normals on one or more polygons, which is, again, an issue of topology-
for 2 polygons to be mathematically readable as a contiguous surface, BOTH vertices describing the boundary must be connected in BOTH directions… and what defines a ‘solid’ in 3D space is when ALL the vertices are connected in both directions with all their Normals facing in the same way. OUT From the enclosed volume.

With Just one of the pairs of verticies having only ONE connection in one direction- it will RENDER fine… but mathematically- it has a hole.

This kind of problem can also result from exporting a model composed of separate overlapping surfaces as a single STL model- which treats ALL geometry in a given file as a single model- ergo creating boolean reversals where originally separate solid surfaces cross one another. Solve that by MERGING all separate objects in a modeling space into a single model prior to export.

Another common source of loss of solidity is when folks model in subD- which is four point geometry- each polygon has four points- and it is not hard for one of those points to get moved out of plane with the other 3. this creates an “angle” in the polygon the points define… but each polygon can have only 1 normal. This is where you sometimes see little triangular holes in rendered models… that hole violated solidity. And its why Triangulating a 4 point model will solve these issues., because 3 points always define a plane with a single, correct normal.

if the fault is confined to a single layer like this… it might print- but the laser will TRY to crate a zero thickness spot and void in the model as the layer shows- and it will try to print the added fill, externally and internally that is shown.
This unsupported and anomalous single layer will not be connected to the rest of the layers and may end up stuck to the tank floor- or floating free in the resin and cause other issues.
Stuck to the tank floor it could result in the model above this flange not printing at all.

Check the model in modeling software- use the Object or Model Doctor or “Verification” tool to see if it can repair the model.

Some folks get a good result by simply opening such models in SolidWorks- where it will often detect bad topology and repair the model on import.

I don’t know if meshmixer has a good model doctor function…

but you see these kinds of issues more and more because fewer and fewer people using modelling software understand the actual principles by which it works, and therefore generate lots of models that render fine- but do not describe correct watertight solids.

When running a CNC mill to, say, cut an injection mold tool out of a block of steel- the solidity of a surface is immaterial… the software simply drives the tool tip to trace a surface in space. But for 3D printers, they have to know where the resin should go, and where it should not… so the geometry needs to describe a mathematical solid.

When Preform ‘slices’ a model it essentially derives series of cross sectional profiles on the fly.

When it comes to a point in space that is NOT connected to another point in space ( Coinciding with the slice line ) It will look for another point that is Not connected to anything in one direction- and it will create a connection, resulting in these anomalous boolean reversals on a single layer…

Since this is an artifact of slicing bag topology, You can try orienting the model slightly differently to see if you get a better slice result… but a model with really bad topology might show errors any way you slice it.

lots of bad topology problems actually occur when converting from one file type to another- or on export or import from one modeling app to another. Not all apps export models using the same parameters… and lots of apps require you to check the right options in order to export a model some other app might correctly import.

This complexity is why we use Freefrom. its costly- but it makes ANY file solid… one way or another.

When you exported your model out did you choose Triangles only? That almost looks like an n-sided export that will almost always import poorly.

If the model is made of multiple meshes then use the obj export from your program, make sure parts are slightly overlapped and Pre-form should be able to slice it fine.