[Bf-committers] new features without release log

[Ben Stabler]

Hi, 

"From the angle at the tip of the pyramid, you can derive the zoom factor."

I still don't understand how this is possible; if you imagine a large cube
beyond a smaller cube, and use alt-b to draw the pyramid around the cubes
from the camera, they can both 'only just' fill the cross-section of the
pyramid, even though one is far larger than the other. If the sides of the
pyramid are at normals to the camera, how is it possible to calculate the
correct offset? The angle at the tip gives the zoom factor of the camera,
but I don't understand how that tells you how far along the pyramid the user
intends to 'zoom' to (keeping in mind that the center of rotation is pretty
much irrelevant at this stage).

"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)"

Ok, that's probably a better method than mine.

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

Yes, but this would break if the user is working on a large scene, and wants
to zoom into a small detail- the zoom factor is large because they are
rotating around a large scene, and dollying towards a detail won't change
the zoom factor (as it is a translation not a zoom), so the camera would be
likely to fly straight past the detail.

Hmm, this also feeds into the last point- if the user zooms into a detail,
and the center of rotation is as far past the detail as the camera was
previously, then you can't really rotate about it once you're zoomed in on
it.

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

Well, this has to happen in some way, as by definition both 'zoom to cursor'
and 'border zoom' are going to translate the viewport center to some extent.

Of course, I'm neither an interface expert or particularly good at coding
either, so these are just thoughts!

Ben

-----Original Message-----
From: bf-committers-bounces at projects.blender.org
[mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Martin
Poirier
Sent: 18 December 2006 01:46
To: bf-blender developers
Subject: RE: [Bf-committers] new features without release log

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 
_______________________________________________
Bf-committers mailing list
Bf-committers at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-committers