Optimize FillTpmsFK using optimized MarchingSquares from #10747. #2066

New Issue

MrUnknownDE · 2026-04-05T23:11:18+02:00

MrUnknownDE commented

2026-04-05 23:11:18 +02:00

Originally created by @dbaarda on 9/26/2025

Change FillTpmsFK.cpp to use MarchingSquares.hpp.

This is still a work in progress, but it does seem to work fine, and I thought I'd put this up there for people to have a play with. I also have a few questions because I'm not 100% familiar with the rest of the codebase and I'm going to use the review of this to figure a few things out.

This builds on #10747 which simplified and significantly optimized MarchingSquares.hpp by replacing most of FillTpmsFK.cpp's implementation to just use that marching squares implementation instead of re-implementing it's own.

I don't yet have any solid speed comparisons but it feels a bit subjectively faster, though I think that most of the delay in previewing the slicing results is not in the fill-generation so it's a bit hard to tell. I don't know if there are any tests/benchmarks/etc that I could use for testing this, but I'm probably going to add some to this PR at some point.

Even if this doesn't give a significant speed-up, it does significantly simplify the code and make it easier to re-use for other equation based fill-patterns. This could re-implement gyroid or TpmsD with about 5 lines of C code to inherit from ScalarField and redefine the float get_scalar(coordf_t x, coordf_t y, coordf_t z) function with the appropriate equation.

I don't think it would be faster than the current gyroid or TpmsD fills though, since they directly generate a single line using the equation and then just copy and shift it. However, it might not be much slower and it would simplify the code to do them all the same way.

But the main reason I'm doing this is this can be used to implement far more complicated fills that can't really be implemented any other way. In particular I'm working towards a gyroid fill that dynamically varies it's density based on how close it is to the walls.

I have a bunch of questions about some of the other bits that I'll post as comments against the review-diff.

Screenshots/Recordings/Graphs

I'll add some when I get there... but so far the results look identical to the previous implementation even when I zoom in close.

Tests

*Originally created by @dbaarda on 9/26/2025* # Change FillTpmsFK.cpp to use MarchingSquares.hpp. This is still a work in progress, but it does seem to work fine, and I thought I'd put this up there for people to have a play with. I also have a few questions because I'm not 100% familiar with the rest of the codebase and I'm going to use the review of this to figure a few things out. This builds on #10747 which simplified and significantly optimized MarchingSquares.hpp by replacing most of FillTpmsFK.cpp's implementation to just use that marching squares implementation instead of re-implementing it's own. I don't yet have any solid speed comparisons but it feels a bit subjectively faster, though I think that most of the delay in previewing the slicing results is not in the fill-generation so it's a bit hard to tell. I don't know if there are any tests/benchmarks/etc that I could use for testing this, but I'm probably going to add some to this PR at some point. Even if this doesn't give a significant speed-up, it does significantly simplify the code and make it easier to re-use for other equation based fill-patterns. This could re-implement gyroid or TpmsD with about 5 lines of C code to inherit from `ScalarField` and redefine the `float get_scalar(coordf_t x, coordf_t y, coordf_t z)` function with the appropriate equation. I don't think it would be faster than the current gyroid or TpmsD fills though, since they directly generate a single line using the equation and then just copy and shift it. However, it might not be much slower and it would simplify the code to do them all the same way. But the main reason I'm doing this is this can be used to implement far more complicated fills that can't really be implemented any other way. In particular I'm working towards a gyroid fill that dynamically varies it's density based on how close it is to the walls. I have a bunch of questions about some of the other bits that I'll post as comments against the review-diff. # Screenshots/Recordings/Graphs I'll add some when I get there... but so far the results look identical to the previous implementation even when I zoom in close.  ## Tests

MrUnknownDE closed this issue

2026-04-05 23:11:18 +02:00

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#2066