[Bf-committers] new features without release log

[Martin Poirier]

Hi Ben,

--- Ben Stabler <ben at half-dome.net> wrote:

> Those were originally my patches, and I've been
> meaning to fix them but I've
> had very little time and my maths still isn't quite
> up to scratch...
> 
> Some questions about your suggestions:
> [1]: Is a pyramid necessary- would taking a vector
> from the center of the 4
> corners of the rectangle have the same effect?

No, it wouldn't. A pyramid is important because it
gives you information about the zoom (the angle at the
top of the pyramid) and the orientation (the rectangle
base of the pyramid)

You can sort of see that with view port clipping
(Alt-B). If you move the view afterward, you'll see
the pyramid corresponding to the box selection you did
earlier. (this examples shows the orientation factor)

If you change the lens setting of a camera, you'll see
its pyramid representation get more or less pointy.
(that's for the zoom representation)

>     - How do you know how far to zoom; the pyramid
> could describe any
> position along the vector

>From the angle at the tip of the pyramid, you can
derive the zoom factor. I'm not sure how yet but maybe
someone on the list will suggest something.

> I believe a depth test will be necessary at some
> point here, we have to
> assume that the user is zooming towards the first
> thing they see- but where
> do we do the depth test from? Is it from the center
> point of the rectangle,
> or the corners? What if they're zooming towards a
> sphere (no corners), or a
> torus (no center)? Where do we place the center of
> rotation- on the surface
> of the target, or at it's center?

That's assuming you even want to do a large correction
on the viewport center of rotation. My opinion would
rather be that you should just adjust it's position in
3D space to keep it the same relative to the camera
(Like in fly mode)

> Possibly we could simulate a plane traveling away
> from the camera and test
> for collisions, but would this be efficient?

A cheap way to do it would be to fake a box select and
take the median of the selection. Not sure that's
really what we want though.

> [2]: The problem here is that I don’t want to
> hardcode figures for how far
> the camera dolly's- at the moment the mouse-wheel
> zoom is based on a
> percentage from the center of rotation, but a dolly
> wouldn’t have a center-
> I think we would have to use another depth test
> (this would be easier than
> [1] because we would just target the cursor
> position)
> 
> But.. what happens if the user dolly's towards empty
> space?

I'm not quite sure I understand the problem here,
can't you just dolly by a certain amount proportional
to the wheel movement and the zoom of the viewport
(prior to the current zoom operation)?

> Also- if we're dollying close in to a surface, and
> the center of rotation is
> miles past the object, what happens then? If the
> user rotates the view it
> will all screw up... Desired behaviour would be that
> the center of rotation
> would attach itself to the surface with the first
> increment, and further
> increments zoom in... I think...

Is that really the desired behavior? I mean, when I
set the viewport center manually, I'd be pretty pissed
if zooming on something messed it up. But then again,
I'm not the interface expert here, others have the
final say on this matter.

Martin

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com