[sldev] Camera/Picking Patch

[Jason Giglio]

Richard Nelson wrote:
> 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 

The FOV zoom works the same way it used to, not sure what you mean.


> 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.

Can you give me a specific case that this is supposed to fix?

It's really two different things, the center biasing and the bounding 
box constraint.  We can have one without the other without problem.

Note that since the bounding box constraint only did a single prim, it 
really didn't accomplish much of anything on multiple prim linksets. 
Close-up orbiting those still moved other prims in the linkset through 
your near clip.  I would think the vast majority of use cases here are 
going to be on link sets, not single prims.

> 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.
> 

The Avatar zoom limits are similar to what they were before.  The only 
difference is when panning around.  You still can't zoom straight into 
an avatar and wind up too tight.

The only way you'd wind up close or inside an avatar is if you zoom all 
the way in, and then pan up or down, not something many new users would 
be doing.

> 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?  

Because the avatar box is so approximate, we really can't reduce the 
basic zoom limit any more without running into what you described above, 
slamming into someone's head, etc.

> 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.
> 

Right, this patch treats them together like the old one did.

> 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.

I would like to move forward from this patch, rather than going back.  I 
think I have a good idea how I can add some or all of these constraints 
back in, while still preserving the fixes and massive cleanups in this 
patch.

-Jason