## Proper 3D navigation in CS

Feedback on past, current, and future development.
anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

### Proper 3D navigation in CS

Please implement what you see in the official CS. Now it is easy to get the world disoriented and even upside down, in 0.39.

A good camera system is described in Jim Blinn's article Nested Transformations and Blobby Man. It is possible to write one camera code which handles both 3rd and 1st views seamlessly (like in the games). It is possible to implement one camera code which handles both drive and orbit mode seamlessly. All four in one code.

The trackball/arcball rotator must be the reason for disorientation. Clever quaternions math but sucks big time with its disorientation. In every 3D toolkit demo.

I have implemented the proper system in my simple test program. Moving the pointer in screen-X direction rotates one angle; moving the pointer in screen-Y direction rotates another angle. When I start rotation in screen position (x,y) and end up to the same screen position (x,y), the scene is in the same original orientation. That does not happen in openmw-cs now.

anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

### Re: Proper 3D navigation in CS

Here are codes from my implementation.

Here is the code which reads pointer position and applies it to rotation angles. Screen pixels are directly mapped to angles.

Code: Select all

``````    back += 0.5*p->movedy;
spin -= 0.5*p->movedx;
``````
Here is the camera code. First part has all the camera parameters - I have commented out parameters which I have turned to interactive parameters.

In orbit mode (clay modeler's table), xyzlook is point at center of table, in world space. zlook = 0.4 means the camera looks higher point in the clay pot. xyzscr tells where look-at point is mapped to screen. zscr = 2.0 means the clay pot is seen in front of view; zscr = 0 would mean that the camera is inside the clay pot, exactly at the look-at point.

In 3rd person view, xyzlook is the position of the player character - zscr > 0. In 1st person view, xyzlook is the position of the camera - zscr = 0. The seamless transition from 3rd person view to 1st person view, like in TES/Fallout3+ games, would be made by fading zscr to 0.

In Construction Set, we may select an object, and rotation happens around that object. I have not worked out this part at all. It gets complicated: xyzlook would be set to the center of the selected object, and xyzscr + spin + back needs to be recalculated so that the view is not changed. Right?

Spin parameter rotates the camera horizontally - looks left or right. Back rotates vertically - looks down or up. Tilt is that unwanted parameter in Construction Set style scene arranger.

You may look at the original article because I made one change in this camera code (scaling by 1,1,-1). Could be I made a mistage and fixed it by this scaling.

Code: Select all

``````  fov = 50.0;
xscr = 0.0; yscr = 0.0; // zscr = 2.0;
// back = -75.0; spin = -30.0;
tilt = 0.0;
// xlook = 0.0; ylook = 0.0; zlook = 0.4;

// Interactive parameters.
zscr = p->zscr;
back = p->back;
spin = p->spin;
xlook = p->xlook;
ylook = p->ylook;
zlook = p->zlook;

pers(fov);
camera_fov(global_camera,fov);
camera_pers(global_camera);
tran(xscr,yscr,zscr);
rotx(back);
rotz(spin);
rotx(tilt);
tran(-xlook,-ylook,zlook);
scal(1.0,1.0,-1.0);
camera_pos(global_camera);
``````

psi29a
Posts: 4692
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

### Re: Proper 3D navigation in CS

If you want some better feedback, send a PR on github with your changes. It allows others to try your branch out for themselves.

anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

### Re: Proper 3D navigation in CS

Here. All modes have the fixed up axis. Would that work? Anyone need the arbitrary tilted world? Maybe new checkbox in preferences to select.

Code: Select all

``````void SceneWidget::selectNavigationMode (const std::string& mode)
{
if (mode=="1st")
{
mCurrentCamControl->setCamera(NULL);
mCurrentCamControl = mFreeCamControl.get();
mCurrentCamControl->setCamera(getCamera());
mCurrentCamControl->fixUpAxis(CameraController::WorldUp);
}
else if (mode=="free")
{
mCurrentCamControl->setCamera(NULL);
mCurrentCamControl = mFreeCamControl.get();
mCurrentCamControl->setCamera(getCamera());
mCurrentCamControl->fixUpAxis(CameraController::WorldUp);
}
else if (mode=="orbit")
{
mCurrentCamControl->setCamera(NULL);
mCurrentCamControl = mOrbitCamControl.get();
mCurrentCamControl->setCamera(getCamera());
mCurrentCamControl->fixUpAxis(CameraController::WorldUp);
}
}
``````
Please check the original code for comparison.

Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

### Re: Proper 3D navigation in CS

Sorry, I don't want to sound like I want to step on your toes. But I am very much in disagreement with your initial statement. We started with the assumption that the original CS is rubbish. I have used the navigation system in it extensively and my conclusion is that we do not want to have it in our editor, because it is really bad.

Now I admit that our current system needs some more improvement, but the original CS is generally not the way to go.

Regarding the fixed up axis: This is problematic in some modes, because it would AFAIK interfere with navigating in upside down position. It seems we have fixed up axis in 1st person mode. We definitely should not have it in free mode. An user settings option to enable/disable it in orbiting mode would be acceptable, though what I originally had in mind was a function (bound to a configurable key) that uprights the camera on demand. Maybe having both would make sense.

Maybe we can pull aesylwinn into the discussion, since he wrote the new camera system (according to my specs). He should be way more familiar with the situation than either of us.

anahuj
Posts: 31
Joined: 29 Dec 2013, 03:26

### Re: Proper 3D navigation in CS

I tried to move-on and start editing - giving feedback along the way on other features. But disorientation problem makes that all impossible. I would be happy with quick fix as preferences toggle.

What is the problem in original CS? Only problem I have found is the view movement with middle-button: the scene should follow the pointer - now the scene comes slowly behind, so annoying.

aesylwinn
Posts: 243
Joined: 14 Dec 2015, 20:30

### Re: Proper 3D navigation in CS

If I remember correctly, the only difference between the 1st person camera and the free camera is that the 1st person camera has a locked up axis. Fixing that axis in the free camera mode would make it rather pointless.

There was a discussion about fixing the up axis for the orbit camera mode as well. However, this idea was discarded for a couple reasons:
1. It did not fit with the original design for the system. It makes more sense to add another camera mode that is specialized for traversing terrain (which is where you want a fixed up axis).
2. The orbit camera is also used for the preview camera. A fixed up axis would be a major hindrance when examining models for defects in the preview mode.

Zini
Posts: 5536
Joined: 06 Aug 2011, 15:16

### Re: Proper 3D navigation in CS

@aesylwinn These are good points.

@anahuj For example working upside down is a pain in the arse. Spend a few hours decorating ceilings and you will start to curse the original CS too. Binding the orbiting mode to the selection as the CS does is also hugely problematic, because it limits the usefulness of that mode a lot (can't keep the nice orbit around the centre of your work area while working on other objects). That's all I got from the top of my head. Would have to go back to the CS to give more details.

wareya
Posts: 338
Joined: 09 May 2015, 13:07

### Re: Proper 3D navigation in CS

There is a particular problem with the first person camera in openmw-cs 0.39: The horizontal sensitivity changes as you look up and down.

>For example working upside down is a pain in the arse.

The current free camera and orbit camera aren't using the only way to make this less horrible. Adding a true drag mode (as opposed to panning) would work too. My favorite way to move around large open world maps is by dragging (i.e. the material at the clicked location stays on the same onscreen location) and flicking the ground with the vertical axis position locked. A general purpose drag would probably not lock the vertical axis, but the "depth" axis instead.

It might be nice to lock the orbit camera's roll axis and give it a depth-locked drag or something. To me, orbit camera seems like it would be most useful for editing cities/villages, where you're always looking down at an angle. If you want to spin there, you don't want the world to tilt.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

aesylwinn
Posts: 243
Joined: 14 Dec 2015, 20:30

### Re: Proper 3D navigation in CS

wareya wrote:The horizontal sensitivity changes as you look up and down
I never noticed that until you mentioned it. It's a side effect of me trying to use some of osg's functions to simplify everything, but I guess that needs to be reworked at some point.

The camera system you described sounds like what is used in an RTS. I would like to see that as the camera specialized for terrain maneuvering.

@Zini
Perhaps the 1st/free camera modes should be merged into one option. A key could then be used to toggle if that camera is fixed or not.