Suggestions on rotate/zoom/pan behavior
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- computer-graphics
Research direction
Start by tracing the existing trackball, zoom, pan, and focus-point input handling described in the issue. Compare the current behavior with the linked trackball references and define separate, testable decisions for rotation, relative zooming, proportional panning, focus-point movement, and focus-point activation before implementing anything.
Written by the indexing model from the issue text.
Description
Hi, thanks for this great lib !
- The recent feature that allows to select a focus point with
ctr+shift+left clickis very convenient. - The trackball follows the rule of path invariance which is great too !
However, I'd like to suggest other features that could improve the ergonomy when carefully inspecting a scene.
Rotate
Current trackball seems to be an azimuth/elevation control which is fine, but disallows roll completely. This "turntable" behavior might be desired, but a more standard approach is to use an azimuth/elevation behavior in the center of the viewport fading to a more roll-permissive behavior further from the center. This nice blog post from Scott Shambaugh summarizes different trackball implementations, including the standard OpenGL one.
Zoom
The default mouse scroll zoom should be relative (without pressing shift+ctrl). The absolute zoom is bad because zooming is supposed to give an impression of scaling things. When far from the scene, it is painfully slow, and way too sensitive near an object's surface.
Pan
Currently, panning the camera does not move the focus point which creates a incomfortable setup if the user decide to rotate again. I suggest to also translate the focus point by a same amount to prevent that. Also, the panning is absolute thus suffers from the same issues of the absolute zoom. I recommend to make it proportional to the distance between the eye and the focus point.
Lastly, I find the focus point picking so convenient I think it should be more accessible (maybe double click like in Meshlab ?)
Those are only suggestions of course.
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 242
- Avg merge
- 11m
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nmwsharp/polyscope
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
-
Rust Version Open
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 20/100
All issues in nmwsharp/polyscope
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
google-ai-edge/LiteRT-LM#3739 ·
-
Component: GLib
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Mute ydb/tests/functional/dstool/test_canonical_requests.py.Test.test_group_take_snapshot in main Openai_reviewed
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
ydb-platform/ydb#53974 · 3 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
google/libultrahdr#485 ·