Add basic orbital camera implementation by maaxxaam · Pull Request #37 · OpenAWE-Project/OpenAWE

maaxxaam · 2024-01-05T11:23:50Z

The aim of this PR is to resolve #13 by adding a mouse/gamepad controlled third person camera that orbits around player character. Camera's features include:

Orbiting around and following player with smoothing
An ability to switch shoulders
Aiming a "weapon" with changing FOV
An ability to focus camera at a specific point (that should be useful for implementing scripts later on)
Responding to static scenery by shortening orbit radius so character stays in camera's view

maaxxaam · 2024-01-06T10:37:44Z

That's weird: player character seems to start travelling at incredible (around 20 orders of magnitude higher than normal) speeds from the start of the game which prevents me from testing the camera. I did test the code before the PR; however, I also did a rebase onto master right before pushing since my dev branch was 13 commits behind. Could the recent AI additions cause the character controller to break?

Nostritius · 2024-01-06T14:34:02Z

Hi I tested your pr and noticed, that I made an error in the character controller leading to strange walues. It should be fixed in the last commit

maaxxaam · 2024-01-06T16:42:33Z

Thank you for the fix! I've rebased the branch off the latest commit, testing should be easier now.

maaxxaam · 2024-01-23T14:31:41Z

Hmm... That's odd. According to the failed build logs for commit 89fc1b2, it looks as if awe cmake target for Mac has arm64 architecture set while all of the previous targets were built for x86_64, leading to >600 lines of reference errors. I'm not sure that's supposed to happen here - after all, recent mac universal binary commits that could lead to such behavior are not included in this branch yet. 🤔
Upd.: checked out build logs for the latest master commit - apparently, it suffers from the same issue.

Nostritius

Apart from the things, commented I am really thinking, that it would be better to control the camera also from the PlayerController or at least centralize the control of the player into some place, since for example, when you turn the camera around enough, Alan will also turn in that direction.

src/controlledorbitalcamera.cpp

Nostritius · 2024-02-18T11:27:40Z

src/controlledorbitalcamera.cpp

+		_movementRotation.y += axisEvent.delta.y;
+	} else if (event.action == kRotateGamepad) {
+		_movementRotation.x += axisEvent.absolute.x * 10.0f;
+		_movementRotation.y += axisEvent.absolute.y * 10.0f;


Maybe make the rotation factor astatic constant

That constant has appeared during a short period of time when I was able to test gamepad controls with an actual gamepad. While I do agree this should be moved into a named variable, it probably should not be a constant to allow tweaking the sensitivity during runtime (I do not remember whether original games allow this, but that seems like a useful option further down the line).

src/graphics/orbitalcamera.h

maaxxaam · 2024-03-22T15:26:07Z

Alright, I hope I didn't go too much into commenting OrbitalCamera's behavior, but it should explain a lot more choices that were made to make the camera feel better and closer to original game's one.

Regarding the character issue: I actually have a code snippet to do that - it was intentionally left out to make this PR focused on camera only. After what happened to the event handling PR that grew double the size because I kept adding more related stuff to it, I hope that keeping changeset constrained would be the better experience for both of us (if you think otherwise - feel free to say so, I'll add that in).

Moreover, it is not completely obvious where the central place of control should be since we have at least two different ways to look at and navigate the world - through character movement and orbital camera and through free camera. I've been testing an option to make a CameraDirector class that would control storing and switching between cameras as a possible solution, but that also includes changes to event handling (namely, adding an option to remove a callback from action), which should probably be an its own PR really.

Nostritius

Apart from the commented things, I also thought about where to place the controls, and I see your point that it is difficult especially when considering the camera work. Nevertheless, I think, the best way would be to add the orbital cam control to the player controller due to its close relation to the other controls, we have over Alan. The freecam mode should be switchable between orbital cam and freecam, maybe with a kind of enabled flag. If you do not want to do that now, we can only add the high level orbital cam stuff.

Nostritius · 2024-03-29T19:11:38Z

src/physics/physicsman.cpp

 	_world->removeAction(actionInterface);
 }

+const CastResult PhysicsManager::raycastStatic(glm::vec3& from, glm::vec3& to) {


Since you return CastResult by value, you can safely remove const and instead make the method itself const

Hmmm... While I can indeed do that, that seems to go against the reason that const was put there in the first place - to signal that CastResult is not supposed to be changed. As far as I understand, making the method const will not make return type const in this case, because we create it inside the function body

// src/physics/physicsman.cpp:102 return CastResult{ true, rayHitPoint, rayHitPoint }; // src/physics/physicsman.cpp:109 return CastResult{ false, glm::zero<glm::vec3>(), glm::zero<glm::vec3>() };

and not return some field of the PhysicsManager object (which would carry the const modifier of the parent object). However, it is a good idea to mark casting methods const as well since they do not change PhysicsManager.

Yeah, but you return the CastResult by value, which means the const is practically meaningless, since it can be copied. The member consts ensure it stays immutable.

Nostritius · 2024-03-29T19:25:14Z

src/physics/physicsman.cpp

+	};
+}
+
+const CastResult PhysicsManager::shapeCastStatic(btConvexShape* castShape, glm::mat4& from, glm::mat4& to) {


Could you simplify the interface of this method, maybe into a sphereCastStatic, giving simply a float as radius? I just want the bullet stuff to be used exclusively in the physics part. And some comment in the header would also be nice to explain what the method is doing.

Sure thing. This method was left intentionally broad for possible later use with other shapes (the same reason why raycastStatic method is still in this PR despite not being used), but I do agree that passing transformation matrices is cumbersome at the very least.

Nostritius · 2024-03-29T19:27:13Z

src/physics/physicsman.cpp

 * You should have received a copy of the GNU General Public License
 * along with OpenAWE. If not, see <http://www.gnu.org/licenses/>.
 */
+#define GLM_ENABLE_EXPERIMANTAL


You don't need this macro, it is already defined in the CMakeLists.txt

Nostritius · 2024-03-29T19:35:28Z

src/controlledorbitalcamera.h

+
+	Physics::CharacterControllerPtr _followedObject;
+
+	btSphereShape _castSphere;


As I described in another comment, bullet stuff should be exclusively located in the physics part

The idea of this was to avoid frequent creation-destruction of bullet shapes for handling casts (especially because it happens every frame for the orbital camera) by storing an object used for collision inside the camera and passing it as a parameter. This could be instead mitigated by storing a sphere object in PhysicsManager (which seemed inappropriate at the time as you would have to keep changing sphere's radius for each cast) or by creating an object pool for the shapes.

Adds OrbitalCamera and ControlledOrbitalCamera classes. Other changes: - Add CharacterController.getUpperPosition(); - Add _fov field and getFOV() for base Camera class; - Tweak Renderer to use camera's FOV in calculations

- Use sphere to check for camera collisions - Accumulate and smooth user input - Aiming moves camera closer to the character - Shoulder gets longer with the higher pitch - Improve default camera orientation - Adjust defaults to match AWAN's camera better

maaxxaam force-pushed the orbital-cam branch from 5ac28b7 to e78e864 Compare January 6, 2024 10:27

maaxxaam force-pushed the orbital-cam branch from e78e864 to 82e45d3 Compare January 6, 2024 16:41

Nostritius requested changes Feb 18, 2024

View reviewed changes

maaxxaam requested a review from Nostritius March 22, 2024 15:26

Nostritius reviewed Mar 29, 2024

View reviewed changes

maaxxaam force-pushed the orbital-cam branch from 93bacb0 to 27e2167 Compare July 11, 2024 16:58

maaxxaam added 9 commits July 11, 2024 19:59

Tweak pitch limit on FreeCamera to avoid warping

24b47f6

Add raycastStatic() method for PhysicsMan

bbc84fa

Add ControlledOrbitalCamera

8a15aca

Adds OrbitalCamera and ControlledOrbitalCamera classes. Other changes: - Add CharacterController.getUpperPosition(); - Add _fov field and getFOV() for base Camera class; - Tweak Renderer to use camera's FOV in calculations

Move near clipping plane closer

924ae8a

Add PhysicsMan::shapeCastStatic method

a498f6f

Change return type of casting methods to use glm values

4e64b07

Add comments for OrbitalCamera class

1bd9208

Add sensitivity fields for ControlledOrbitalCamera

27e2167


		Physics::CharacterControllerPtr _followedObject;

		btSphereShape _castSphere;

Conversation

maaxxaam commented Jan 5, 2024

Uh oh!

maaxxaam commented Jan 6, 2024

Uh oh!

Nostritius commented Jan 6, 2024

Uh oh!

maaxxaam commented Jan 6, 2024

Uh oh!

maaxxaam commented Jan 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nostritius left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

maaxxaam commented Mar 22, 2024

Uh oh!

Nostritius left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nostritius Apr 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maaxxaam Mar 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

maaxxaam commented Jan 23, 2024 •

edited

Loading

Nostritius Apr 4, 2024 •

edited

Loading

maaxxaam Mar 30, 2024 •

edited

Loading