Redesign Camera3D pivoting and unocclusion

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Doing proper game cameras in Godot is not obvious. Currently, two overlapping (to some extent) implementations exist.

• SpringArm - Has the advantage of being very simple to use, but it's rather limited in its current form. Attempting to make it generic makes it more limited when used specifically for camera (a good amount of things are missing that would be expected in a camera, like autoturn, drag, etc.), and also the fact that it uses a collision shape that is not necessarily the camera frustum. This can lead to inaccurate unocclusion. Also, no one uses this node for anything other than cameras.
• ClippedCamera - Has the advantage of having very accurate unocclusion by projecting a shape that is exactly the shape of the frustum, but it only provides that and it's very hard to use.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose joining both into a single system that takes the best advantage of each, making it powerful and simple to use. This would consist of two nodes:

• CameraPivot - A higher level node that acts like a camera pivot. It can be rotated around manually, or it can be configured with a "drag" mode, like some games have, which just drag the camera. It can also interpolate the camera to provide smooth motion. It should also provide simple unocclusion by rotation. The idea of this node is that it should be very simple and ready made and well understood, but provide the most common case scenarios that are required. It should also be possible to replace it by a more complex one (or an add-on) if required. This node interacts with child camera nodes (will show warning if none present).
• PhysicalCamera - A camera that can bump into physical objects and unocclude itself by moving forward. If used together with a CameraPivot, the pivot will act as the frame of reference for unoccluding, otherwise its up to the user to specify this. Having it separate from CameraPivot allows the user to create their custom camera behaviors while still having the unocclusion solved, which is the hardest part.

Using both together should provide a simple and ready made setup for creating third person cameras.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In normal operation, a CameraPivot would be positioned at some point relative to the player (generally a bit above the head). Camerapivot will make the child camera look towards it, and provide elevation, latitudfe/longitude orbiting parameters as well as maximum and minimum distance for dragging.

PhysicalCamera will be added as s child (can be another camera but it will lack the unocclusion), and it will always precisely unocclude from walls thanks to using its frustum volume as projected shape.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can be made a script, but not with a few lines, and this is a very common use case in TPS.

Is there a reason why this should be core and not an add-on in the asset library?

It is an important building block that is found commonly enough and simple enough that warrants being in core.

[aaronfranke]

"PhysicalCamera" to me would imply an actual camera in real life (such as a webcam), so maybe it should be something else, but I'm not sure what. PhysicsCamera? CollidingCamera? KinematicCamera?

"CameraPivot" to me would imply it uses a camera in some way, but this is not necessarily true - a camera pivoting around would just be the intended use case for this node, but I would imagine that it would be a general purpose node for offsetting children from a point based on physics (if the goal is indeed to replace SpringArm). Maybe it should be called SpringPivot?

Some context for the reason this topic came up: I asked what the purpose of ClippedCamera was, since you can do the same thing with a SpringArm + a Camera (although making the collider be the shape of the camera frustum would have to be done manually), and also ClippedCamera was made for the TPS demo (but the TPS demo never used ClippedCamera). So the problem is that there is some functionality overlap which may not be desired. This proposal does indeed resolve this, and it seems nice, though I will say that I would never have thought of this as it seems very complex for something included in core.

[Chevifier]

I personally think the spring arm and the Camera could be combined into 1 and the springarm would be something you just enable if needed. However I never had issues with the Spring Arm Camera node combo until I start messing with its margin property.

[theraot]

I want to point out that the SpringArm as it is has other uses than handling a Camera. For example, in a FPS, the SpringArm is useful to have the weapon retract to avoid clipping obstacles. Please keep SpringArm around.

---

Based on what @aaronfranke says, Here is an idea, submitted to your consideration:

• Have SpringArm use a CollisionShape node.
• Add an option in the editor to create a CollisionShape from the frustum of a Camera.

That way it would be easier to setup the SpringArm + Camera combo to work like a ClippedCamera/PhysicalCamera. Then remove ClippedCamera. I believe that would solve this.

---

I like the idea of a Node that would help in making the Camera setup (CameraPivot).

[jasperbrooks79]

If the point here is, to re-structure the clipped camera, so it's easier to use, I'd rather have it just ' spawned ' with a gizmo, for the arm, and maybe rename it, to something so it makes more sense, at least I had no idea what a 'clippedcamera' did, just from the name, I thought the ' camera ' would be clipped, or parts of the 'image' it makes, would be ' removed ', like black bars, in many movies, or so . . it's like clipped camera means it, does stuff to the ' image ' it makes, renders, sort of 'clips' them <3

So, if the player is at 0,0,0, and I need clipped camera, to be 2 meter over that point, little bit over head, of most people, at 1.8-1.9 m height, then the ' root ' transform of the camera is the gizmo, so if one write 0,2,0 in Transform, the 'gizmo' moves there . . one could also make a special gizmo, that looked like a spring, or 'gear', to show the camera moves on 'this' axis, when the camera clips, or is 'inside' stuff, or so . .

Maybe make, so when one ' creates ' a clipped camera, instead . . the gizmo, icons, or ' design ' makes it more clear, what it ' does ' . .

ps. I'd not call it camerapivot, as the ' core ' clipped camera doesn't pivot, it scales, or so, call it ' CameraArm ', ' CameraPoint ' . . it's really tough finding the ' right ' names, none of these 'really' work . . .

Anyway, not 100 % sure this is what you're talking about, but at least it could be really nice, if ' clippedcamera ' was better explained, had a better gizmo, 'interface', or so <3

ps. best case would be if one could ' select ' both the pivot 'target' and, also the camera, and move them independently, with gizmos, so one wouldn't ' move ' the camera, like they had separate coordinates . . that way, one could ' accurately ' place both the ' spring arm ', and the camera, more easily :OO . . . this isn't ' exactly ' how it's supposed to be, maybe if these ideas were improved, it'd work nicer . . Hmmm, need more gizmos, that make ' sense ' <3 at least, in clippedcamera <3 . . like, if one had two move modes, one where the ' end - gizmo ' controlled the camera, position, it rotated around that point, and also ability to move camera alone, or, well . . Thx . . . . perhaps ' DynamicCamera ' is a better word, or ' CollisionDetectCamera ' . . <3

[jasperbrooks79]

I'd probably design it, like this . . the ' end ' gizmo moves both camera, and itself . . the camera has a gizmo, that moves only that . . then it'd be visually 'apparent' that a clippedcamera, had something to do with the 'axis', at least . . <3

if one added a special icon, or called it a ' CollisionCamera ', or something . . or ' AnticlippingCamera ' :OOO . . <3 <3

maybe, this should be a separate proposal, sort of, to improve user-experience, of clipped camera <3 Sorry, engine talk gets very technical, at engine maker level <3

I'd just re-do the clipped camera, like this, and add the more advanced stuff, from ' CameraPivot ', in settings for the first gizmo, and add what's needed, also for the camera, so in node inspector, there's first a list, for ' Target ', or so, where you can write ' drag ', other stuff, and then below the settings for the first gizmo, settings for the camera, that are relevant . . Having a separate camera arm node, would make it more flexible though, as it can be coded separately, or combined . . but if in effect, all it does is act as a ' parent ' node, for the camera, well either suggestions work, problem is will new users be able too see, that they need a camera pivot, and how to set them up, well . . clipped camera could be improved this way, and it might solve all the problems, in the proposal, or it will be close . . <3 . .

[reduz]

@jasperbrooks79 Actually, to work as expected, the actual distance is clipped by the plane sitting at the pivot and looking at the camera, this allows you to implement off-center cameras (like over the shoulder). But the general idea is that anyway.

[jasperbrooks79]

Well, those are my thoughts, but I may have mis-understood the whole thing, sorry . . <3

[reduz]

@jasperbrooks79 oh no you got it pretty well, what you suggested is almost how it actually works, so you were spot on. I was just clarifying. :smile:

[jasperbrooks79]

Okay, I've been thinking, might be nice to update the ' clipped ' camera, like above . . so, the gizmo has ' global ' coordinates, and the camera has ' local ' coordinates, referring to that . . and, since clipped camera can only move on z - axis, make so the ' gizmo ' that moves camera, can only ' move ' there, effectively giving it only a ' z - coordinate ' :O . .

if clippedcamera was updated that way, maybe it won't be necessary to make two new nodes . . . also, the stuff you talked about, ' drag ' on the CameraPivot, could be ' options ', under the camera . . what I was thinking, maybe it'd be good, if one could make a clipped camera, with two gizmos, for really complicated stuff :OO . . so, one can write, ' use secondary pivot ', in node inspector, and you get this, or so . . <3

I think this might work just as well, as having two nodes, and the gizmos would make new users understand, those were ' important ', the ' point ', if the camera was a ' child ', of the root gizmo, people would soon figure it out, on their own :OO having two pivots, one could make a camera ' interpolate ' on both axis or, even make a ' bezier ' approximation, between them, so the ' camera ' could do ' smooth ' clipping stuff :OO . .

any-way, you'd have to re-code the entire clipped camera, and add any new features, you think, could have use - cases, in general <3 . .

ps. Thanks for this amazing engine, I began using visual script, it looked more user-friendly, but now I have written first code <3

it's ' Hello world ' <3

Godot 4 is looking amazingly promising, can't wait . . Best thing is, it's free and, relatively easy, to use :OO . . .

So, maybe this is new proposal, I'd like to have clippedcamera updated, so it's more user-friendly, and it might do all the things you want, not sure . . :OO . . .

ps. if one could select say, the mid gizmo, and only add ' drag ' to that, then one could create well, any camera :OO . . .

[jasperbrooks79]

ps. might also be possible to set a ' rotation ' value, so as camera moves along pivot direction, it rotates, along certain axis, so the ' camera ' focuses, on a complex rig, might be too complex, to include . . also, one could add, so after a camera has clipped, it doesn't ' jump ' back, to the ' original ' position, but ' slowly ' lerps there or, so . .

also, might be cool to add a node, called ' BezierArm ', that creates a bezier arm, other nodes can use, like a normal 'SpringArm' :OO . .

This might have to be included, under ' advanced settings ', or so . . not sure how many, would use it . . problem is, can it be coded, and ' run ' fast, no bugs <3 . . . .

Godot 4 is getting so many improvements, it's tough to see, it's based on Godot 3 / 3.2 :OO . . <3

or, you could make the camera rotate along one, or two axis, of the bezier arm . . so, it tries to point, along the path :OO <3 with option, to ' lock ' one axis, so it does, well cool stuff <3

add. so it follows the ' normal ', of the path, but can be locked on one axis, so it doesn't ' roll ' :OO

This is more like brain - storming, I don't have enough experience, to really say, what should happen <3 . . .

Thx, <3 . .

[Lexpartizan]

I don't like the behavior of springarm in that if there is something between the player and the camera (for example, a small column), the camera is attracted to the player. Moreover, the default camera may collide with the player himself and be drawn close to him, which causes inconvenience. You have to make a tracking point above your head to somehow compensate for that. But this is not always possible, for example, in a camera attached to a spaceship, you can turn camera around the ship and a collision with the ship is inevitable (yes, this is also treated, but it's all unnecessary movements and you need some experience). I would like a normal physical collider on the camera, which would react to collisions with the environment (the camera is attracted to the player only if it collided with something, and not always when its path is crossed by an object). That is, the standard behavior of the springarm camera, but only if the camera itself collided with something. Perhaps you should expand not the camera node, but the springarm node and introduce an additional function mode.

[theraot]

@Lexpartizan I remind you that you have collision layers. For starters, use different layers for the environment, small objects, and the player avatar. Then set the collision mask of the SpringArm to the environment only, By not setting the layer of small objects, those will be ignored, and will not trigger the SpingArm. Similarly by not setting the layer of the player avatar any collision with the player are ignored too. Of course, you may need to use more layers depending on the game, this is just the simplest setup that works for me.

Addendum: and the player avatar collides with the environment and small objects, of course.

[jasperbrooks79]

One more thing, I some-times write too much :OO . . since I'm new to engines, and don't know what is really needed, in the larger sense, of the industry, or small studios . . the stuff I wrote, is more like brain - storming, if there's some-thing useful there, that'd be nice, if not, <3 . . .

Thx, for 4 / 3 :OO . . <3 . .

like, I'm noob, don't really know what's best, from long experience, coding <3

[theraot]

@jasperbrooks79 Don't worry. Ideally people with different points of view would give feedback. I don't think it makes sense to expect people to have all the perspectives.

Some things I would highlight from what you have said:

• These nodes could benefit from having more gizmos.
• Giving a good name to these nodes is important.
• It can be hard to understand how these nodes work.

And on writing too much, I have been there. Brevity eludes me sometimes, so I sympathize. Gotta try to stay on topic.

[jasperbrooks79]

Thank you, here's my thoughts, on all this, as a noob, Godot - novice . .

1. Current clippedcamera doesn't make sense, at least from name . .
2. Juan's proposal, is like rest of this amazing engine, a step forward, superb . . But, I would consider, improving ClippedCamera, so it did all this, has advantage old users that use it, will find it familiar, and it won't introduce more nodes, ie. we get the old Godot, with improvements, though new features, are so cool, sdfgi, all that stuff <3 . . I'd rather have all these things included in clippedcamera, IF that is even possible, for instance ' drag ', so on . . could be a ' setting ', under the root gizmo, or so . . .
3. I don't understand the proposal fully, or what it's 100 % intended, to accomplish, so it might not be possible to include all these things, in clippedcamera, so the CameraPivot node, might be needed, to get everything . .
4. Last, I don't understand cameras, that well, like what kind of ' settings ' they should have, so it's REALLY difficult to do anything, beyond speculating, almost no experience, atm . . I don't understand the industry, or what the next-gen version, of video - game cameras / viewports are, or should be :(( . . .
5. This is brain-storming, 'throwing' ideas around, so the people working on this proposal, have a bit more, to start from, as a big noob, my ideas are very rough, in-complete . . I don't expect this to be the ' best ' idea, just some 'inspiration', ' ideas ' . . . :OO . .

Thanks, for amazing engine, can't wait to see, how it all comes together <3 . . Godot, is wonderful, the engine makers simply do a superb job, it has ' everything ' but, we want more <3 . . .

🤤 ❤️ . .

ps. if this is about adding really advanced features, to the camera, if one could ' generate ' a bezier curve, and one also had a ' slider ', with relative position, ie. 0 - 1, so one could ' move ' that in inspector, to see what the camera then does, not sure, anyway be nice if one generated a ' curve ', that one ' could ' see it, like a ' gizmo ' <3 . . . :OO Thx . . Problem is, I have no idea what really advanced things camera riggers dream of, in the industry :(( . . . .

[Lexpartizan]

@theraot Collision masks are not a good solution. Because the camera will fall into the objects of other layers. For example, if I rotate the camera around a ship and want to get as close as possible, I will pass through it. In addition, it is handmade and a potential place for glitches if the distribution is incorrect in layers.

[jasperbrooks79]

One last thing, I really like well, a ' realistic ' feel to my cameras, like they're held, by hand, and tries to focus, or so . .

Like, this, people standing on a roof, with a phone, like that . . or, on the news . .

https://www.youtube.com/watch?v=ckFfMZ5gd_E

Those cameras have ' jitter ', and often tries to focus, so on . . I guess I'm supposed to code that, or so, was thinking, Unity got this really ' elaborate ' camera, or called . . Cinemachine . .

Brackeys, on the ' camera ', in Unity . .

https://www.youtube.com/watch?v=Gx9gZ9cfrys

It's REALLY complex, and I feel, does ' too ' much, to make ' movies ', ' junk ' . . .

But, having a new camera, with BASIC settings, for jitter, so on, like based on documentaries, or people's home - videos, like just a normal camera, that could be a neat thing, to add . . maybe call it, ' JitterCam ', no reason to make it like, do every-thing, just so you can get a nice effect, of people filming, what they see, around town, places . . when that happens, there's a little delay, before it changes ' focus ', there's jitter, hand - shake, more . . it quickly gets ' over done ', but having a ' simple ' version, of that, could help create a ' documentary ' effect, and add ' realism ', to the projects, the key is, to not go over-board, on the features, implementation . . . <3 :OO . .

Like, a ' news ' camera or, people recording stuff, by accident, on phone, other stuff . . I think one could add that, while keeping it real, ' honest ' . . Not, sure . . . It gives a really nice effect, of ' being ' there, often . . Just, make a basic, do ' what you need ' version, not complex, over - done . . <3 :D . . . I'd like that, since it takes video - games, to the next level, of ' realism ' <3

Thx, noob ideas, point is, I feel such a camera is missing, it'd help bring more realism, to Godot, imo . . Just, don't make it over-done, or 'pointless', a simple version, that gets the job done, no more, Thx . . I'd rather have that, than some crazy advanced camera, I'll prob. never use . . But, is it possible and, could it find a place, in the engine, if done well, ' modestly ' . . <3 Thx . . .

Like, node called ' DocumentaryCamera ' :OO like that, the idea <3

So, it has a Raycast, that detects a focus point, and it tries, at intervals, to ' adjust ' focus, like news - camera, personal camera, phone <3 problem is, it quickly gets ' dumb ' or, over-done, there's a sweet spot, where it 'makes' sense, imo . . Thx . . . <3 <3

'FocusCamera', 'LiveCamera', or so :OO Thx . . Might be, dumb <3

Something, that simulates a real camera, keeping it honest, or so <3 . . . And, relevant, competent, ' nice ' <3 . . . ' ActionCamera', or 'LiveCamera' <3 avoiding the pit-fall, of ' making ' it nice for you, like 'Unity', too elaborate, but like, a real, ordinary video - camera, used for documentaries, home - videos or, ' direct ' recordings :OO . . . .

<3 . . . .

[theraot]

@leonkrause I see. Yes, a normal collider collider - as you suggested - makes sense to solve that.

That makes me think of making the camera a child of a PhysicBody. It is not clear which one. Which makes me think #2184 is relevant.

---

I don't know how much of setting the camera can be automated. Of course I would like to be able to effortless set up a camera and not have to worry about the "50 Game Camera Mistakes" (GDC 2014 talk, video).

---

Here is an idea, can we have the editor automatically assign layers based on collider size? That is, that we configure in the project settings some layers dedicated to "small", "medium" and "large" objects, with some criteria of size. That is the closer I can think to a not manual solution to the column problem you mentioned (which is also error number 9 in the linked video above). Perhaps not so good idea.

[jasperbrooks79]

For instance, many modern cameras have multiple points, it uses for determining ' focus ', when it reaches a certain threshold, it auto-adjusts . . .

It might be ' nice ', to have a camera, that simulates how these works, also, for videos, based on the ' systems ' used, in current cameras, better . . .

That'd be a ' cinematic ' camera implementation, while keeping it 100 % honest or, so . . Thx . . . <3

Trick is, finding a ' nice ' implementation, that makes sense, is simple, ' works ' . . <3 . .

I'd prefer, if clippedcamera was improved and, there was a camera, like that, similar to ' Blair Witch ', 'real', simple, nothing ' added ' <3 Thx . . .

like, a ' camera ' that, would ' make ', what a real camera, cam - corder does . . :OO . .

Focus, blur, even ' lens ' distortion, at the edges . . a 100 % re-creation, of a normal camera, with nothing added, just, the ' basics ' <3

stuff like blur, could be a ' setting ', so one can check it, ' random jitter ', horizontal 'drift' . . :OO . . <3

then, it's up to the game - devs, users, what they do with, or so <3 . .

Something, that replaces a ' camera - man ', no more <3 should work, like a documentary camera, or video - cam, no 'bull - shit', just ' real ', actual cameras, that's enough, or so . . . . so, one can have a documentary camera, or 'disaster' - camera, or so on . . . I'd prefer that, to getting a new node, that effectively ' works ' like, an improved clippedcamera <3 . .

Now, this gets a bit 'wild', if one made a simple bezier curve, and animated a camera like that, one would ' effectively ' have a, real camera, and for instance, if ' camera ' man fell, one could even animate the jitter value, so there's more shake, 'impact', etc . . it could even respond to physics, so if the animationplayer made an abrupt stop, it ' compensated ', realistically . . simple, honest, functional, adds a whole new world, to what's possible <3 . . .

I'd prefer that, over some ' fancy ' implementation, like Unity, where goal is to make ' Hollywood ' stuff, a bit ' fake ', or ' unreal ' <3

Then, users could use it, as needed, in their projects, no more . . . :OO Thx . .

Like, keep it ' real ', but also a bit impressive, ' spectacular ', ' cool ' . . bec. that's what almost any-body can do, with a good camera, or ' real ' video - camera <3 ps. I think this would fill a gap, in the current number of cameras better, than an improved ' clipped ' camera, esp. if the current one, was improved, like above <3 . .

then, if you ' care ' you can add post-processing, contrast, that stuff <3

[theraot]

ps. if this is about adding really advanced features, to the camera, if one could ' generate ' a bezier curve, and one also had a ' slider ', with relative position, ie. 0 - 1, so one could ' move ' that in inspector, to see what the camera then does, not sure, anyway be nice if one generated a ' curve ', that one ' could ' see it, like a ' gizmo ' <3 . . . :OO Thx . . Problem is, I have no idea what really advanced things camera riggers dream of, in the industry :(( . . . .

Do you mean like the Path node? I think we can do what you say with Path and PathFollow.

---

So... There are a lot of things that we may want as parent of the camera at different moments. We could have multiple camera and switch between them. We could even move the Camera in the scene tree. Or we could use multiple RemoteTransform.

I wish there was an easy way to switch between multiple RemoteTransform, in particular a way that would interpolate between them.

[theraot]

@jasperbrooks79 What you describe seems to me like a good idea for an asset in the AssetLib. In fact there are already a handful of cameras there.

Jitter is motion, can be scripted. For focus, the environment (there is an environment attribute in the camera) has depth of field (Dof), which can be scripted. And we could use a RayCast, or multiple, and have an autofocus functionality.

Edit: I don't think we have distortion and such without some extra effort (Advanced post-processing).

Should it be core? Don't know. Perhaps make a proposal.

[jasperbrooks79]

Sorry, if this is too much . . My main goal here is, to start a ' meta ' discussion, about if the first proposal, is the ' right ' direction, or we would be better off, by adding a ' different ' camera, and just updating ' clippedcamera ', to do 90 - 95 %, or more, of original proposal, and sort of, ask a big question . . is there a ' better ' node to add, than in the proposal, like isn't it smarter, to add something that REALLY adds to the list, of camera - nodes, instead . .

I guess, it's my critique, of the proposal, though I have nothing against it, in fact, as usual, Juan's proposals are next - level, frankly speaking . . My point is, I'd rather things were done this way, at least in terms of new nodes, regarding cameras, for Godot 4, since this ' significantly ' expands, the current list, and adds a functionality, far beyond what, adding a node, that allows one to make a ' better ' clipped camera . . :O so, this is 'my' idea, sort of, this is prob. a better way, to expand the ' options ' of what cameras do, that's how it is related, to the first post :O . .

ps. I'm noob, things got rather ' meta ', or meta - meta, the ' real ' question is, how do we improve the number, and kinds of cameras, for Godot's line-up, in the most sensible way, that is ' implied ', by the start proposal, I think . . :OO

<3 . . Thx . . . :OO . .

might seem like I'm rambling, but I'm trying to brain-storm, perhaps too much of that, if the original proposal, perhaps needs a ' new ' perspective, so we get far more functionality, in terms of ' cameras ', rather than just adding two nodes, possibly making it more complex, that do what clipped camera does, or interpolated camera does, sort of, combined :OO that would not really ' expand ' the engine THAT much <3 but, adding a ' RealisticCamera ', or well, ' DocumentaryCamera ', that works like a decent, mid - range cam-corder, or DLSR ( with advanced zoom functions, etc ) . . or, a modern phone - camera, that also has auto-focus, etc . . I think, this might IMPROVE what Godot's camera nodes ' give ', far more than, ' moderately ', making the clippedcamera, or interpolatedcamera, a bit better, combined :OO . . So, that's what I think of the proposal, it's really nice, and frankly AWE-SOME, but I think this adds to the engine, much more significantly, tbh . .

:DD :DD <3 . . .

Sry . . . <3

Sort of, trying to say, the ' REAL ' question is, how do we improve the current cameras, in the most significant, user-friendly, ' important ' way . . And, while the first proposal is really good, I don't think it does that much, compared to what is already there <3 Thanks . . . So, it got a bit ' meta ', looking at it, from a ' distance ' but, I think this adds MUCH more to the engine, and is MAY-BE a better way, to improve the camera nodes, imo . . :OO <3 . . .

Silly . . ( am I <3 ) . .

<3 . .

ps, It would technically also be, the only ' honest ' way, to add a ' Cinematic Camera ' system, to Godot . . and, one could make amazing things in it, without ' compromising ', making it ' dirty ', or so on . . A documentary camera, is 100 % honest, it's just a 'thing', that records, etc . . Making a camera, that ' works ' like that, would give engine users a cool platform, to ' start ' from <3

[jasperbrooks79]

I think this, makes more sense to add, as a significant improvement, of camera nodes, their ' functionality ' . .

Also, it'd be very easy to go from a 'RealCamera', to ' cinematic ' look, by adding post-proc., in environment, may-be contrast, etc . .

By making a 'HandheldCamera', or so . . that just works, like a decent, mid - range cam-corder, or DSLR, easy to get, or find . . Then, people could even create ' movies ' in Godot, using post-proc., but it's up to them, to decide, what ' they ' do, or so . .

I am sorry, I think it was a bit implied, by first proposal, indirectly . . how do we best ' add ' to the camera nodes, so more users benefit, sorry . . I think this fundamentally adds to nodes, much more, than separating clippedcamera, into two nodes, and then letting devs, so on, figure out, how to connect them <3 <3 . .

I think, this is a much better node, to add, and is 100 % honest, simply ' real ' <3 Thx . . . .

In fact, all movies start with a normal, average camera, most of reason, for ' movie ' look, is bec. post-proc, or color-range, well ' tampering ' . . . this would effectively be the ' CinematicCamera ', bec. it'd take 2 - 3 minutes, to add post - proc, while keeping it ' real ', not doctored, so on . . Prob. the closest thing you can get to a cinematic camera, without ' selling ' out :OO . . Thx . . . . or, helping users make ' fake ' stuff, or so . . but, it'd be very easy, to go from a ' DocumentaryCamera ', to a movie, just add post - proc., boost effects, etc . . <3 . .

imo, it's not the job, of engine makers to ' lie ', or ' pretty ' up images, so on, like Unity does . . it's up to the users, to do that, if their project merits it, or they ' like ' it . . but, adding something that works, like a clean ' documentary ' camera, no bull - shit, doesn't really go ' into ' that territority, at all . . it's the closest you can get to a ' cinematiccamera ', without lying for the player, or making ' bull - shit ', etc . . however, giving it a ' movie ' look, is as simple as adding post-proc, of course <3 . . . Thx . . . .

That's the new node I'd add, to improve camera functionality, significantly, drastically <3 . . . Sry . . .

<3 <3 . .

[jasperbrooks79]

Last, if we look at ways to improve current camera nodes, or make new nodes, maybe consider making a ' steadicam ' node, works like, this . .

This is a real camera, been used for many years, and adding such a node, would make sense, or so . .

That way, the cameras in Godot represent ' real ' equipment, standard, in the media industry, or so . . I think it's important to rely on ' real ' stuff, when making stuff, it'd have to be an expansion, of the ' RealCamera ', any-way one often sees that camera, it's used in many areas, mostly ' film ' :OO Thx . . .

prob., just need some 'physics simulation', of the arms, that's all <3 . . Thx . . .

It's about looking at, how to add things, to get ' classic ' looks, to the camera line - up, imo . . Thanks . . . <3 also, it's 'real' stuff, not fake, or so . . <3 <3 . . it's just physics, coding it, momentum, mechanics . . :OO . . .

if one made the camera, follow an animationplayer transform, it'd react like that . . and, if one maybe had some mo-cap data, it could be attached, to a BoneAttachment, and look real :OO . . 100 % reliable, ' normal ' stuff, used in film, also documentaries <3

this would also effectively, be a ' CinematicCamera ', been used in many movies, tv-shows, documentaries, over last 10 - 15 years <3 effectively giving you, an ' expensive ' steadicam, drag-and-drop, in Godot <3 how the gizmo would look, not sure . . . Thanks . . .

Results . . .

Basically, ' movie ' stuff, after post - proc, effects . .

<3 . . . also, very cheap to code, assuming it's just physics, 'momentum', velocity . .

you could make a ' simple ' gizmo, and a more complex one, so one could ' trouble-shoot ' any glitches, while ' moving ' it <3

Any-way, I'd add stuff like that, to take it to the ' next level ' <3

Might have to study steadicams, a bit . . notice how there's a ' point ', right below the camera, one can move . . <3

One would need a gizmo, to do the same, where the points can be animated, as a series, of nested nodes :OO . . . <3 <3

That would effectively mean, Godot could make ' Hollywood ' quality cut - scenes, cinematics, in some projects . . . <3 it's just some ' mechanical ' arms, levers . . <3 <3 or, ' physics ' . . . <3

[jasperbrooks79]

Last, I think this is what the ' gizmo ' would look like, based on some images . .

Would give Godot that, ' cinematic ' mode, easily . . . Coding it, would require some study, of ' real ' rigs, equipment . . . <3

That's how, they got that ' film ' look . .

Probably needs a gizmo, on the camera, for up - down rotation . . :OO . . <3 Any-way, it's based on actual reality, ' real ' cameras . . :OO . . . It'd be expanding the cameras in Godot, based on what they use, for production, t-v . . . <3 . . .

[marmitoTH]

A good camera is very difficult to code from scratch indeed, but what makes it even harder in Godot is that fact that it's not easy to deal with rotations. Unity uses quaternion representation by default, which is harder to visualize, but provides a bunch of very handy methods to deal with rotations:

https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Math/Quaternion.cs https://gist.github.com/aeroson/043001ca12fe29ee911e

With those methods it's very easy to, for example: match an object rotation to a given direction, easily rotate vectors, interpolate between rotations, easily rotate around a given axis and much more. I know that Godot does have an implementation of Quaternions as well, but it does not provide the same flexibility in terms of built-in implementations.

I'm not saying that Godot should handle rotation in the same way Unity does, but should at least provide better approaches to deal with nodes rotations. I hope it doesn't sound too off-topic, it seems very related to camera pivoting in my opinion, but would be an advantage not just for camera implementations, but for some others game mechanics as well.

[jasperbrooks79]

Well, in my opinion, best way to get a more ' cinematic ' look, to Godot projects . . is to make a ' FocusCamera ' and, a ' SteadiCam ' ( StabileCamera(C) lol ) . . :OOO . . 1. Because it's different from all the other engines, 2. is very cheap, in terms of code, size, and 3. because it gives you that ' cinematic ' look, should one add some post - proc., like contrast, tweak color spectrum or, range, so on . . My guess is, this is all one needs to make, to beat both Unity, and Unreal, at that ' cinematic ' appeal or, so . . and, it'd all be based on real equipment, nothing ' fake ', you can't effectively order or, buy on the internet, and that is now classic equipment, across all media, atm . . .

Then, I'd update the ClippedCamera, so it does most of what, proposal does, and say, that's Godot's version, of a ' cinematic preview ' or, like that <3 . .

Sorry, last post, I brain - storm too much <3 :( :( . . . .

So, instead of doing this, start proposal, as ' major ' improvement, to cameras in Godot 4, to get closer to ' advanced ' rigs, ' cooler ' cameras, I'd just do this, it's prob. very simple, when you study it, to simulate this stuff, not sure . . . <3 . . .

Anyway, by adding these two new cameras, which is stuff you can get for a cheap money, at least good entry - level stuff, you get option, to make ' cinematics ', that rival movies, also because it's just code, even, the steadi-cam rig, fairly simple, it wouldn't take up much space . . I feel this is a ' better way ', to add significant ' progress ', to the camera nodes . . <3 . . . it'd effectively give you everything needed, to make professional documentaries, etc . . . and, with a bit post - proc, even ' movies ', cinema . . :OO <3 <3 . . . nice, for cut-scenes, etc etc . . . I thought the original proposal was a bit limited, and to really take cameras to ' next ' level, well this would prob. be, a much bigger step forward or, so . . . .

Logically, it'd give you something better, than Unity's ' Cinemachine ', that is like 200 megabytes and, give much more ' movie ' like results, also <3 . . . if one wanted, to take the cameras, to the ' next ' level, in Godot or, so . . . <3 :OO

[Wolfe2x7]

...This can lead to inaccurate unocclusion. Also, no one uses this node for anything other than cameras.

Not true. Aspects of the current behavior of the SpringArm node are essential to my project, and it has nothing to do with a camera. Converting it into a type of camera or doing something else with it may break my project.

As it is, the SpringArm is very convenient as a built-in node to cast a shape instead of a ray. I imagine my use case is not the only one where casting a shape can be useful -- I think the main reason such a thing is not common is because the SpringArm's description does not convey that it could be used for things other than a camera.

Therefore, my suggestion on this would be to consider creating a sibling to the RayCast node that can cast a shape and return a length -- "ShapeCast" -- producing the same result as the SpringArm.

If this "ShapeCast" node could collect extra information that is available from a RayCast but not currently available from a SpringArm (get_collider() for example), then this change might improve my project instead of breaking it.

EDIT: I suppose it's also worth pointing out that my suspension model is only working with Bullet physics currently, and that I have two more experimental projects that also rely on the SpringArm as a physics collider -- the wheels of a plane, and the feet of a mecha.

One more thing that has made the SpringArm useful for me is that seems to produce smoother results for sliding over trimesh terrain than a RigidBody, whether the "Smooth Trimesh Collisions" fix is enabled or not. I don't know if that is helpful for improving collisions in general.

[me2beats]

I like the idea, I had some hard time trying to make a nice smooth TPS like camera that orbits around an object, with unocclusion, from scratch (without tutorials).

It would be great if these camera nodes were flexible

It should also provide simple unocclusion by rotation

Could be optional, when you don't want implementing unocclusion

[MewPurPur]

What's the status of this in late 2023? I see ClippedCamera has been removed, have there been any other developments?