Is island size a realistic representation of risk of print failure?

[klauskopec]

Preface: it might be, that my understanding of island size calculation is wrong, so please take this with a grain of salt until confirmed or feel free to correct me.

I (and I assume others) take island size as a sort of indicator for the risk of not supporting that island. Is this a reasonable approach? It seems like that's the intended use, given that you can configure UVtools to only list islands above a certain size threshold.

Here's why I question that approach: My current assumption/understanding is that island size is calculated as the pixels in the smallest rectangle comprising all island pixels on the lowest layer of that island (so only 1 layer is included). It seems to me that a better measure of the risk of leaving an island unsupported would be to include the pixels in all the layers above that island in the area (then: volume). Obviously, adding those pixels of higher layers would need to stop as soon as adjacent pixels on a higher layer are considered "supported" again.

This would avoid the issue of setting the minimum reported island to, e.g., 5px (to avoid going insane ;)) and then missing a 2x2 pixel island, which will cause issues for the next N layers because they depend on me supporting that 2x2 px island.

Are my thoughts on this correct or did I misinterpret something around what island size is and how to benefit from it?

[sn4k3]

I (and I assume others) take island size as a sort of indicator for the risk of not supporting that island. Is this a reasonable approach?

Yes, the larger the island the worse the problem is on that layer. Still, a small island can also lead to large failure if that island is about to support a big increasing mass in Z.
You can change the default order to sort by area instead.

It seems like that's the intended use, given that you can configure UVtools to only list islands above a certain size threshold.

I'm not big fan of hide information, is up to user, as told small island can lead to big failure too, user should always check and decide whatever to ignore, remove or fix. Hide as it is now is not recommended.

My current assumption/understanding is that island size is calculated as the pixels in the smallest rectangle comprising all island pixels on the lowest layer of that island (so only 1 layer is included).

Area is given by that layer blob, that is the sum of all island pixels only in that area and layer. (Fast)

It seems to me that a better measure of the risk of leaving an island unsupported would be to include the pixels in all the layers above that island in the area (then: volume). Obviously, adding those pixels of higher layers would need to stop as soon as adjacent pixels on a higher layer are considered "supported" again.
This would avoid the issue of setting the minimum reported island to, e.g., 5px (to avoid going insane ;)) and then missing a 2x2 pixel island, which will cause issues for the next N layers because they depend on me supporting that 2x2 px island.

UVtools does not calculate risk, it just show some numbers that aren't related to risk, is then up to user to evaluate.
Without doubt that would be the most correct approach, I aready considered, however by doing so it will increase alot the processing time, ie, same or worse than resin traps time (that shows you real area/volume of the problem). And the problem here is eficiency/time, some users dislike the time resin trap takes to compute and that can be a problem if made same way in islands.

The current implementation is fast and can provide "live" updates as you edit layers, however doing so for the other method would be time-expensive

[klauskopec]

Thanks, that explanation is really appreciated! I fully understand your approach, the speed consideration is obviously important.

[Oem42]

Would it be hard to implement? I wouldnt mind a bit of extra time spent here when were talking about hours long prints

Also is there anyway to offload some of these calculations onto a gpu? Cant imagine many 3d printing people wouldnt also have a card in their machine

[sn4k3]

Would it be hard to implement?

Currently yes.

I wouldn't mind a bit of extra time spent here when were talking about hours long prints

People often say that but, in the end, they will not like the expensive operation which is way slower. More than resin traps.
Also, that imply the lose the feature of bad connections since contours does not have the 4-connected feature.

Also is there any way to offload some of these calculations onto a gpu? Can't imagine many 3d printing people wouldnt also have a card in their machine

Yes, but the GPU implementation at OpenCV is not efficient and shows way worse results when using GPU. The solution is to write the raw GPU kernels myself which I never did nor have the expertise to implement the algorithms.

I can in the future try such detection (optional) if I found an efficient way to do it.

[klauskopec]

I agree! If this is ever implemented, it should definitely be optional for those who don't like the added time.