-
Notifications
You must be signed in to change notification settings - Fork 635
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
DYN-6489 Dynamo Zoom Extents behavior has changed #14674
Conversation
+1 |
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.
A couple questions, but it looks good otherwise, I think we should add an image comparison test if one doesn't exist already.
We likely also need a followup if one already exists to see if we can make the system more robust.
I think whoever takes the current task can add that test or file that followup task.
@saintentropy I've pushed to this branch and will merge / cherry pick after the tests pass. |
UI Smoke TestsTest: success. 2 passed, 0 failed. |
UI Smoke TestsTest: success. 2 passed, 0 failed. |
|
||
if (geom.Geometry.Positions.Count > 1) | ||
if(Math.Abs(bounds.Size.LengthSquared()) < defaultBoundsSize * defaultBoundsSize * 3) |
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.
A square of any number will always be greater than or equal to zero, why do we need Math.Abs
?
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.
Can you explain this formula, where do you get 3
from?
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 I remember @saintentropy 's explanation correctly, he was just trying to set a good minimum zoom size. If we go too small the UI becomes difficult to navigate/pan etc. This value is larger than what we had before but it seems to work well in practice even for just a point.
I don't see a reason for the abs call either. I can remove it.
if(watch_view.Camera.Position.ToVector3().IsUndefined() || | ||
watch_view.Camera.LookDirection.ToVector3().IsUndefined() || | ||
watch_view.Camera.LookDirection.Length == 0) | ||
if (watch_view.Camera is HelixToolkit.Wpf.SharpDX.PerspectiveCamera perspectiveCam) |
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.
Do we need to account for the case where the camera is Orthographic if at all possible?
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.
hmm, let me look into if that was supported before.
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.
yeah, your're right @aparajit-pratap that would have been supported before, I'll move in the code for ortho cameras as well from helix.
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.
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.
Wait, how do we change the camera from perspective to orthographic? Is there a UI option?
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 be done from a view extension - theres a property on the helix viewport object
UI Smoke TestsTest: success. 2 passed, 0 failed. |
UI Smoke TestsTest: success. 2 passed, 0 failed. |
UI Smoke TestsTest: success. 2 passed, 0 failed. |
UI Smoke TestsTest: success. 2 passed, 0 failed. |
* Adopt updated helix ZoomExtents algorithm * use Helix native bounds implementation * Why was this ever this way * changes made * handle zoom for ortho * review comments --------- Co-authored-by: Craig Long <[email protected]> Co-authored-by: mjk.kirschner <[email protected]> (cherry picked from commit 6d50740)
* Adopt updated helix ZoomExtents algorithm * use Helix native bounds implementation * Why was this ever this way * changes made * handle zoom for ortho * review comments --------- Co-authored-by: Craig Long <[email protected]> Co-authored-by: mjk.kirschner <[email protected]> (cherry picked from commit 6d50740)
Purpose
Helix-Toolkit made an adjustment in the
ZoomExtents()
algorithm in the 2.24.0 Release. Specifically, the change was introduced here -> helix-toolkit/helix-toolkit#1921 and was included in the 2.24.0 release. Previously theZoomExtents()
algorithm was never very accurate or predictable in that results would vary depending on the size and height/width ratio of background preview view window. This change however makes the calculated ZoomExtents appear fully incorrect for some cases. Subsequent to this code change, the Dev branch in helix-toolkit now has a dramatically improved algorithm for ZoomExtents. The PR is found here -> helix-toolkit/helix-toolkit#2003. I assume this new algorithm will be available in the 2.25.0 release and is testable currently with the helix-toolkit daily builds. This PR pulls the relevant implementation into Dynamo for use until the release of 2.25.0 when we can presumably call the updated methods directly. In testing, ZoomExtents is now fully predictable regardless of background preview view window size or height/width ratio.This PR also takes the opportunity to utilize the native helix-toolkit bounding box calculation for scene objects. This was not available 8 years ago when we added our own implementation. By using the native methods, we also solve the issue where instance geometry was not correctly considered for ZoomExtents calculations.
Also for some reason we have always been clipping the top 20 pixels off of the background preview 🤷. Now you notice it so I removed that margin.
Improved Result
Previous Behavior
Declarations
Check these if you believe they are true
*.resx
filesRelease Notes
Zoom Extents for the background preview is now more accurate and predictable regardless of the size of the Dynamo application window.
Reviewers
@aparajit-pratap @mjkkirschner
FYIs
@jnealb @twastvedt