[sldev] Camera/Picking Patch

[Jason Giglio]

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

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

I'm still not seeing this one.  I can't get my FOV zoom to stick in any 
way that it wasn't doing before.  Could this be just because you've 
moved the entire prim through your near clip (by panning so you are 
inside looking out) and can't see it anymore?


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

OK, I can add back in the center biasing.  I'd like to add it into a 
different area of the code though, it was really doing it in the wrong 
spot before.  I'd like to have an accurate picking method, then munge 
the spot as needed elsewhere.  That way we can have accurate picking if 
we need it (which we will, I'm sure).


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


I have an idea to add point of interest clipping protection back in, 
without enabling the old bounding box constraint.  I'll work on that.

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

I'll test that out and fix it too.

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

Alright.  Maybe I'll turn off the clipping constraint if camera 
constraints are disabled then.


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

Usually. :)

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

If you think we aren't, then that's good enough for me.  I think I can 
press forward with this and add some smarter constraints back in to 
satisfy these specs, without breaking the stuff that is made better by 
this patch.

-Jason