fix: 3D raycast annotations follow reachable collider shapes - #1502
Conversation
Replace large sampled-cell bounding boxes in the screenshot overlay with outlines built from reachable raycast sample cells. Keep the JSON bounds as a compatibility bbox while preserving SimX/SimY as the click-ready sampled point. Add a perspective raycast annotation demo scene so angled placement areas and UI blockers can be visually checked.
|
Warning Review limit reached
Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughThis PR adds clustered raycast outline generation and rendering for physics-collider annotations, extends tests around outline geometry and coordinate conversion, and updates related skill/reference docs for explicit boolean values and revised output semantics. ChangesOutline and annotation updates
Documentation updates
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant RaycastGridAnnotator
participant RaycastSampleOutlineBuilder
participant UIElementInfo
participant UIElementAnnotator
RaycastGridAnnotator->>RaycastGridAnnotator: CollectClusterSamples (row, column, clusterKey)
RaycastGridAnnotator->>RaycastSampleOutlineBuilder: CreateOutlineSegments(clusterSamples)
RaycastSampleOutlineBuilder-->>RaycastGridAnnotator: outlineSegments
RaycastGridAnnotator->>UIElementInfo: RaycastOutlineSegments = outlineSegments
UIElementAnnotator->>UIElementInfo: read RaycastOutlineSegments
UIElementAnnotator->>UIElementAnnotator: ConvertTopLeftOutlineSegmentToScreenSegment
UIElementAnnotator->>UIElementAnnotator: CreateAnnotationOutlineForElement
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Assets/Tests/Editor/UIElementAnnotatorTests.cs (1)
129-141: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider adding coverage for the outline-rect geometry, not just the Y-flip helper.
This test covers
ConvertTopLeftOutlineSegmentToScreenSegmentwell, butCalculateOutlineSegmentRectandCreateOutline(the actual pixel geometry drawn per segment) have no direct tests. A test asserting adjoining segments produce a corner without gaps would have caught the corner-notch issue flagged inUIElementAnnotator.cs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Assets/Tests/Editor/UIElementAnnotatorTests.cs` around lines 129 - 141, The current test only validates the Y-flip helper in UIElementAnnotator.ConvertTopLeftOutlineSegmentToScreenSegment, but it does not cover the actual outline geometry built by CalculateOutlineSegmentRect and CreateOutline. Add tests around those methods that assert adjoining RaycastOutlineSegment values produce a continuous corner with no gap/notch, using UIElementAnnotator as the main entry point so the drawn pixel geometry is verified directly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Packages/src/Editor/Utils/UIElementAnnotator.cs`:
- Around line 550-582: The outline corners in CreateOutline are leaving small
uncovered notches because CalculateOutlineSegmentRect only expands each segment
perpendicular to the line, not at the ends. Update CalculateOutlineSegmentRect
so horizontal and vertical segment rects are extended by thickness/2 on both
endpoints (square-cap behavior), ensuring adjacent perpendicular edges overlap
and fully cover each corner for all outline layers.
---
Nitpick comments:
In `@Assets/Tests/Editor/UIElementAnnotatorTests.cs`:
- Around line 129-141: The current test only validates the Y-flip helper in
UIElementAnnotator.ConvertTopLeftOutlineSegmentToScreenSegment, but it does not
cover the actual outline geometry built by CalculateOutlineSegmentRect and
CreateOutline. Add tests around those methods that assert adjoining
RaycastOutlineSegment values produce a continuous corner with no gap/notch,
using UIElementAnnotator as the main entry point so the drawn pixel geometry is
verified directly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 7b854040-d4d3-4b4a-856d-d981bc168b4b
⛔ Files ignored due to path filters (3)
Assets/Scenes/RaycastAnnotationPerspectiveDemoScene.unityis excluded by!**/*.unityand included by noneAssets/Scenes/RaycastAnnotationPerspectiveDemoScene.unity.metais excluded by none and included by nonePackages/src/Editor/Utils/RaycastSampleOutlineBuilder.cs.metais excluded by none and included by none
📒 Files selected for processing (9)
Assets/Tests/Editor/RaycastGridAnnotatorTests.csAssets/Tests/Editor/UIElementAnnotatorTests.csPackages/src/Editor/Api/McpTools/Screenshot/Skill/SKILL.mdPackages/src/Editor/Api/McpTools/Screenshot/Skill/references/annotated-elements.mdPackages/src/Editor/Api/McpTools/Screenshot/UIElementInfo.csPackages/src/Editor/Utils/RaycastGridAnnotator.csPackages/src/Editor/Utils/RaycastHitClusterer.csPackages/src/Editor/Utils/RaycastSampleOutlineBuilder.csPackages/src/Editor/Utils/UIElementAnnotator.cs
There was a problem hiding this comment.
1 issue found across 12 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Use distinct UI and visual blocker colors so the raycast annotation demo is easier to inspect from an angled camera.
Avoid a magenta blocker color that looks like a shader error while keeping the visual blocker distinct from the blue UI blocker.
Use a transparent amber material so the foreground blocker remains visible while revealing the placement cells behind it.
Clarify that screenshot boolean options require explicit true or false values so skill examples match the CLI option parser.
Regenerate the checked-in Claude and agent skill copies so screenshot examples include explicit boolean values.
Extend outline segment rectangles along their endpoints so perpendicular segments overlap at corners and avoid visible notches.
There was a problem hiding this comment.
3 issues found across 49 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".agents/skills/uloop-compile/SKILL.md">
<violation number="1" location=".agents/skills/uloop-compile/SKILL.md:39">
P2: The `compile` examples still demonstrate explicit `true`/`false` values for `--force-recompile` and `--wait-for-domain-reload`, which conflicts with the project's convention for valueless boolean flags in compile docs. Consider replacing these examples with valueless forms (e.g., `--force-recompile` and `--wait-for-domain-reload`) for consistency with the documented CLI contract.</violation>
</file>
<file name=".claude/skills/uloop-compile/SKILL.md">
<violation number="1" location=".claude/skills/uloop-compile/SKILL.md:39">
P2: The example commands use explicit `true`/`false` values for boolean flags (`--force-recompile true`, `--force-recompile false`, `--wait-for-domain-reload true`), which contradicts the project's convention of using valueless boolean flags for the `compile` command. The Usage section already shows the correct valueless form `[--force-recompile] [--wait-for-domain-reload]`, but the examples below it reintroduce the non-standard explicit-value style. This inconsistency can mislead users and downstream automation. Consider rewriting the examples to use the valueless flag convention consistently.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
|
|
||
| # Force recompilation and wait for Domain Reload completion | ||
| uloop compile --force-recompile true --wait-for-domain-reload true | ||
| npx --yes uloop-cli@2.2.0 compile --force-recompile true --wait-for-domain-reload true |
There was a problem hiding this comment.
P2: The compile examples still demonstrate explicit true/false values for --force-recompile and --wait-for-domain-reload, which conflicts with the project's convention for valueless boolean flags in compile docs. Consider replacing these examples with valueless forms (e.g., --force-recompile and --wait-for-domain-reload) for consistency with the documented CLI contract.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .agents/skills/uloop-compile/SKILL.md, line 39:
<comment>The `compile` examples still demonstrate explicit `true`/`false` values for `--force-recompile` and `--wait-for-domain-reload`, which conflicts with the project's convention for valueless boolean flags in compile docs. Consider replacing these examples with valueless forms (e.g., `--force-recompile` and `--wait-for-domain-reload`) for consistency with the documented CLI contract.</comment>
<file context>
@@ -30,16 +30,16 @@ uloop compile [--force-recompile] [--wait-for-domain-reload]
# Force recompilation and wait for Domain Reload completion
-uloop compile --force-recompile true --wait-for-domain-reload true
+npx --yes uloop-cli@2.2.0 compile --force-recompile true --wait-for-domain-reload true
# Wait for Domain Reload completion even without force recompilation
</file context>
There was a problem hiding this comment.
Addressed in 19d010a.
The CLI help shows these compile booleans as value-based options (--force-recompile <value> and --wait-for-domain-reload <value>), so I updated the source skill and generated copies to document <true|false> explicitly instead of switching to bare flags.
Verification: uloop compile --help; git diff --check.
There was a problem hiding this comment.
The parent comment was wrong here: the CLI contract is value-based booleans, so documenting true/false is the right fix. Thanks for updating the source skill and generated copies.
|
|
||
| # Force recompilation and wait for Domain Reload completion | ||
| uloop compile --force-recompile true --wait-for-domain-reload true | ||
| npx --yes uloop-cli@2.2.0 compile --force-recompile true --wait-for-domain-reload true |
There was a problem hiding this comment.
P2: The example commands use explicit true/false values for boolean flags (--force-recompile true, --force-recompile false, --wait-for-domain-reload true), which contradicts the project's convention of using valueless boolean flags for the compile command. The Usage section already shows the correct valueless form [--force-recompile] [--wait-for-domain-reload], but the examples below it reintroduce the non-standard explicit-value style. This inconsistency can mislead users and downstream automation. Consider rewriting the examples to use the valueless flag convention consistently.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .claude/skills/uloop-compile/SKILL.md, line 39:
<comment>The example commands use explicit `true`/`false` values for boolean flags (`--force-recompile true`, `--force-recompile false`, `--wait-for-domain-reload true`), which contradicts the project's convention of using valueless boolean flags for the `compile` command. The Usage section already shows the correct valueless form `[--force-recompile] [--wait-for-domain-reload]`, but the examples below it reintroduce the non-standard explicit-value style. This inconsistency can mislead users and downstream automation. Consider rewriting the examples to use the valueless flag convention consistently.</comment>
<file context>
@@ -30,16 +30,16 @@ uloop compile [--force-recompile] [--wait-for-domain-reload]
# Force recompilation and wait for Domain Reload completion
-uloop compile --force-recompile true --wait-for-domain-reload true
+npx --yes uloop-cli@2.2.0 compile --force-recompile true --wait-for-domain-reload true
# Wait for Domain Reload completion even without force recompilation
</file context>
There was a problem hiding this comment.
Addressed in 19d010a.
The CLI help shows these compile booleans as value-based options (--force-recompile <value> and --wait-for-domain-reload <value>), so I updated the source skill and generated copies to document <true|false> explicitly instead of switching to bare flags.
Verification: uloop compile --help; git diff --check.
There was a problem hiding this comment.
You're right — the compile CLI treats those booleans as value-based options, so the parent comment was wrong here. Updating the source skill and generated copies to show <true|false> matches the actual help output.
Thanks for the feedback! I've updated an existing learning with this new information.
Align compile skill usage with the CLI value-based boolean parser and remove the duplicated raycast screenshot example from generated skill docs.
There was a problem hiding this comment.
1 issue found across 44 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".claude/skills/uloop-compile/SKILL.md">
<violation number="1" location=".claude/skills/uloop-compile/SKILL.md:20">
P1: The compile skill documentation now requires explicit `true`/`false` values for `--force-recompile` and `--wait-for-domain-reload`, and claims bare flags are not accepted. This contradicts the established CLI contract guidance for this repository (valueless boolean flags are the expected form for this command). Without evidence that the CLI parser itself was changed to reject bare flags, the documentation should continue to show valueless flags like `--force-recompile` without values.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
@.agents/skills/uloop-execute-dynamic-code/references/playmode-automation-powershell.md:
- Line 180: The `find-game-objects` example is currently using the default
inactive-object behavior implicitly, which can mislead readers about where the
behavior change applies. Update the example in the playmode automation docs to
keep `--include-inactive false` explicit on the hierarchy-related example, and
make sure the `get-hierarchy` guidance is the one that reflects the new default
of including inactive objects unless that flag is set.
In @.agents/skills/uloop-screenshot/references/annotated-elements.md:
- Line 41: Scope the direct-use note in annotated-elements.md to rendering
captures only: the current statement in the annotations section claims
AnnotatedElements[].SimX/SimY and RaycastGridPoints[].InputX/InputY are always
mouse-input coordinates, but that guarantee applies only when
ImageCoordinateSystem is "top-left-game-view". Update the wording near the
ResolutionScale/ImageToInputOffsetY guidance so it explicitly qualifies this
behavior for rendering captures and does not imply the same contract for window
captures.
In @.agents/skills/uloop-screenshot/SKILL.md:
- Around line 97-100: Clarify the capture-mode dependency in SKILL.md so
downstream tools only rely on conversion fields for rendering captures. Update
the documentation around the listed symbols (ImageToInputOffsetY, GameViewWidth,
GameViewHeight, ScreenshotToInputFormula, UnityInputFormula) to state they are
populated only when the screenshot comes from rendering capture, while window
captures leave them default or unavailable. Keep the scope explicit near the
relevant mouse-input guidance so users of the screenshot-to-input flow don’t
assume universal availability.
In @.claude/skills/uloop-screenshot/references/annotated-elements.md:
- Line 41: The direct-use note for AnnotatedElements[].SimX/SimY and
RaycastGridPoints[].InputX/InputY is too broad and should be scoped to rendering
captures only. Update the wording in annotated-elements.md to explicitly tie the
mouse-input coordinate guarantee to ImageCoordinateSystem being
"top-left-game-view" (for example in the section describing ResolutionScale and
ImageToInputOffsetY), so window captures are not implied to follow the same
contract.
In @.claude/skills/uloop-screenshot/SKILL.md:
- Around line 97-100: Clarify capture-mode dependency for the screenshot output
fields in the SKILL.md section: `ImageToInputOffsetY`, `GameViewWidth`,
`GameViewHeight`, `ScreenshotToInputFormula`, and `UnityInputFormula` should be
documented as rendering-capture-only values. Update the descriptions near those
symbols to state that window captures leave them at defaults or unavailable, so
downstream mouse-input tools do not assume these fields are always present or
usable.
In `@Packages/src/Editor/Api/McpTools/Screenshot/Skill/SKILL.md`:
- Around line 25-28: The `--raycast-layer-mask` row is misleading about
clustering: the implementation in the screenshot annotation flow groups dense
raycast samples by clickable object/GameObject via
`collider.gameObject.GetInstanceID()`, not by individual collider. Update the
wording in `SKILL.md` to reflect that `PhysicsCollider` entries are clustered by
the GameObject/clickable object so multiple colliders on the same object are
covered by one entry, while keeping the rest of the behavior description intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6c80668d-358b-4579-ada2-0c17fd447eef
⛔ Files ignored due to path filters (1)
Assets/Scenes/RaycastAnnotationPerspectiveDemoScene.unityis excluded by!**/*.unityand included by none
📒 Files selected for processing (46)
.agents/skills/uloop-clear-console/SKILL.md.agents/skills/uloop-compile/SKILL.md.agents/skills/uloop-control-play-mode/SKILL.md.agents/skills/uloop-execute-dynamic-code/references/asset-operations.md.agents/skills/uloop-execute-dynamic-code/references/playmode-automation-powershell.md.agents/skills/uloop-execute-dynamic-code/references/playmode-automation-zsh.md.agents/skills/uloop-find-game-objects/SKILL.md.agents/skills/uloop-focus-window/SKILL.md.agents/skills/uloop-get-hierarchy/SKILL.md.agents/skills/uloop-get-logs/SKILL.md.agents/skills/uloop-launch/SKILL.md.agents/skills/uloop-raycast/SKILL.md.agents/skills/uloop-record-input/SKILL.md.agents/skills/uloop-replay-input/SKILL.md.agents/skills/uloop-run-tests/SKILL.md.agents/skills/uloop-screenshot/SKILL.md.agents/skills/uloop-screenshot/references/annotated-elements.md.agents/skills/uloop-simulate-keyboard/SKILL.md.agents/skills/uloop-simulate-mouse-input/SKILL.md.agents/skills/uloop-simulate-mouse-ui/SKILL.md.claude/skills/uloop-clear-console/SKILL.md.claude/skills/uloop-compile/SKILL.md.claude/skills/uloop-control-play-mode/SKILL.md.claude/skills/uloop-execute-dynamic-code/references/asset-operations.md.claude/skills/uloop-execute-dynamic-code/references/playmode-automation-powershell.md.claude/skills/uloop-execute-dynamic-code/references/playmode-automation-zsh.md.claude/skills/uloop-find-game-objects/SKILL.md.claude/skills/uloop-focus-window/SKILL.md.claude/skills/uloop-get-hierarchy/SKILL.md.claude/skills/uloop-get-logs/SKILL.md.claude/skills/uloop-launch/SKILL.md.claude/skills/uloop-raycast/SKILL.md.claude/skills/uloop-record-input/SKILL.md.claude/skills/uloop-replay-input/SKILL.md.claude/skills/uloop-run-tests/SKILL.md.claude/skills/uloop-screenshot/SKILL.md.claude/skills/uloop-screenshot/references/annotated-elements.md.claude/skills/uloop-simulate-keyboard/SKILL.md.claude/skills/uloop-simulate-mouse-input/SKILL.md.claude/skills/uloop-simulate-mouse-ui/SKILL.mdAssets/Tests/Editor/UIElementAnnotatorTests.csPackages/src/Editor/Api/McpTools/Compile/Skill/SKILL.mdPackages/src/Editor/Api/McpTools/Screenshot/Skill/SKILL.mdPackages/src/Editor/Api/McpTools/Screenshot/Skill/references/annotated-elements.mdPackages/src/Editor/Api/McpTools/SimulateMouseUi/Skill/SKILL.mdPackages/src/Editor/Utils/UIElementAnnotator.cs
✅ Files skipped from review due to trivial changes (30)
- .agents/skills/uloop-execute-dynamic-code/references/asset-operations.md
- .claude/skills/uloop-raycast/SKILL.md
- .agents/skills/uloop-raycast/SKILL.md
- .agents/skills/uloop-focus-window/SKILL.md
- .claude/skills/uloop-clear-console/SKILL.md
- .claude/skills/uloop-get-hierarchy/SKILL.md
- .agents/skills/uloop-clear-console/SKILL.md
- .claude/skills/uloop-get-logs/SKILL.md
- .agents/skills/uloop-control-play-mode/SKILL.md
- .claude/skills/uloop-replay-input/SKILL.md
- .agents/skills/uloop-launch/SKILL.md
- .claude/skills/uloop-focus-window/SKILL.md
- .claude/skills/uloop-execute-dynamic-code/references/asset-operations.md
- .claude/skills/uloop-find-game-objects/SKILL.md
- .claude/skills/uloop-record-input/SKILL.md
- .agents/skills/uloop-get-hierarchy/SKILL.md
- .agents/skills/uloop-get-logs/SKILL.md
- .claude/skills/uloop-execute-dynamic-code/references/playmode-automation-powershell.md
- .agents/skills/uloop-replay-input/SKILL.md
- .claude/skills/uloop-launch/SKILL.md
- .agents/skills/uloop-execute-dynamic-code/references/playmode-automation-zsh.md
- Packages/src/Editor/Api/McpTools/Compile/Skill/SKILL.md
- .claude/skills/uloop-simulate-keyboard/SKILL.md
- .agents/skills/uloop-find-game-objects/SKILL.md
- Packages/src/Editor/Api/McpTools/SimulateMouseUi/Skill/SKILL.md
- .agents/skills/uloop-compile/SKILL.md
- .claude/skills/uloop-compile/SKILL.md
- .claude/skills/uloop-control-play-mode/SKILL.md
- Packages/src/Editor/Api/McpTools/Screenshot/Skill/references/annotated-elements.md
- .agents/skills/uloop-run-tests/SKILL.md
🚧 Files skipped from review as they are similar to previous changes (1)
- Packages/src/Editor/Utils/UIElementAnnotator.cs
|
Verified the latest cubic finding against the current CLI contract.
Added commit |
There was a problem hiding this comment.
1 issue found across 9 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".agents/skills/uloop-compile/SKILL.md">
<violation number="1" location=".agents/skills/uloop-compile/SKILL.md:39">
P2: The `compile` examples still demonstrate explicit `true`/`false` values for `--force-recompile` and `--wait-for-domain-reload`, which conflicts with the project's convention for valueless boolean flags in compile docs. Consider replacing these examples with valueless forms (e.g., `--force-recompile` and `--wait-for-domain-reload`) for consistency with the documented CLI contract.</violation>
</file>
<file name=".claude/skills/uloop-compile/SKILL.md">
<violation number="1" location=".claude/skills/uloop-compile/SKILL.md:39">
P2: The example commands use explicit `true`/`false` values for boolean flags (`--force-recompile true`, `--force-recompile false`, `--wait-for-domain-reload true`), which contradicts the project's convention of using valueless boolean flags for the `compile` command. The Usage section already shows the correct valueless form `[--force-recompile] [--wait-for-domain-reload]`, but the examples below it reintroduce the non-standard explicit-value style. This inconsistency can mislead users and downstream automation. Consider rewriting the examples to use the valueless flag convention consistently.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Summary
User Impact
Changes
Verification
Summary
Bounds*as compatibility axis-aligned boxes (and omitting fully covered clusters).RaycastOutlineSegmentstoUIElementInfoand updated overlay rendering/border rendering to prefer outline strokes when present; converted top-left raycast outline segments into screen-space for drawing, including correct canvas-space Y-flip behavior and per-segment rect calculation.GameObjectinto a single physics annotation, increased clustered grid density (20×20 → 40×40), and propagated row/column metadata into outline generation.GameObject(multi-collider case),PhysicsColliderUI elements when cluster samples include grid coordinates,RaycastOutlineSegmentrect conversion.true|falsevalues for boolean flags.uloop compileboolean options reject bare flags and error when--force-recompile <value>/--wait-for-domain-reload <value>are omitted.