Don't break lerp effect in post-processing local mode #2513
Conversation
WalkthroughThe changes in the Changes
Suggested Reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2513 +/- ##
==========================================
+ Coverage 68.58% 69.02% +0.44%
==========================================
Files 957 957
Lines 100052 100051 -1
Branches 8566 8562 -4
==========================================
+ Hits 68617 69063 +446
+ Misses 31179 30732 -447
Partials 256 256
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/core/src/postProcess/PostProcessManager.ts (1)
Line range hint
73-111: Consider enhancing error handling for edge cases.While the changes fix the lerp effect, consider adding the following improvements:
- Add debug logging when
interpFactoris calculated to help troubleshoot blending issues.- Consider clamping
interpFactorto [0,1] range explicitly for safety.- Add performance metrics for distance calculations in local mode.
Example implementation:
let interpFactor = 1; // default value in global mode if (!isGlobal) { interpFactor = 0; // default value in local mode + const startTime = performance.now(); const currentColliders = PostProcessManager._tempColliders; // ... distance calculation code ... if (closestDistance <= blendDistance && blendDistance > 0) { interpFactor = 1 - closestDistance / blendDistance; + interpFactor = Math.max(0, Math.min(1, interpFactor)); + Logger.debug(`PostProcess: calculated interpFactor ${interpFactor} for ${postProcess.entity.name}`); } + const endTime = performance.now(); + Logger.debug(`PostProcess: distance calculation took ${endTime - startTime}ms`); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/core/src/postProcess/PostProcessManager.ts(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: build (22.x, windows-latest)
- GitHub Check: codecov
- GitHub Check: e2e (22.x)
🔇 Additional comments (1)
packages/core/src/postProcess/PostProcessManager.ts (1)
73-75: LGTM! Clear initialization of interpolation factors.The explicit initialization of
interpFactorfor both global and local modes improves code clarity and correctness. Setting it to 0 for local mode ensures proper blending behavior from the start.
| if (closestDistance <= blendDistance && blendDistance > 0) { | ||
| interpFactor = 1 - closestDistance / blendDistance; | ||
| } |
There was a problem hiding this comment.
💡 Codebase verification
Consider adding property-level validation for blendDistance
While the runtime check prevents interpolation issues, consider adding validation in the PostProcess class to ensure blendDistance is always non-negative when set. This would catch invalid values earlier and provide clearer feedback to developers.
Example locations that need attention:
packages/core/src/postProcess/PostProcess.ts: Add validation for theblendDistanceproperty
🔗 Analysis chain
Good fix for blend distance validation.
The additional check blendDistance > 0 prevents invalid interpolation when blend distance is zero or negative. This fixes the lerp effect in local mode.
Consider adding validation when setting blendDistance to ensure it's always positive.
Let's check if blendDistance validation exists:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for PostProcess class definition and blendDistance property
ast-grep --pattern 'class PostProcess {
$$$
blendDistance$$$
$$$
}'
Length of output: 75
Script:
#!/bin/bash
# Find the class definition and blendDistance usage
rg "class.*PostProcess" -A 5
rg "blendDistance" -A 2 -B 2
Length of output: 14581
|
enhance it in #2514 |
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:
Summary by CodeRabbit