Viewport is like a transparent tray in the modelling space
A viewport is defined around a viewport origin. Viewport origing is a user defined point somewhere in the modelling space. Usually the definition happens as a "by product" of view manipulation so, that the user is not necessarily concious about the definition.
All the view manipulation actions happen in some relation to the viewport origin. To be able to work furter more definitions are needed. The viewing point is the point, where your "eye" is calculated to be in the modelling space. The viewing point is sometimes referred to as "camera", though I'd like to reserve the word camera to be used only in the context of a rendering camera.
Viewport definitions
The viewport axis is the line or the vector from the viewport origin to the viewing point. The viewport plane is coincident with the viewpot origin an is normal to the viewport axis. You could think that the image you see on the computer screen is projected onto the the viewport plane, which is then sent to the computer screen.
Sometimes we may talk about the view cone, that presents the limits of the part of the modelling space, that is projected for the user. The view cone of course extends to infinity, but the presentation above seems easier to handle.
The perspective mode means, that the viewing point is somewhere relatively close to the viewport origin. The distance is defined by the view angle. Typically that is the vertical angle of the view cone.
Viewport modes and view angle
Here the use case is that usually I like to use a relatively narrow viewing angle -- around 10° for modelling. That helps to see the 3D-form of the model better than plain parallel mode. A larger angle (maybe 30° to 45°) is useful if you need to work inside a model and the viewing point needs to be close to your working area.
Alternatively there could be a three-way toggle for parallel, perspective_narrow and perspective_wide. Though, the narrow - wide switch is propaply obsolete to most users. It's more usefulto have the angle setting easily available. The setting will be used more as the using does not include browsing throug a complex pile of menus.
Pan and rotate
To rotate the view, you again turn the world as if there was a large sphere attached into the center of the viewport. Now the viewport is turning around it's own origin. This rule natuarlly applies to tilting the viewport as well.
Zoom center is the viewport origin
Possible implementations:
The sequence of using the command is typically, that you point something on the scene and hit the command. Additonally or alternatively there are possibilities to center the viewport to a selection, the entire model or the coordinate origin.Center click (by mouse) Right click Two-button click (eg. hold the right mouse button down, point the place and click with left**) The first menu item
** This should be in line to the panning function: If you pan with the right button, you start centering with the right button
My definite favorite is this:
The viewing point stays where it is. The viewpoint origing moves to the new location. The viewport does not tilt during this operation. The rest of the viewport is redefined by the above.
Centering/focusing the viewport to a new target
Why so? The use case that I'm thinking is, that you are working on a small object close to your viewing point. Then you decide, that you need to go working on something big relatively far away from you current position. You definitely do not want a closeup of the new location and you'd probably want to keep track of your orientation and the feel of location in your working space. The method above provides all that.
You may notice, that from the mathematical point of view the definition in perspective mode actually applies to parallel mode as well. In the parallel mode the viewing point just is very far, though in the programming the zero angle and the infinity distance probably need to be handled as a separate case.
This has a great meaning, when you are working on the edge of a large scene or a large model. You don't need to go collecting your new pieces from he zero-coordinate planes afterwards.
The ones marked with bold font are built-in in the userinterface. The rest of them probably need to become menu items. I strongly recommend that all the viewport commans are collected under a "View" menu. They are frequently used and easy acces to them is crucial to the usability. Also, in addition to the list above, there are quite a few viewport properties, that would have their settings under the view menu, like color- and lighting settings for the modelling space.Pan (or Move along the viewport plane) Rotate (around viewport origin) Tilt (around viewport axis) Select viewing direction (Front, Back..... As defined by Rotate and Tilt) Center (to pointed object, surface or point) Center to selection Center to scene Center to origin Zoom in/out Zoom to selection (also centers) Zoom to scene (also centers) Toggle mode (parallel, perspective) Set viewing angle (for perspective mode)
This happens, when you have the viewpoint origin on an object and you try to zoom through the viewport plane to a new location. As you keep trying to zoom in, the viewport just becomes smaller and your attempts to zoom and pan get less and less effective. Eventually the viewport dimesions are reduced to zero and then you can not even zoom back.
To release the block you just need to center/focus the viewport to a new location. Some software also seem to recognize a zoom block and release it after a few vain attempts to use the zoom. I'll try to cast some more light into this issue in the "Assisted Functions" section.
If it becomes inavoidable in the programming, that the center of rotaton is separated from tne viewport origin, then some "intelligence" should be added to the programming, so that the preferred behaviour is resumed as a result of normal view manipulation. Some suggestions, that might help may be found in the "Assisted Functions".
How does it vork then? Simply it calculates, which is the closest 1/4 of circle for each of the x-, y-, z-rotations and turns the viewport to that orientation. To clear any doubts, this also covers the tilt angle around the viewport axis, so if I have a reason to view the model on it side or up side down that happens by a key-click. (And believe me, 3D-modellers just love the lack of gravity in their modelling space.)
For the alignment fuction to work, no predefined names/numbers for the possible orientations are required. However, this does not make the standars viewing directions completely obsolete and for the user's comfort, if the standard viewing directions are already defined, it would be nice if the named orientations would be recognized and displayed if such a filed or an icon is available on the userinterface.
If the numberpad is already taken, the Home-, Arrow-, PgUp- and PgDn-keys could be used instead. These would also be a better choise for a lap-top computer, that does not have a separate number-pad.Center-key (5): Align to closest "Arrow" keys (4,6,2,8): Switch to the next alignment in that direction Low left key (1): Tilt left Low right key (3): Tilt right 7 and 9 could the be assigned for other purposes or used as doubles for 1 and 3
Also, it should be noted that, the rotate and tilt functions are accessable directly, without first having to use the Align to closest-function. The function of each key should simply be "Align to the Closest Main Orientation in that Direction".
For the alignment and the browsing animated transition instead of a "snap" would be highly appreciated. The duration of the turn should be relatively fast though. About 0.25 - 0.50 seconds does not seem to slow the work down, but the visualization allows you to follow, what is happening on the screen.
One more issue to avoid misusnderstandings: The align functions should work in the inverted way in comparison to rotating the view by mouse or a 3D-navigator device. Whereas by mouse you think, that you rotate your model, the arrow-kwys should rotate the viewport. So eg. if your viewing direction is "Front" and you press "Arrow Up" then the viewing direction is changed to "Top".
At first it seems like a self evident thought, that the viewport should be focused, where you work, but as you start to design the function to the viewport there will be questions, that need to be answered first. Questions like, "Should the viewport be automatically centered to your selected element?" A short answer would be "no". The viewport becomes very restless, if it moves everytime you select a new object or element in the modelling space. However the first step of intelligence can be built upon this idea.
The center of the active selecton should be defined the "pending point of focus". Then, when you start to navigate your viewport, the viewport gradually centers it to the pending point of focus. The viewport actions that could contain the assisted centering are Zoom In, Rotate and Tilt. Zoomin by 50% in or turning the view 90° should result centering.
The sequence of Centering actually consist of three steps:
1) Defining the pending point of focus
2) Moving the viewport plane to match the depth where the new poitn is located.
3) Moving the viewport towards the point of focus as defined by the current fraction of zoom to turn.
It seems, that to get this operation performed correctly, another step needs to be added between 1 and 2: To record the viewport location, size and orientation in the beginning of the operation.
The question still remanis, how the viewport should behave in the case of zoom in. As this is a centering operation it probably should not just move along the viewport-plane, but at least to some extent, turn around the viewing point as described in the Basic Functions, Centering.
The the basic functionality is simply, that when the newly picked element is outside a predefined center area of te viewport, the viewport responds by moving into that direction only so much, that the recently picked element is right on the border of the center area. The center area could be defined as about 65%-80% of the width and height. -- Whether the center area should be a rectangle or something else, is another discussion, but I'd start with something "rectangleish".
As this function obviously is related to the centering function, it also might be worth of consideration if the viewport should again turn around the viewing point rather than just travel linearly. My recommendation, that is a kind of a combination of those both would be:
This behaviour shoud turn out to be quite robust, if the view angle is relatively narrow, as I would anticipate in modelling use. The purpose is that the viewport moves like car being parked, without changing it's size or view angle. This behaivour would not mess up the users zoom settings as the use of zoom or centering commands could in the case that the selected objects are on very different distances in "viewpot depth" direction. Also the viewport origin would in most cases find a seemingly logical new "average" location in the space.Calulate the the new axis direction so that the latest selection is just inside the centerarea Calculate the movement in viewport axis direction (after the turn) as the same fraction of the total difference in depth as the turn was in relation to the width and/or height of the view cone. Double check the turn and correct if needed. Perform the move.
Animated transitions are pretty much obligatory in this case. A jumpy view would easily be very disturbing to the user.
Below is embedded a video that illustrates the function in action.
The transition time in the video is set to 0.4 seconds with accelerated/decelerated action. -- In robot kinematics that was known as parabolic smoothing. The center area (that btw. should not be displayed to the user as it is on the demo) in there is defined as 2/3 of the screen in x-direction and 3/4 in y-.
Not to forget the complexity of the problem, the user may as well be trying to travel through a hole of an object that the viewport was centered to just a moment ago. Though this situation may be tricky to recognize, the information already is there: It is projected on the screen. So again there should be a predefined center area -- probably an oval or ellipse this time -- and when there is nothing to zoom to on this area, the logic picks a new object, that appears in the center of the viewport to be the new point of focus.The viewport has become awfully small (But how small?) There is nothing on the viewport plane to zoom to The user still keeps zooming....
Now the only problem left is, that the user might be zooming towards "nothig". In that cas the simplest solution would be to let the viewportplane move forward instead of scaling it. It should also be possible enlarge the "scanning angle" and measure the distance to the first object that is found to be the new lenght of the viewport axis. Or if that turns out to be impossible and no other obvious plan comes up, notify the user to take appropriate actions to reset the viewport size.
There of course are cases, where no logic really applies. How about if the user goes zooming in empty space? It's of course possible to use some kind of defaults to to take over in the the extreme cases, but generally speaking I would not worry about surviving intentional abuse as long as it does not damage the model file.
There are, however, some details in the behaviour of a camera, that make it different from a viewport. First, the view angle setting does not move the camera, but just changes the perspective angle of the camera. Also the user can turn the a camera around itself, where the viewport can only be turned around the viewport origin.
If the software provides a "physical" presentation of a camera (i.e. the camera is treated as an object in the modelling space) activating the camera specific behaviour is easy. Just select the camera or launch it for editing it's properties. If the software does not present cameras in the space, the job gets a bit trickier and the camera settings are found somewhere in the view menu. Which approach is taken, depends on the purpose of the software. Both are used.
Generally speaking the normal navigation of the viewport should follow the same rules as the navigation without a 3D-device. Center the wiewport, rotate always around the viewport origin etc... To avoid blocking the zoom I'd recommend a logic that, when there is nothing to zoom to, the viewport is not getting any smaller by zooming in, but rather just starts to move forward.
Anyhow, according to my own experiences, you are less likely to run into a zoom block by using a 3D-device than you would be when zooming by mouse. I'm not sure if that is due to smart UI-design or just, that the dynamic viewmanipulation keeps you better aware of the behaviour of the viewport than navigating by mouse does.
What I wish the readers to make note of, is that the user wants to keep the viewport focused on the thing that is under the work. Change of focus should be easy, but strictly under the user's control. Users tend to do stupid things, but as a user I'm willing to learn my lessons in exchange of control over my working.
Also the 3D-navigation tools, that are nowadays available and affordable to an increasing number of users, provide many new possibilities. Being able to work with both hands however, seems to raise up several issues, that did not exist while working just with a mouse. To start with, a left handed user would most likely prefer to use the tools with a somewhat different set of functions than an right-handed one. And there is more to come: There are already available some devices (finger pads ...) that are capable of gesture recognition. Currently the industry is already discussing optical gesture recognition, which should eventually enable working in 3D just with your bare hands!
Still, what ever the development will be in the future, the basic definitions of the viewport will always be the key to building a successful 3D-editing software. The approach certainly is different from 2D applications and equally different from entertainment use. I'm hoping that this story on it's part will help future software developers to understand the a modellers point of view on the matter.
-Petri-
Created, 01-Jan-2009
Published, 03-Jan-2009
Updated, 04-Jan-2009