It’s not a download link, it’s a shared video file, you can watch it in your browser.
I managed to fix the issue by increasing wall thickness for about 0.1 m and it works flawlessly for now, it can probably be increased less than 0.1 m, I just didn’t test it yet.
Is it possible that that was an issue? Is that common? I mean, if the collision shape is exactly enveloping the mesh, that there will be some frustrum clipping on the sides of the frustrum because of the raycast colliding under a certain angle with the wall?
I just tested the setup without the github angles setup mentioned in the post, and still works flawlessly.
So I could just automate increasing collision shape thickness of walls on imported scenes, or I could make separate collision shapes for walls on a separate layer with which only camera collides.
I think it would be helpful to discuss your walls. Did you make them? I’ve never had the need to do this with walls, but if they are Plane Meshes, that’s probably the reason you’re having an issue, and nothing to do with Godot per se.
I tried this guy’s project, you can download it from video description. Just make player controller’s collision shape smaller and make a wall, try it yourself. Camera just penetrates through the wall.
So I used my own Character 3D Plugin to try this. The only time I could see the other side of the wall was if the wall wasn’t high enough to block the camera or if the SpringArm3D was too close to the wall.
I think the easiest solution is to create a second CollisionShape3D using a capsule shape attached to your player that only sees walls. Then make its radius large enough that when the player collides with the wall, the SpringArm3D and Camera3D can still fit.
I don’t really understand what would that second collision shape improve? It’s still on the player controller, camera still gets too close to the wall, I don’t see the point.
I can try but then the player can’t get that close to walls, player gets restricted by that additional collision shape, right? I’ve seen that in the previously linked project, from the video. He used 0.8 m collision shape, it does get the job done but it restricts the player from getting close to walls.
To me, margin for the SpringArm3D or margins for CollisionShape3Ds would be a perfect solution, i wouldn’t have to change the size of CollisionShape3Ds, but they don’t seem to work, there is practically no difference if I set margins to 0 or some big value. Why could that be? If a collision layer was the problem then springarm wouldn’t collide with shapes at all, but it does collide.
I’ll try it, but the thing is, you usually don’t have only walls in the environment. There can be a table in the center of the room where that additional collision shape won’t help, because the player can rotate the camera down and at the table, then what?
I mean, I found a solution. As I said, thicken collision shapes with which the SpringArm will collide with, they can be duplicated ones on a separate layer which only SpringArm scans for. Usually adding 0.01 meters to needed axes of collision shapes does the job.
Another very important thing is to do SpringArm/camera rotation inside Physics Process, otherwise your inputs may run faster than 60 fps, at that point physics engine can’t process collisions correctly. Store your input events from overriden input methods to member variables, then use those stored events and their values inside Physics Process to do camera rotation.
