Skip to content

Implement lookup-table-based rectangle approximation.#161

Open
Veeno wants to merge 5 commits into
RLBot:masterfrom
Veeno:RectUtil
Open

Implement lookup-table-based rectangle approximation.#161
Veeno wants to merge 5 commits into
RLBot:masterfrom
Veeno:RectUtil

Conversation

@Veeno
Copy link
Copy Markdown

@Veeno Veeno commented May 30, 2026

Rectangle approximation using a precomputed lookup table has been implemented, for use in MakeFakeRectangleString. Even though this method produces a string of length rows+cols-1, the ratio limit in table precomputation is based on rows*cols because this produces a better ratio value distribution for a given lookup table size.

An additional accompanying unit test has also been implemented.

Edit: The value generation strategy has been significantly refactored.

Comment thread RLBotCSTests/ManagerTools/RectUtilTest.cs Outdated
@NicEastvillage
Copy link
Copy Markdown
Contributor

If I understand this correctly, all the aspect ratios you compute are subject to rows * cols <= Limit (as I presented it in #mathematics), and currently Limit is 4096 because the lookup table grows fast.

The existing algorithm finds ratios subject to rows + cols <= 30_000 but fails if it cannot find an exact solution.

You did not implement this as a fallback to the existing algorithm, so I wonder if this change drastically reduces the number of exact solutions found.

Since this is for rendering, an exact solution is preferable over speed. We do not want 1-pixel-wide gaps to appear too often. We really only need a "good enough" fallback when an exact solution is not possible.

@Veeno
Copy link
Copy Markdown
Author

Veeno commented Jun 1, 2026

If I understand this correctly, all the aspect ratios you compute are subject to rows * cols <= Limit (as I presented it in #mathematics), and currently Limit is 4096 because the lookup table grows fast.

The existing algorithm finds ratios subject to rows + cols <= 30_000 but fails if it cannot find an exact solution.

You did not implement this as a fallback to the existing algorithm, so I wonder if this change drastically reduces the number of exact solutions found.

Since this is for rendering, an exact solution is preferable over speed. We do not want 1-pixel-wide gaps to appear too often. We really only need a "good enough" fallback when an exact solution is not possible.

@NicEastvillage I was not aware that accuracy was critical, sorry about that!

However, with the latest value generation refactoring, I think it's incredibly unlikely that this approach fails to either find an exact solution, or one which rounds to the exact pixel count. However, this would need to be more thoroughly tested (I can't guarantee it for certain at this point). So if you prefer, I'll revert the MakeFakeRectangleString code so this is used only as a fallback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants