Camera movement

Involved development of the OpenMW construction set.
Post Reply
anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

Camera movement

Post by anahuj »

Hi. In FPV mode, I'm able to rotate the view to down but not back up. Something wrong there.

In free mode, the orientation gets messy - as happens in any trackball based camera system. After the orientation is messed, are other modes useless because the orientation does not reset. What if we stick to camera which always stays vertical? Like in CS.

Movement and rotation speeds needs adjustment as you may have noticed but more on them later.

v 0.32.
anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

Re: Camera movement

Post by anahuj »

In orbital mode, the rotation amount is larger when near the rotation point, and smaller when a far away. In any case, orbital mode is bad as now. It would be better to have the rotation angle related to the pointer movement. Like half window would be full rotation. Don't remember what values are in my viewer, but no problem there.

The orbital mode has that trackball effect too: the orientation is messed pretty quickly. Trackball seems to be very bad invention; it is cool because it uses quaternions, but disorientation has always been there from day one.

My viewer implements the camera described in article Nested Transformations and Blobby Man, by Jim Blinn, IEEE Computer Graphics and Applications, October 1987, if I remember correctly. There are no need for separate modes: when zlook > 0, it is orbital; when zlook = 0, it is FPV. Just one compact camera formula. I have implemented UnrealEd type camera and turntable camera (orbital, always vertical) in one go.

Plus, this camera can be used in the game as well, because switch between FPV and third person view is handled with this one camera. In Skyrim, the camera looks slightly over the shoulder. That is possible too, but I need to test it for movement and aiming.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Camera movement

Post by Zini »

I am not sure if I agree with everything you wrote, but our camera movement implementation definitely needs further refinement. What we currently have is meant as a first iteration anyway. Values will be adjusted we we are still missing a bunch of features. Also, some of your findings sound like bugs. We will take your comments into consideration once we get back to this feature.
Post Reply