-
-
Notifications
You must be signed in to change notification settings - Fork 715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/remaining issues camera inside terrain #4551
base: main
Are you sure you want to change the base?
Fix/remaining issues camera inside terrain #4551
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4551 +/- ##
==========================================
+ Coverage 90.48% 90.70% +0.22%
==========================================
Files 265 265
Lines 38113 38116 +3
Branches 3166 3150 -16
==========================================
+ Hits 34488 34575 +87
+ Misses 2650 2601 -49
+ Partials 975 940 -35 ☔ View full report in Codecov by Sentry. |
@chrneumann where are we with this? |
Waiting for your reply, see the open code review. |
Hu? |
Ok, sorry, I did not submit the review. |
Ok, looks good, can you check why the test is failing? |
Fixed that, a render test failed because of the readded buffer between terrain surface and camera. |
Should this PR still be in draft mode? |
Can you please add a changelog entry? |
…camera-inside-terrain
Done. New transform stuff also merged. |
Looking at the fact that you added code without a failing test can indicate that the added code in the transform class is not covered by tests? |
Yes, the try/catch is not covered by a test. We talked about that before: #4551 (comment) Best would be to have more insights from someone who knows more about the recalculation code. Not sure, if you got a reply? But yeah, I could also try to crash it and find out which values lead to the crash and add a test with these values. But knowing why it crashes in the first place would be better. |
Did you push the commit? I still see that the code coverage is not getting to this catch block... |
No, did you see the discussion at #4551 (comment) ? |
Yes, regardless of if the solution is an "if" or a try-catch, there's a need to add a test the reproduces this issue (I think a unit test is the right kind of test here, but I don't mind either way). |
…camera-inside-terrain
I can't reproduce the crash any more in the current main branch. Still kept the added surface padding (camera stays not directly on the ground), as it prevents some graphic glitches. But there seems to be a regression with the |
Started with 5.0.0-pre.4 |
@NathanMOlson is this change problematic for what you are working on? |
Yes, it's ready. |
@@ -2028,6 +2028,9 @@ describe('#flyTo', () => { | |||
}; | |||
camera.transform = { | |||
elevation: 0, | |||
recalculateZoom: () => true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be recalculateZoomAndCenter()
now
if (!this.terrain && tr.elevation >= 0 && tr.pitch <= 90) { | ||
return {}; | ||
} | ||
const surfacePadding = Math.min(500, 20 * (25 - tr.zoom)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this surface padding?
At a typical zoom of 15, this sets the minimum altitude at 200m. This amount of surface padding is problematic for ground-level use cases (like an aircraft on the runway, or touring a city at eye-level.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can help prevent graphic glitches when the camera is directly moving on the surface. Do these use cases have terrain enabled? If so, one could make the padding optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (!this.terrain && tr.elevation >= 0 && tr.pitch <= 90) { | ||
return {}; | ||
} | ||
const surfacePadding = Math.min(500, 20 * (25 - tr.zoom)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The linear scaling with zoom level doesn't make sense to me. I think it would be more appropriate to have something like 500 / (2**tr.zoom)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong arguments for the current calculation, but why do you think non-linear is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the distance from camera to center point (in meters) is inversely proportional to 2**tr.zoom
If you increase zoom by 1, you are cutting the distance from camera to center point in half. So it seems like you should also cut the padding in half.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "expected" image shows this bug: #4859
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think any of the "expected" images for these render tests should change. The fact that they are changing means that the pitch angle is being adjusted, and I don't think it should be in any of these cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's shifted because the padding is added which results in a changed angle (the center stays the same).
Thanks @NathanMOlson! These are interesting questions and observations. |
Tbh I would like to disable this feature for the use case for aircraft. Currently motion control works with We can have a on and off switch for this feature where the user can choose between going under the terrain and not going under it. I know for the default UX no one wants to go under the Terrain but we have to find a solution for the aircraft use case. |
Launch Checklist
Add buffer so that camera doesn't sit directly on terrain. Prevent crashes when zoom is wrongly calculated.
CHANGELOG.md
under the## main
section.