Adding collision to non-third person follow types

[ghostsoft]

I discovered that the "Group Follow" mode makes for an excellent target camera similar to the Z-targeting in the Zelda games, but it comes with the huge downside of not having a spring arm with physics collision like the Third Person Follow has and will thus just clip right through the walls and floors.

Is there any easy way for me to add this or is this something I would have to edit the source code in order to do? I tried parenting it to a spring arm but that did nothing, presumably since the script sets the position manually.

Fantastic addon! Here's me testing the lock-on using group follow https://i.imgur.com/Sb5slx4.mp4

[ramokz]

So the SpringArm3D is technically the way to add a collision to a camera. Otherwise, you would have to add a collider around the Camera3D or PCam, but that leads to all sorts of complications for tween transitions and when having the camera in-between its follow target and another physics object. All of which is what a SpringArm3D is designed to address.

I haven't gotten around to optimizing the addon for all workflows yet, but the setup should ideally be a mixture of Third Person Follow and Group Look At to achieve the result you're thinking of. It doesn't work quite as one would expect at the minute due to how the rotation is being calculated in the respective mode. So think there is a need for synergizing the behavior between that follow mode and look at mode so they work better together.

I tried parenting it to a spring arm but that did nothing, presumably since the script sets the position manually.

Yeah, this wouldn't work as the PCam node automatically sets top_level to true once it has a valid follow target, so any parent nodes would be ignored.

[ghostsoft]

Thanks! I wanted to check in before I do something stupid, but I guess my next step is to see if i can find a way to make the two play nice together by editing the source. I just wanted to make sure I'm not reinventing the wheel here!

[ghostsoft]

Actually re-reading your answer, I'm not sure about the part where you talk about Group Look At. I am already using the Simple look at mode which works fantastically and does what I want (rotation follows the single lock-on target) while I'm using Group Follow to keep both the player and the target in view - this is the opposite of what you describe (Group look at, Third Person Follow).

I tried the most basic edits of the source code to add the third person spring arm to the Group Look At follow mode but that didn't seem to accomplish anything at all and I'm not completely sure why, but I'll keep trying.

edit: I should note that this setup (group follow, simple lookat) is already perfect for the kind of Ocarina of Time Z-targeting that I'm going for (see video clip) and the only thing that it's missing is collision with walls/floor.

[ramokz]

The intent behind suggesting Group Look At here is that it would help keep the player and the target in view, while also not restricting where the camera can be. Allowing for a bit more flexible camera positioning that can be controlled by either the user or the game developer.

Thinking of allowing for scenarios like the above, where rather than having a fixed position of the camera behind the playable character, it's able to move around a bit as either the player or target moves. Thinking predominantly about cases such as environment collision, where either the game or the player need to adjust the camera to avoid getting into an unsuitable position. But also cases where the camera positioning needs additional logic.

Take this example of Devil May Cry 5, where the camera is keeping the player and target both in view, while simultaneously also changing its distance and rotation around the player (the Spring Arm) as the target and player changes position.

The complication of Group Follow is that it inherently cares more about getting the optimal position based on the group it's meant to follow. Which is not inherently a bad thing, but it also relies on that optimal position being desirable, which it may not always be.

The solution obviously depends on how you want the camera to behave, of course.

But again, the system is currently not entirely set up to work with it, as the SpringArm3D is currently being affected by the Look At behavior, which it shouldn't.

[ghostsoft]

Sorry that I keep replying to this but I figured out a solution for now which does not involve messing with the source code - I should've realized this sooner but it's perfectly possible to just put a phantom camera with no follow mode and no look at mode and just program its behavior manually, so that's what I did.

I gave the camera a spring arm and copied the follow code from Group follow and the rotation code from Simple look at and the result is good enough for now. The spring arm makes the auto-distance code not work quite like expected due to the length of the arm so there are still things I can refine, but this achieves the goal of having a camera that tries to keep both targets in frame while keeping the camera facing one of them.

2024-12-16.04-43-59.mp4