HUD edit: mouse-wheel zoom of the HUD layer (find off-screen HUDs, fine editing) #413
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream#413
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In other viewers, when you edit a HUD attachment (build mode with a HUD object selected), the mouse wheel zooms the HUD layer in and out. That lets you work on small HUD details, and zoom out to find HUD objects that sit off screen (a common problem after attaching a HUD that saves its position off the edge, or switching screen aspect ratio). Slipstream needs this.
What's already in the code
LLAgentCamera::cameraZoomIn(llagentcamera.cpp~1047) checksinBuildMode() && selection is SELECT_TYPE_HUDand updatesmHUDTargetZoominstead of the camera.getAgentHUDTargetZoom()(~883) and the reset at ~386 exist too.mHUDCurZoomtowardmHUDTargetZoom; the only assignment is its initialisation. LL's per-frame lerp seems to have gone with the GL display code. Everything that reads the current zoom therefore always sees 1.0:get_hud_matrices(llviewerdisplay.cpp~385)llmaniptranslate.cpp,llmanipscale.cpp,llmanip.cpp)altoolalign.cppget_hud_matricesor its own HUD projection. If it builds its own, it must apply the zoom (and the pick / hover / manipulator projections must match it).Do
mHUDCurZoomtoward the HUD target zoom (an LL-style lerp), and reset it when leaving HUD edit.Test