Whither goes the cam when sitting and arrow keys are pressed?

[Qie Niangao]

This must be documented somewhere but not sure where to look and discovering the details myself is proving a deeper dive than I expected.

If the avatar sits on an object that does not have fixed camera offsets, pressing the left or right arrow key will orbit the cam around a focus somewhere "in front" of the avatar center. After left/right arrows are touched, pressing the PageUp and PageDn keys will adjust the elevation of the cam. The up/down arrow keys pull the cam in closer or further away (but don't unlock the PageUp/PageDn behavior).

Some people apparently rely on this feature, which is completely lost when camera offsets are set (llSetLinkCamera or llSetCameraAtOffset/llSetCameraEyeOffset), but still works when only using llSetCameraParams(). My overall objective here is to use llSetCameraParams() to preset a newly seated agent's camera constrained to settings from which the first press of those arrow keys won't jump the cam over a big discontinuity.

So far it seems that with the viewer in "Rear View" mode, the initial seated cam position is about <-3, 0, 0.8> from the avatar (so directly behind and slightly above), focused on a point <1, 0, 1> (looking forward and very slightly upwards from a distance of 4m). This "in front"/"behind" cam behavior mostly follows the avatar's rotation about the Z axis except when the avatar is facing straight down or straight up which results in the cam being off to the side of the avatar. Or something like that.

In "Front View" mode, the cam starts out almost level with the seated avatar's center, 2.2m in front of the avatar, so a "Front View" cam positioned and focused where it would be with "Rear View" will jump to a slightly lower focus when the arrow keys are first pressed. This is detectable and a couple points on the rotation should be enough to solve for the focus point of any starting cam view given enough geometry calculations, but I'm sensing these "Views" could be viewer-specific. Also, the little "about" and "mostly" deviations here remind me of the complexities of how a sit target is reflected in the seated avatar's actual position—although I certainly haven't tried that hard, hoping that this is all known already if only I knew where to look.

Anybody know where to look?

[Frionil Fang]

Don't know how much help it would be, but Firestorm phototools->aids (Alt-P) has "Show Detailed Camera Position Data" which is probably a generic debug setting, just made more accessible via a checkbox in this viewer.

It shows the camera's (global) position and axis which appear to change when seated on a non-camera-scripted object so it might get you something though?

Edited August 27, 2022 by Frionil Fang

[Qie Niangao]

Thanks, that's interesting. The numbers in that readout are in some coordinate space alien to me, but it got me thinking that the viewer must be driving all the camera parameters that represent "Views", and indeed there's a handy control that not only allows selection among the views but also defining your own. I remember thinking it was a big deal when these controls appeared on all viewers—and then I never touched them again. For the purposes here, the detailed manual settings dialog (goes by different names in different viewers) reveals the precise focus point (kinda) and allows anybody to adjust their cam focus to an arbitrary point, then save that as a preset.

Problem is, scripts only llGetCameraPos and -Rot, and to solve for the focus point I think we'd need two readings of those numbers as the cam orbits, and once the cam moves it's too late.

Thing is, this now seems a fool's errand anyway. Even if I managed to match the View's focus point perfectly (so the seated cam won't jump when an arrow key is pressed), I'd need to find a cam position to use that focus point and still show the part of the scene (/avatar) that should be in view—which may not even be possible for some Views.

So now I'm thinking there may be something funky with the whole logic of how those arrow keys operate the cam: if I set a cam focus point, why don't the arrow keys simply orbit the cam about that point, rather than whatever they're using instead to cause this starting jump? Hmmm.