[sldev] Camera/Picking Patch

[Richard Nelson]

On Thu, 18 Oct 2007 13:53:46 -0700, Jason Giglio <gigstaggart at gmail.com>  
wrote:

First off, let me say that I manually applied your patch, as I couldn't  
get my subversion tools to do it automatically.  So there is a possibility  
I am seeing different behavior.

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

When your focus points moves outside of the bounding box of the object you  
are focused on, the FOV would reset to it's nominal value.  With your  
change, this never happens and FOV zoom is "sticky".  I think that's  
probably ok, I just wanted to point out the difference.

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

Sure, focus on a medium side object with some amount of volume to it (not  
a thin wall), and move the mouse left and right to rotate the camera.   
With the center biasing, the camera will pivot around the object's  
middle.  The object will stay centered on your screen when you rotate, as  
opposed to pivoting off to one side.  Specifically, when rotating around  
to the back of the object, your camera stays a constant distance away from  
the object bounds, instead of seeming to get closer because the pivot  
point is on the other side.  Like I said, this is a subtle heuristic, but,  
I believe, a noticeable improvement.

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

Yes, I agree.

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

Sure, but I wouldn't say vast majority.  For example, right now in my SL  
window almost every thing I see (LL conference room) has a large prim that  
I can yaw the camera around and the bounding box will work.  Chair backs,  
table top, signs, etc.  Tendencies to build in the vertical with a minimum  
number of prims tend to align with this heuristic.  More importantly, it's  
your point of interest (roughly equivalent to the prim you clicked on)  
that we protect from clipping, which is often the most important and  
largest thing on your screen.

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

But if you zoom in on an attachment, you get the object zoom behavior, at  
least with my build.  My avatar is covered in attachments, so any time I  
try to zoom in on my avatar, my camera gets too close.  Maybe this is a  
bad merge on my part.

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

First, I don't think everyone who is comfortable with alt-zoom doesn't  
care about camera clipping.  Second, I have seen enough user tests to  
convince me that spinning the camera around, inadvertently or not, is not  
uncommon.

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

Actually, we have tight-fitting ellipsoids for the avatar skeleton that we  
use for animation constraints on our built-in animations.  There used to  
be a visualization mode in the client to see them, but it appears to be  
broken right now.  Regardless, the ellipsoids should work.

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

Fair enough, the old code was begging for a cleanup.  But a lot of what  
you removed was tied to bounding box clamping.  I just want to make sure  
that we are clear that we are better off without it.

R.