Improving Godot's ClippedCamera node

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

BinaryOrange

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

BinaryOrange

Life got really crazy for a while (having a baby will do that), but I have not stopped this project.

I got distracted by developing some other features for a future demo project, which will show the camera in action, so I added in the following:

Moving and/or rotating platform support (by parenting the player to said platforms)
Proper joystick deadzone support
"Walking on ice" effect, which was just silly and nothing more than an experiment
Interactions with rigidbody components (again, just an experiment)

And for features for the actual camera system, I have changed up a ton of the code and done tons of cleaning to better enhance the overall feel of the camera, and while it doesn't look too different from when it did in October, there has been tons of changes to better improve the workflow.

I still need to add proper mouse/keyboard support, and I need to figure out a better way to handle confined spaces - currently I took that feature out until I can get it working better.

Here is a video :

cybereality

That looks really nice. Good job.

BinaryOrange

Two weeks later and I have made some pretty good progress!

Finally added mouse/keyboard support (demonstrated in the first half of the video below)
Redesigned the test world
Refined how confined spaces work (still may need to tweak a few things)
Created ranges for the values assignable in Inspector tab to prevent assigning an absurd value for things like FOV, margins, etc.,
Made my repo public!

First, the video!

And finally, here's the repo - please note that you MUST use 3.2 stable if you plan to download/clone this repo to test it out, and hopefully you can make heads and tails of my code... I do plan to document the crap out of the this to make it easier to understand, and I plan to comment/condense the code so that it is much easier to understand, but I've been eager to let other people try this out first, so let me know what you think!

ADDITIONALLY: Please use a gamepad if you have one! Currently, you can switch between mouse mode and gamepad mode by either left-clicking the mouse in-game, or hitting the Escape key in game. Use ALT+F4 to quit the game since I took away the ability to with the Escape key.

This is a direct link to the camera controller script - as you can see it's quite messy, and in fact, I can see many things that aren't doing anything anymore, so I'll tidy that up in the next commit or two, but please be patient as I have a baby and this is very much a "when I get around to it" project. No pull requests please! :p

novaleaf

this looks really awesome. I spent about 3 full days making a non-gimbal locking "freelook" camera, and shudder at trying to get it working as a 3rd person camera.

I think I'll give yours a go instead :)

emo10001

Nice work @BinaryOrange !

BinaryOrange

Thanks for the comments everybody! It's been a long time developing this, and it's nice to know that people are finding this interesting!

I do have an announcement that sounds bad, but is actually good - I have to start the project over!

Basically, I've encountered an issue with mouse control that just couldn't seem to be solved - if the mouse was not moving at a consistent speed, it was possible for the camera to clip through geometry for a brief moment and then catch up after a frame or two, resulting in a horrible "glitchy" feeling and look.

Of course, I didn't discover this until after I published my repo , and I have spent the last week attempting to fix it to no avail whatsoever. Even if I set up a ridiculously high offset value for the clipping distance, it would still happen.

Then I thought to myself, just tonight, "what happens if I get rid of my "View Camera", and just go with the ClippedCamera again?"

And...! That seems to have solved the issue altogether.

I did start developing this project in 3.2 "alpha 0", so it only makes sense that a lot of things may have changed since then, as I no longer seem to need to use a secondary camera at all, and can just rely on the ClippedCamera itself.

I'll have to come up with another way to determine ignoring distance, as well - it seems using a probe with areas for detecting when a body was in the way of the camera also could have been to blame as well, but either way, I like the idea of simplifying this by reducing the amount of cameras needed back down to one.

I'll work on it this weekend and push a commit with the changes by Sunday night, if I can manage it. It shouldn't take too long to make any of the changes, I just have work tomorrow so will have to primarily work on this Sunday morning.

BinaryOrange

Ok, so... I'm still having issues with the ClippedCamera being able to clip through geometry in certain instances, after all. I'm not sure why my preliminary tests didn't reveal the problems the other night, but when I reworked my script and scene to only use the ClippedCamera, the same exact issues re-appeared, albeit in slightly different ways.

Thus, I believe there are still some internal bugs in ClippedCamera that need ironed out (can anyone verify if the margin property in ClippedCamera actually does anything? It still doesn't seem to affect collision distance like I thought it should, according to its own description).

So, before I lose all of my hair, I'm putting this project on halt until I can maybe find a different solution. It may just be that ClippedCamera doesn't expect to be manipulated like I'm manipulating it, which could be causing my problems, but I suspect it's an internal issue of ClippedCamera itself.

novaleaf

I hope you are able to figure it out without going crazy. I just spent the last few days obsessing over making a wireframe render... so I know what it feels like when things are not perfect :)

BinaryOrange

Over a year later....

I've not done much else with the original project. In fact, it currently lays dormant on my github page.

However, I have started doing some experiments with other ideas I have gotten over these past several months. I have not had much time (raising a baby, dealing with other things (like finding out we're expecting a second child!), eating, sleeping...), but some of my preliminary tests are very encouraging!

Since I started and then abandoned this project, some very neat things have been added into Godot, namely the Spring Arm node, and the ability to set the collision shape of the spring arm node! By adjusting the collision shape, it's finally possible to do a "sphere cast", which, in my tests, provides a much more professional and smooth-feeling camera system.

I am still having that issue where the camera will occasionally clip through geometry when it's both moving very fast, and the distance between the camera and the player is greater than maybe 8 or so units. This tells me that the clipping issue could potentially be solved by ensuring the camera cannot reach the floor once it's at a certain distance, and wouldn't be noticed by the player since it would immediately respond to hitting the ground anyway. That's honestly probably how it's handled in most games anyway!

So here are my plans for this going forward.

Completely redo the original project.
Create a reusable scene that anyone can download and instance into their projects.
Provide tons of options, such as choosing how the camera responds to collisions, lerp speed, whether or not you want it to lerp at all, basically everything you can think of will be an option.
Obviously this will be open-sourced!
Model the whole system off of Rockstar's insanely good cameras. This gives me an excuse to play games like RDR2 and GTA V all over again. It's not stealing, it's inspiration! :tongue:

I've been learning a lot over these last few months, and though I've barely been active and have maybe done three hours worth of coding in the last eighteen or so months, I'm confident enough with these tests to try to get this back up and running, and make it even easier for everyone to have a nice camera for their game!

Calinou

BinaryOrange

That's a very interesting discussion! I'm glad to see that reduz himself is attempting to tackle this issue as well. Cameras, in my opinion, are what can really make or break a game. This a problem, though, because if the camera in a game is well-coded and behaves naturally, you'll never notice it! Whereas if the camera is poorly done and glitchy, the player will immediately notice and be frustrated by it.

If Godot can have a built-in way of handling a camera setup and give the user an easy way to make a professional feeling camera, that would just be tops.

That said, I still plan to open-source my project (tentatively called "BetterCam", because I suck at coming up with names), and in fact, if anyone wants to look at/follow it, I did start a repo for it the other day. Suggestions/ideas are welcome! It's not functional yet, I've just been setting up the basics whenever I have a free moment.