Download

Camera Snapping Problem

Hi community,

I have encountered a problem with my camera snapping very close to level elements such as geometry and characters when it moves over them:

The camera is attached to a camera boom with collision enabled – this is necessary for the game –, but even testing with bDoCollisionTest set to false results in the same problem. Selecting the conflicting Actor or geometry element and setting their collision property Camera to Overlap or Ignore does not resolve the problem.

Why is my camera snapping to the floor when something intersects the line of the camera boom component (I’ve checked and, indeed, this is when it happens)?

Thanks,
Shrooblord

Has nobody seen anything like this before? Is it the same kind of problem as the “camera snapping” many people report? Has it to do with collision at all, or am I thinking in the wrong lines entirely?

Are you sure that camera position is not affected by some gameplay logic?
I disabled “Do Collision Test” and I was not able to replicate described behavior at all

Starting out with just the TopDown Template and having modified very little, could you give me a couple of pointers as to what sort of things could be modifying the camera position? I will scour what little code I have for the logic that could be causing this, but I’m pretty sure there shouldn’t be any.

Maybe there’s some default settings in the Editor that need changing?

Could you maybe send me your test file so I can see how you set things up on your end?

I don’t think there is any point sending files, I mean it is freshly default project and it works fine.
Hmm… Is it possible that you’ve changed bDoCollisionTest in code, but it’s getting overwritten in BP character settings?

As for behavior itself - it works like expected, this snapping designed for 3rd person games, not isometric. Are you sure you need this? This behavior is basically “bug” with that “isometric” perspective, it’s even turned off by default in TopDown template.

This just looks to me like the camera spring arm is getting caught on geometry, nothing out of the ordinary.

A good solution would be to make sure that your objects don’t block or overlap the ‘Camera’ trace channel.

My game isn’t necessarily isometric; you’ll be able to manipulate the camera in any way you want, much like a 3rd person game, really. Zoom, pitch, rotate, move the camera, etc. should all be possible for this.

I tried this already; see my first post:

It is weird to me that setting it to “Ignore” shouldn’t resolve anything. This is why I came here for help; it seemed to me either a bug or something I’ve been setting up wrong.

Anyway, why is the Spring Arm getting caught on Geometry considered “normal behaviour”? I’d expect the whole purpose of the Spring Arm is to keep the Camera that target distance away from everything, so that it wouldn’t clip through geometry and that kind of thing and also always kept the character (or whatever else it’s attached to) in view.

Is there a minimum arm length I can set that I tell it to “retract” to when geometry gets in its way? I don’t want it to snap to 0 length if it collides with geometry of any kind. Furthermore, isn’t it good design if geometry and objects collide with the camera, so that it won’t clip through things? Or am I interpreting things wrong?
I am aware of this AnswerHub Question:
https://answers.unrealengine.com/questions/60031/how-to-set-a-minimum-length-for-the-camera-spring.html
However, the person who asked the question was looking for RTS-style camera that won’t clip through the ground. Now, I’m basically looking for the same thing, but I also don’t want it to clip through, say, mountains. I’m going to want mountains in my game and I need the camera to be able to look “through” the mountains, i.e. pretend they weren’t there and instead look straight ahead as if the mountain weren’t in its way, but I also need it to not clip through the mountain if the player moves the actor that controls the camera so that it physically moves into the same position the mountain is also in. In that instance, I need the mountain geometry to block the camera from moving, or, slide it along its surface, ideally.

Thanks guys. I’ll check out the default camera behaviour when I load up a new project and see if that is any different, and I’ll scour my code for any conflicting code I may have introduced myself. I’ll check the BP character settings like you suggested, zeOrb. I’ll let you know what I find.

@Shrooblord

I almost certain that your default initialization just getting overwritten somewhere else

Behavior of Spring arm is to snap “in front” of an object that otherwise will obstruct the view. It will retract to 0 length only if something wrong in settings.

This is the idea, yeah. Here is example of my setup, as you can see, it works correctly even when between character model and wall just a 10cm or so

[HR][/HR]
I just watched your gif again and I don’t understand the setup. Your spring arm attached to the cursor? Is it possible that “cursor” blocks camera spring collision checks? Or your character mesh?

Yeah, your setup looks more like what I’d expect the Spring Arm to do.

Aye, the character pawn in my game is maybe a little iffy. You see, the Pawn itself doesn’t have any actual geometry. It just has a position in the world; it has a Scene Component with attached to that a Spring Arm with a Camera. Then, its Player Controller spawns an Actor that whose behaviour is defined within that PC to always follow the mouse cursor position; this Actor additionally spawns a particle system that follows the mesh around. The hand mesh itself (with attached to it the particle system) have nothing to do with the player pawn, except that they are spawned by it. They do not collide with the Camera channels.

However, I did once code a MovementComponent for the pawn when trying to set up movement controls and following many different (conflicting) sources of information at once. Maybe I’ve messed something up in that step. I’ll try to recreate movement controls without the need for this MovementComponent. It seems irrelevant.