Improving Godot's ClippedCamera node

BinaryOrangeBinaryOrange Posts: 240Member

Hi, kids! It's been a long time since I've posted anything here.

Anyway, I'm sure you all saw akien's tweet a couple of weeks ago where he released the 3.2 "alpha 0" build. It finally fixed the bug in the ClippedCamera node where it wasn't updating the local z of the camera! Excited, I decided to try it out and posted a video of it properly working.

Now, that's all well and good, and should be good enough for most basic games, right? ... WRONG! And let me tell you why. B)

The astute viewer will, upon closer inspection, notice several things wrong with the default behavior of the camera.

-- It does not take distance into account. You can move the ClippedCamera 10 units away, or 100 units away, but it will ALWAYS clip straight back to the player, instead of ignoring geometry between it and the player past a certain distance. That's annoying, isn't it?

-- It does not have any smoothing effect whatsoever. Upon clipping, it teleports straight to the player. Upon going back to a non-clipping state, it instantly teleports back. This is disorienting, confusing, and, as one reddit user described it, it feels like a car crash. Not good! A camera should follow the player, not teleport to the player.

-- It is possible to push the camera through geometry (not shown in video). This just shouldn't happen at all.

So, I took it upon myself to attempt to address these issues, and managed to solve them a bit.

It's a bit complicated, but essentially, here's what I'm doing.

--- I have an array that stores three ClippedCamera nodes, one for each "zoom level". They each are parented to a different target than the player. This was necessary to prevent the camera from clipping back to the player at zoom levels greater than 1.

--- I am not using ANY of the ClippedCameras as an actual camera. Instead, I have a master "view camera" that is being fed the information from the currently active ClippedCamera. This way, no matter what zoom level the player is at, it will respond accordingly. I can also use lerp() to smooth out movement! Neat!

--- I am always casting a ray from the view camera back to the player. If it detects a body between it and the player, it will calculate the distance of the camera back to that body. If it is less than the Max Occluding Distance, it will clip through as expected, otherwise, the camera will STAY BEHIND the body.

Here's some videos on the progress so far!

First Attempt - Just trying to get smoothing working

Second Attempt - Factoring in distance

Latest Attempt - Preventing the camera from pushing through geometry, and demonstrating multiple targets/cameras for the first time

When this is all said and done, I'm locking this up and keeping it for myself and patenting it so I can get rich going to release this on my github page so other people can use it in their games! It's a simple gimbal setup, so you should be able to just drag into your player node and go from there!

I do not have a set release date or schedule or anything. I do have a baby, so my development time is "when I can get to it".

Let me know if there's anything else that you think is missing! And let me know if this is something you would use in your third person games!

Tags :


  • Ace_DragonAce_Dragon Posts: 311Member

    Have you considered contacting the dev. who made the node more usable?

    The reason I ask is so whether this setup would be improved enough to warrant breaking systems that may have just recently been built. The setup I use meanwhile tends to use spatial nodes as targets rather than the player itself.

  • BinaryOrangeBinaryOrange Posts: 240Member

    @Ace_Dragon said:
    Have you considered contacting the dev. who made the node more usable?

    The reason I ask is so whether this setup would be improved enough to warrant breaking systems that may have just recently been built. The setup I use meanwhile tends to use spatial nodes as targets rather than the player itself.

    Good question! I had, in fact, not even thought to contact the dev.

    I do believe reduz (Juan) himself is the person who developed it for 3.1 last year, here's a tweet about it.

    Later on in that conversation thread, he says this:

    So, given that, I'm almost certain he has no intention of updating the ClippedCamera itself, as he has not talked about it since, the docs are barren about it, and there's virtually no indication of any further development on it.

    I believe it was his intention to give us a basic camera node which responds to collisions, and then for us to flesh it out from there. Seeing as he has bigger fish to fry, I can't say I blame him!

    As a result, I don't foresee any breaking of compatibilities in future versions of Godot, unless they change the very nature of ClippedCamera and how it detects its collisions.

    All of that said, I understand your concern. Seeing as I am building this in an alpha build (which is probably insane!), I can see why some people would question me! :p

  • Ace_DragonAce_Dragon Posts: 311Member

    Reduz was the original developer, but I'm pretty sure there was a patch created by another dev. that changed it to be more usable (which was committed).

    So it already received one revision.

  • BinaryOrangeBinaryOrange Posts: 240Member

    The only information I can find is that they fixed its original bug (where it wasn't updating its local Z position, even through code), and are adding information about the node in its current state in 3.2. I can find no mention of adding any additional features to it whatsoever. I can only find Juan's original tweets about it where he explicitly says that it is up to the programmer to move the camera, which I read as he is not going to add any more features to it, at least not for a while.

    Regardless, though, I do think my setup will be of value to most people. It's very much emulating a camera system that could be found in a game such as GTA V, for example, which most users may enjoy for their project. I highly doubt that any included node would do that exactly, but I would hope it would offer a lot more basic features than it does now! Not even including any smoothing/damping support puzzles, me to be honest, though I have recently learned that not even UE4 has a smoothing/damping effect on their out-of-the-box camera setups, either!

    I'd love to see any signs that they're going to add more features to the ClippedCamera node, but I am not finding anything, which is why I've started this whole thing. If they eventually make ClippedCamera have more advanced features, then great! If not, this setup should work for many versions to come, unless they change the collision detection methods they use in the node itself, which really doesn't seem likely.

  • BinaryOrangeBinaryOrange Posts: 240Member

    I have managed to make some decent progress this weekend despite working almost 60 hours and taking care of a baby!

    What did I do, exactly?

    • Removed unnecessary code that was not only redundant, it didn't really do anything.
    • Figured out how to create a "spring arm" sort of device, which works by taking into account the x rotation of the gimbal the camera resides in. This way, as the player moves the camera up, whatever target is currently active for the camera will move ahead, thus allowing the camera to clip through geometry directly above the player. This will work if you are pointing the camera straight down at the player and then move under something.
    • Removed the raycasting to determine the distance between the camera and any occluding geometry, as it was useless since I'm now using three separate ClipCamera nodes, each with their own targets at set distances.
    • And finally, I worked on handling confined spaces (this is where my own "spring arm" came into fruition).

    Here's a video, illustrating how it works in tighter spaces, as well as how the target will move back and forth depending on the x rotation of the gimbal!

    If all goes to plan, I may be able to have this as a released asset sometime before 2049!

    Things I still want to add:

    • Mouse/keyboard support (currently using my old Xbox 360 controller)
    • Camera rotating slowly to the player's back when no camera movement input is giving, so that it will always follow the player
    • Support for different camera heights as well, though not necessary
  • BinaryOrangeBinaryOrange Posts: 240Member

    I've made significant progress over the week, after several more experiments.

    First, I found that it is much better to go with a one camera and one target system, because adding more targets was getting complicated. Attempting to move the target back to the center of the gimbal depending on the x angle value was, admittedly, a bit of a silly idea, and it didn't work very well because you could end up clipping or not clipping through other geometry at odd times. So, I completely scrapped that idea and started anew.

    Secondly, I discovered that my original gimbal setup was flawed, because while the gimbal itself was at its zero position, I had set the camera and targets to be offset from that position, so the orbiting was all wrong, and felt nasty, and thus the camera was clipping in odd values, causing it to sometimes jump all over the place.

    Thirdly, I scrapped the idea of using raycast to calculate distances to determine if the camera should clip through an object or not, and replaced it with an Area that uses a sphere collision shape, which will notify the camera that there is an object close enough to the camera and clip!

    And finally, I use another Area with a tall box shape on it to determine if the player has gone under any geometry, and to clip if that is indeed the case. No complicated math needed!

    Here's a video of the latest results, by far the smoothest the've been!

    Now all I have to do is add mouse/keyboard support, and maybe I can let other people download it and test it out! :p

Sign In or Register to comment.