[sldev] Camera/Picking Patch

[Richard Nelson]

Thanks for tackling this.  Those camera bugs have been around for a while  
and it's past time someone fixed them.  However, I'd like to point out a  
couple of existing behaviors that were eliminated, and the original  
rationale behind them.

1.  Cancelling FOV zoom when panning away from an object.  The intent was  
to avoid getting in a situation where you are staring off into space with  
a really tight FOV (and the only way out is to hit Escape, if no other  
object is in view, for example).  In practice, however, this limits  
zooming and panning around small objects and it really only an issue for  
advanced users who know how to pan the camera anyway.  Your solution to  
this looks good, but I'd like to gather more feedback on the fov problem.

2. Shifting the focus point towards the center of an object.  This is a  
subtle heuristic.  The idea is to treat an object as a whole when the  
camera is far away from it (relative to its size), and pivot around its  
center of mass (or the equivalent part of the object that fell under your  
mouse cursor).  This has the benefit of keeping the object centered on the  
screen and under your mouse cursor for easy retargeting.  When zoomed in  
closer to the surface, however, we assume the surface is the point of  
interest and use that as the pivot point.  The goal is to support tumbling  
the camera around an object as a whole as well as pivoting around smaller  
surface features, without having to think about it.

3. Avatar zoom limits.  This is another tough one, again with two  
contradictory user experiences we want to support.  First, less  
experienced residents who want to look at an avatar more closely, and  
second, those who need to examine or edit small attachments.  When  
learning how to alt-zoom, it is way too easy to slam the mouse forward and  
have someone's eyelashes filling the screen or, worse yet, seeing inside  
the avatar's head.  It was disconcerting and considered user-unfriendly  
when our original camera behaved that way.  However, I can understand the  
desire to examine attachments very closely, and it's unacceptable to not  
be able to zom in tightly when editing an attachment.

Perhaps we can enable close-up views of avatars/attachments while in build  
mode, allowing you to find attachments inside your body, etc?  Or maybe  
tighten the minimum camera distance from avatars to a more reasonable  
value?  Regardless, we shouldn't treat attachments and avatars separately,  
as the two tend to blend together and the distinction will be lost on many  
of us.

That said, we should definitely fix the zooming on hollow objects bug.  I  
think it can be done while conserving some or all of the above behaviors.

R.



On Tue, 16 Oct 2007 21:27:31 -0700, Jason Giglio <gigstaggart at gmail.com>  
wrote:

> Here's the patch!
>
> This patch fixes VWR-1286, and VWR-98.
>
> This patch redoes the minimum camera constraints to allow zooming on  
> hollow/cut/twisted up prims correctly, and improve zooming on  
> trees/grass/other weird stuff.
>
> As part of this, it was necessary to overhaul and simply the picking  
> code.  This patch is a significant improvement in the picking code.  
> There's a lot left to be done in terms of cleaning that up so that it  
> can be used for other neat things (like the LSL UV touch), but this  
> patch brings that closer.  I'd like to wait for this patch to get in  
> before I do any more work cleaning up the picking code.
>
> Notes:
>
> 1. Alt-zooming on nametags is still weird. It was already weird before,  
> so it's just a different kind of weird now. If anything, it's a little  
> more tolerable.
>
> 2. The camera is no longer constrained to the bounding box of the focus  
> prim or avatar.  This is intentional. The only way you can see this is  
> if you zoom all the way in, and then pan up or down, left or right, to  
> force your camera to intersect with the prim or av.
>
> This is a desirable behavior in a lot of cases, as it is near impossible  
> to get lost attachments out of your body with the current constraints.
>
> When doing a straight alt-zoom, the behavior is similar to before, the  
> camera will not penetrate the focus surface.
>
> Note that it was always possible to pan other prims (even in the same  
> linkset) through your camera in this manner.
>
> 3. I have written a test script for this patch and for camera  
> constraints/picking in general:  
> https://wiki.secondlife.com/wiki/Camera_and_Picking_Test
>
> It is not complete, as it is focused on this patch and the issue it  
> touches mainly. It should be expanded to cover all the functional specs  
> of the alt-zoom feature and the camera control feature.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html