Feature Request: Additional Z-axis Resolution

[aaron1138]

Request to be able to slice in single digit um, e.g. increments of 0.001mm. I'm aware this massively increases the chances of hitting a defect in the model and getting a blank scanline. Another helpful feature would be a notification that slicing likely struck a hole in the mesh.

I ran across this project after some discussions with Cubiq / Matteo. I have 3D / vertical AA working with some UVTools scripts linked below in the form of "build your own super sampler" approach which involves slicing at higher than print Z-axis resolution as well as blending along Z with "out of box" sampling layers above and below along with significant grayscale remapping. Towards native AA and / or 3D AA in mslicer, let me know and I would be happy to go over more specifics.

Scripts:
https://github.com/aaron1138/UVTools-Scripts
Output examples:
https://imgur.com/a/YH2rJ6e
These are at 5x out of box layers -- so 40x 5um layers to make each 40um layer, some vertical detail loss. I have 3x working ok, but I am working on a grayscale LUT calibration and tools towards getting to 2-2.5 layers of vertical blending in each layer.

[connorslade]

Right now you can enter small values (like 1μm) into the slice height field, and it will slice successfully, but the thousandths place is not currently displayed in the UI, so I can fix that. Although the outputs will probably be multiple gigabytes.

For detecting holes in the mesh, what exactly do you mean by this? Have you noticed mslicer giving incorrect results for certain models? (will likely manifest as horizontal lines of inverted pixels) Because any topological holes in the meshes should be detected and met with a 'Non-manifold mesh warning'.

I have not yet done much work on antialiasing in mslicer since I want to implement it efficiently without having to decode every layer into a bitmap image. I think this should be possible, but just haven't gotten around to figuring out an algorithm.

The grayscale LUT thing is interesting. Did you determine the values seen in your scripts repo experimentally? Also, I'm curious how long it take you to run the whole process to get your super sampled 3d antialiasing?

[aaron1138]

Typing in small values works, not sure why I didn't try that, thanks.

I usually slice at 5um in Prusa Slicer which provides enough resolution for enough grayscale to resample. One advantage there is Prusa Slicer does pixel occupancy AA, so the grayscale values are proportional to the XY space of the pixel covered by the intersecting edge of a triangle in 2D. Unfortunately, it only works at the singular Z interval of the layer, otherwise it would be doing 3D / volumetric AA. I have a 9950X3D, so a 50mm tall plate of 12k resolution prints takes about 3-4 minutes to slice + convert and 5-6 minutes to collapse down from 10k to 1250 layers at 40um with LUT application in my current UVTools script. Most reasonably modern gaming PCs though I would expect 15-30 minutes. I also save intermediate steps for experimental prints (e.g. collapsed to 1250 layers of linear grayscale with no LUT applied for testing different LUTs - applying a LUT takes 2 minutes to open and apply).

As far as holes in the mesh, I tested a known "bad" mesh which Satellite and Prusa Slicer will both flag as having holes / not watertight. While there was a warning about normals on load, it did not flag as any other errors. They're very small mesh defects. Prusa Slicer flags the mesh as needing repair, Chitubox will slice it successfully without issue as that is probably one of their better developed features needed for their professional customers (e.g. dentistry).

Based on the inverted pixel streak, would I be correct assuming a form of raycasting approach which is counting intersections as it fires along the X axis at layer height Z? If so, implementing super sampling might look roughly like this:

1. Fire rays at each of the four YZ corners of the voxel when viewed along X. As the results are shared across voxels and layers for corners, the additional number of base rays is small. Alternately, firing a ray down the YZ middle of the voxel should also work reasonably well.
2. Anywhere there are hits on the model, fire additional rays in a Hammersley, N-queens or similar pattern (perturbations on the Y & Z voxel coordinates along X).
3. Divide the number of hits by rays fired at that pixel and that is the approximation of occupancy.

The LUTs I am using are derived experimentally, but I got a bit of a start with the vertical voxel growth curves here: https://www.youtube.com/watch?v=PsK7An7ymYk&t=2105s

The LUTs change substantially per resin and right now I am working on a way other users could print a set of test parts with various grayscale curves applied and then grade them to select the best curve. I have a script which applies multiple LUTs to a test part in UVTools and makes a copy on the build plate for each LUT with labels and such.

I've also been experimenting with "2D" LUTs which look at the contour at the grayscale pixel and pick the 1D 0-255 LUT from a 2D table based on the local approximate angle (this is using Sobel / Scharr magnitudes).

One significant challenge is that each resin has different scattering properties and that in resin printing at modern 8/12/16k resolutions, the light from a single pixel actually spreads out by several pixels (actually I am finding many more than several with some experiments). The energy density and gradients are wider than you might expect.

[connorslade]

In the latest development build (which I would recommend using for now anyway due to more robust slicing and better user experience) I have made it so the slice height slicer uses metric prefixes, so you can just set it to 1μm, and it won't cut off the value. You can download from the latest build on GitHub Actions.

While there was a warning about normals on load, it did not flag as any other errors.

The non-manifold mesh detection was added after the last release, so again I would recommend using the development build. I know that some slicers are able to work with invalid meshes, but I think that's kinda beyond the scope of this project.

Based on the inverted pixel streak, would I be correct assuming a form of raycasting approach which is counting intersections as it fires along the X axis at layer height Z?

Not exactly. The slicing code itself is very short and well documented so you can take a look if you want. The way it works is by (for every layer) intersecting all the meshes with a plane. In non-degenerative cases, triangle-plane intersections will always fail or return two points, which can be interpreted as a line segment. This means the mesh-plane intersection will effectively return a set of polygons. The horizontal lines come in because I use the scan line polygon fill algorithm which works really well in run length encoding, which most msla formats use for layer encoding.

I really want to improve the antialiasing implementation and have some ideas, but haven't yet gotten around to figuring out all the details. I have also been working on support structure generation and while working on that implemented a function that allows calculating the distance field of a mesh, which could be used for 3D AA. I'm not sure if that would really be fast enough compared to doing a layer-wise Gaussian blur, so still need to do some experimentation. But it should be faster than the method you suggested with a bunch of ray casts, since it's based on a 'Closest Point on Triangle to Point' function.

The LUTs I am using are derived experimentally, but I got a bit of a start with the vertical voxel growth curves here

I hadn't really thought about rescaling the grayscale values with the voxel growth curves before this, but that makes a lot of sense and I think I want to add it as a post-processing effect. Although it will need some way to calibrate the mapping for a specific setup.

[aaron1138]

Ah, your 2D polygon intersection is a similar base method used in Prusa Slicer's AGG renderer. Then as I recall they calculate 2D occupancy by the polygon intersection with the pixel edges for grayscale mapping. Combining that with super sampling by internally slicing at a vertical multiplier ratio (e.g. 10 samples along Z for each layer) would be quite a bit faster than 2D post processing especially if there is a fast way to stack pixel rows. Thinking further about the level you have optimized without AA, you could slice at higher internal XY resolution as well as along Z and then weight those results into AA grayscale rather than an analytic occupancy. Additional XY resolution is less relevant due to the exposure and curing physics of resin.

I looked at SDFs previously, but the method is difficult with the so-so mesh quality and self-intersections common across the resin printing sources. I should note, I am not a programmer, It might be reasonable if you have a shell separating function as most people tend towards pre-supported models when possible. Most pre-supported models are 1 shell for the object and hundreds for the supports. There are a few bits of utility separating shells as well as far as not wasting AA on supports as well as potential around differential exposure for supports versus model (whether multiple exposure or grayscale offset). For my main test prints, I actually keep a copy of slices of just the supports as certain 2D / 2.5D manipulations tend to erode supports enough to cause printing problems.

As for blurs, I have found box blur is a bit easier to work with as grayscale then analytically represents volume / height when super sampling. I had issues with Gaussian blur skewing the grayscale remapping as it's very sensitive. Gaussian might work better with a much larger super sampling set, especially distance fields as then there is the possibility of integrating light scattering / point spread function and in turn grayscale which is more related to energy / power needed to create a feature at the edge of the model versus deep inside.

I hadn't really thought about rescaling the grayscale values with the voxel growth curves before this, but that makes a lot of sense and I think I want to add it as a post-processing effect. Although it will need some way to calibrate the mapping for a specific setup.

I alluded to this earlier, but the point spread / light scattering is quite large relative to the dimensions of a pixel. This is a significant portion of why the two methods I am aware of for 3D / vertical AA require so much vertical blur / "sampling out of box". A distance field which is then pre-compensated for light scatter should reduce the amount of vertical blurring required for AA. Below is one example approach of grayscale pre-compensation designed to maintain wall dimensionality.

This is grayscale inside the print to reduce concavity and cross-layer curing. These are the top right swatches from Phrozen XP finder at the same exposure. First is the normal slice, then the same print and exposure (next to it on the build plate) with an interior grayscale script applied. Grayscale values are a 240/220/220/230 sandwich and 255 white at the interior and exterior edges as well as normal white/255 the infill. For reference with panel gamma ~3 220 is ~64%, 230 ~ 75%, and 240 ~82% energy.

Images

[connorslade]

I finally got around to implementing 3D antialiasing (#31) and ended up doing it similar to how you suggested, by slicing to a higher resolution internally then downsampling. It should be a lot faster than running as a post-processing step since it downsamples the RLE encoded data immediately after slicing each row / layer. You can try it in the latest development builds.

I still need to figure out the best way to add exposure remapping in a user-friendly way. I'd appreciate your feedback on the AA and the best way to measure / import the remapping LUT / curve. Also can you explain the vertical blur that you mentioned is?