Confiner 2D - strange Series of issues

[tbngrd]

Hey everyone!

I’m having somewhat strange issues with the Confiner 2D component, which I’m going to try to descirbe as thoroughly as possible.

First, the way I’m generally using the Confiner 2D Component and Vcams: In a scene I have different Vcams setup with different Confiners. These are activated and deactivated by triggers, once the player enters the respective areas. This generally works perfetly, and as far as I’m aware, is about the inteneded use of Vcams, right?

Also I’m currently using Unity 2020.3.11f1.

So, up until recently I used a pretty old Version of CM, that did not yet have the specific Confiner 2D component, but the general Confiner witht the 2D option. This worked well and as expected, with the annoying, known issue of the camera damping “beyond” screen edges when using a perspective camera (which I am). So, as far as I understand, to handle this exact issue, Confiner 2D was created in newer Versions, so I updated. Now generally, this component seems fantastic, and if I can get it to work as expected it’s exactly what I want and need. However there often times seem to be, somewhat strange, issues that, from as far as I can tell, mostly have to do with the calculation of the “inner polygon” that the component generates from the Polygon Collider. I’ve tried different version of the CM package, and across different versions I seem to run into different variations of the issues, which I’m going to try to describe as best as I can further below:

• Version 2.7.1

• In this version, the component works closest to the way I would expect it to but there seems to be one major issue: sometimes the camera would still damp beyond the defined screen edges the way it would with the old non-2D specific confiner. Strangley enough, this seems to happen even if damping is set to 0 and seems unaffected by the Max Window Size. It’s not the case with every Vcam/Confiner but all their settings are identical, and it’s not the case all the time - sometimes when playing the game it does damp beyond screen edges, and sometimes it doesn’t, with no changes to the components in question.

• No matter the value i define for the Max Window Size, it always has a warning below saying “Camera window size is bigger than the maximum confinable size”. It’s safe to say I do not quite understand what an adequate value for this seems to be as the warning appears wether I enter 0, 1, 1000000 or anything inbetween. The inner polygon is drawn most optimally I would say if I have it at around 2 or 0 (I can see the shape change in the editor when I adjust this value).

• However it seems pretty hard to guess where to “draw” the polygon collider for the confinement to be accurate, as the inner polygon, no matter the Max Window Size value, always seems to be somewhat too big if I draw the collider along the lines where I’d want the screen edges to be.

• Version 2.7.2 - 2.9.0

• Now in every version above 2.7.1 the issue I experience is a different one. Generally, if I can get confinement to work, it’s much better. The camera doesn’t damp beyond screen edges, and the confinement seems more acurate to the shape of the polygon collider.

• However, for some reason, in these version, the Confiner 2D component only ever seems to be working on one single Vcam per Scene. As soon as I try to setup a different Vcam (exact same settings as the first one though) with a different confiner shape, that confiner does not work. If “Oversize Window” on the second Vcam is unchecked, it does not create an inner Polygon whatsoever, and the camera does not confine at all. If it is checked, one, or rather multiple tiny polygons, are created within the shape of the polygon collider, but they do not accurately confine the camera and cause the camera to “jump” between the multiple, small polygons created (it’s also easily visible by the Gizmo of the inner polygons that something is off). The “max window size” value does not seem to impact this in any meaningful way.

• Below some screenshots in an effort to illustrate the problem:

Above is the optimal case, that as described, only works for one single Vcam. The Inner Polygon is generated perfectly and confines the screen in a way that matches perfectly with the defined bounds by the Polygon Collider. It does not seem to matter whether “Oversize Window” is checked or not, and the “Max Window Size” value does not affect it at all.

Above is how it looks on the second Vcam, with exact same settings as the other one, when “Oversize Window” is unechecked. No inner Polygon is created (and I’m of course aware I need to use the “Invalidate Cache” method).

Above is how it looks with “Oversize Window” checked on the second Vcam. It’s a bit hard to see, but there seem to be multiple small Polygons created within the collider shape which will cause the camera to “jump” between them. The “Max Window Size” only marginally affects the size of these polygons.

The screenshots were taken with the CM 2.9.0 preview installed, but the issue persist in every version from 2.7.2 onward.

Now I do not know if I’m missing something obvious or if I’m fundamentally using something in the wrong way, but I now thourughly tested this in every version of CM and seem not be able to arrive at the behaviour I need, so I decided to make this post and hope that I have described the issue in a way that one is able to make sense of it somewhat.

I would love to hear some possible pointers in the direction of what could maybe solve this issue.

Also a huge thank you to the Cinemachine team at this point for the awesome work you guys do, I love CM and up until trying out this Confiner 2D component, never had any issues with it. Makes everything camera related sooo much easier!

Cheers,
Thierry

[gaborkb]

Hi
Thank you for looking into this issue and providing such a detailed description!!

Version 2.7.1

@tbngrd

the camera would still damp beyond the defined screen

This is a bug of this limited confiner2D version.

@tbngrd

• • No matter the value i define for the Max Window Size, it always has a warning below saying “Camera window size is bigger than the maximum confinable size”. It’s safe to say I do not quite understand what an adequate value for this seems to be as the warning appears wether I enter 0, 1, 1000000 or anything inbetween. The inner polygon is drawn most optimally I would say if I have it at around 2 or 0 (I can see the shape change in the editor when I adjust this value).
• However it seems pretty hard to guess where to “draw” the polygon collider for the confinement to be accurate, as the inner polygon, no matter the Max Window Size value, always seems to be somewhat too big if I draw the collider along the lines where I’d want the screen edges to be.

Max Window Size’s value is for optimizing the calculation of the inner-polygon. If you are going to change the camera window size during your game, you should pre-calculate the inner-polygon using this value. The inner-polygon calculation can be costly, so it could cause an fps drop.
When the camera is in Orthographic mode (which is not the case for you), Max Window Size represents the maximum Orthographic size, the camera is going to have while the game runs. If you set it to 0, we calculate the confiner until it has only ~0 area polygons (~lines, ~points). When the camera is in perspective mode, Max Window Size represents the maximum FrustumHeight, the camera is going to have while the game runs. This is something, you need to find (either by experimenting or calculating it).

The warning message in Version 2.7.1 is always displayed, because Confiner2D in that version was not able to calculate the inner-polygon fully. It is a warning for the user to expect that the calculated confiner may be wrong. The wording might be confusing though, I agree.

Version 2.7.2 - 2.9.0

@tbngrd

The camera doesn’t damp beyond screen edges, and the confinement seems more acurate to the shape of the polygon collider.

That’s good to hear!

@tbngrd

However, for some reason, in these version, the Confiner 2D component only ever seems to be working on one single Vcam per Scene. As soon as I try to setup a different Vcam (exact same settings as the first one though) with a different confiner shape, that confiner does not work.

The confiner shapes are calculated, but the calculated inner-polygon is displayed only on the currently live camera. You can check this by using a Solo button. If you Solo a vcam (that’s not live), then you’ll see the calculated inner-polygon. Do you see the calculated inner-polygon in this case?

I agree it is confusing to not see the calculated inner polygon. It should not care whether the vcam is live or not. I logged a feature request for this.

@tbngrd

However, for some reason, in these version, the Confiner 2D component only ever seems to be working on one single Vcam per Scene. As soon as I try to setup a different Vcam (exact same settings as the first one though) with a different confiner shape, that confiner does not work. If “Oversize Window” on the second Vcam is unchecked, it does not create an inner Polygon whatsoever, and the camera does not confine at all. If it is checked, one, or rather multiple tiny polygons, are created within the shape of the polygon collider, but they do not accurately confine the camera and cause the camera to “jump” between the multiple, small polygons created (it’s also easily visible by the Gizmo of the inner polygons that something is off).

It looks like your camera window is very big for this confiner, so it collapses down to those small polygons. If you make your confiner a perfect rectangle, you will get a line instead. Is that the case? Does that fit your needs?

You could also play with your FOV. For example, making it smaller when your player enters this narrow area.

@tbngrd

The “max window size” value does not seem to impact this in any meaningful way.

Edit:
I could reproduce it on my side. However, this is not a bug as I though at first.
Trying to put it very simply, the reason why it does not affect your case, is that the resulting sub-polygons are very simple. Our calculation results have some ranges within which they will work. When a polygon becomes two or more sub-polygons, that’s when a new range starts. In your case, I think (just by looking it at), it starts as one polygon, then it probably breaks into two at some point. Then those two polygons collapse into a nearly 0 area polygon were the calculation stops.

@tbngrd

Above is the optimal case, that as described, only works for one single Vcam. The Inner Polygon is generated perfectly and confines the screen in a way that matches perfectly with the defined bounds by the Polygon Collider. It does not seem to matter whether “Oversize Window” is checked or not, and the “Max Window Size” value does not affect it at all.

Oversize Window is not affecting the result, because the camera window for that confiner is not too big, so it is not oversized.

Let me know if you need more help or something is not clear.

[tbngrd]

Hey thank you so much for the reply and clearing some things up @gaborkb !

The confiner shapes are calculated, but the calculated inner-polygon is displayed only on the currently live camera. You can check this by using a Solo button. If you Solo a vcam (that’s not live), then you’ll see the calculated inner-polygon. Do you see the calculated inner-polygon in this case?

In most cases yes, however there’s still cases where, according to the info you provided, the confiner collider is probably too small and the camera is not confined at all when playing. Gonna elaborate further down.

It looks like your camera window is very big for this confiner, so it collapses down to those small polygons. If you make your confiner a perfect rectangle, you will get a line instead. Is that the case? Does that fit your needs?

That does not seem to be the case, no. Here’s how it looks with as perfect a rectangle as I can get the Polygon Collider to be:

This is in V2.7.3 (version chosen somewhat randomly). There is still 2 separate inner polygons created, causing the camera not to track all the way when moving through this area, but jumping abruptly from one polygon to the other. If it were a straight line, then yes, that would probably do it. I just tested it by making the collider wider which, in fact does create a better result and I’m not sure might actually be the solve of this problem lol - I’m still gonna elaborate further in case someone stumbles across this thread. Here’s how it looks with a wider Collider:

This is indeed much better and in fact what I wanted. I think you’re assessement, that it was simply the confiner shape that was drawn too small, was correct. I feel kinda stupid now, lol.

I could reproduce it on my side, this is a bug!
Ideally, if this would be working correctly, you would be able to stop the confiner calculation before it collapses to those small polygons. In this case, you would not need to make a perfect rectangle like I suggested above, though it may still help.

Yes, not allowing it to collapse to those small polygons would definitely be preferable as it is still irritating when it happens. Glad I could help in pointing out this bug. The behaviour in V2.7.1 to this is actually preferable I would say - here’s how the same, narrow, Confiner looks in 2.7.1:

This is in 2.7.1, the inner Polygon can be adjusted with the Max Window Size. While this obviously doesn’t confine accurately to the collider shape, as it is too small as we’ve realized, it’s much less confusing than the tiny split-up polygons haha.

So, this mainly seems to have been a case of me being too daft to realize I’m drawing colliders too small. When drawing bigger collider shapes, it seems to work. I feel kinda silly now, but maybe this thread will help someone else stumbling across it, haha. Thank you so much for making me realize my mistake!

I’m going to do some further tests, respectively setting up the confiners as I need them in game - and I would update here in case I’m running into further issues. Thanks a lot for your help and elaborate reply @gaborkb ! Have a great weekend.

[gaborkb]

@tbngrd

Yes, not allowing it to collapse to those small polygons would definitely be preferable as it is still irritating when it happens. Glad I could help in pointing out this bug. The behaviour in V2.7.1 to this is actually preferable I would say - here’s how the same, narrow, Confiner looks in 2.7.1:

@tbngrd

This is in 2.7.1, the inner Polygon can be adjusted with the Max Window Size. While this obviously doesn’t confine accurately to the collider shape, as it is too small as we’ve realized, it’s much less confusing than the tiny split-up polygons haha.

This feature was dropped. But I’ll log it again, and we may reintroduce it. Thank you for the feedback

Have a great weekend!

[tbngrd]

Hey @gaborkb

Just a quick follow up to this post, as I think I just figured out how to get the exact behaviour that I want.

I experimented a bit with the Confiner2D, and while screen edge confinement worked well, I felt the camera movement got a bit rough, and not as smooth as I’d want it to be with the somewhat “weirder” confiner shapes, that aren’t just squares.I realized, that in some parts of the level I actually prefer the behaviour of the normal Confiner that damps “beyond” the confinement shape, as it looks a lot smoother than the somewhat hard-stop caused by the Confiner 2D.
It’s just at the “hard edges” of the map I’d want to have the Confiner2D behaviour.

I thought this was a trade-off I had to accept, but only just now I thought of if I could have both? A normal Confiner that confines the “main path” through the level, and a Confiner 2D that confines the hard screen edges. I thought that would surely cause some kind on conflict - but I just tried it and it seems to work?! Putting both confiners on the vcam seems to work fine so far and gives me the behaviour I want. It looks like this:

The large outter collider is assigned to the Confiner 2D and confines the hard screen edges, and the weird shape inside is assigned to the normal Confiner that leads the camera through the level. I have damping set to 0 on the Confiner2D and to a pretty high value on the Confiner to give me as smooth-as-possible camera movement. The only main thing I need to be careful of is that the inner polygon of the Confiner 2D and the confinement collider shape of the normal Confiner match up in the region of the screen edges so the Vcam doesn’t get “confused” where to go with conflicting confinement shapes.

It works! It solves my main problem of the camera pushing past screen edges at the exit points of the map, while retaining the buttery smooth camera movement through the rest of the map.

I thought I’d share my experience and wanted to ask wether this is a good idea or if there are some downsides to this I’m not yet noticing? I haven’t seen this method promoted anywhere, so I’m a bit worried I’m overlooking something important, haha.

Anyway, I just thought I’d let you know that this is a use case to solve a problem I think might not be that unusual in a 2D game. And if the using-2-separate-confiners-on-one-cam method isn’t optimal, maybe it could be considered for a future feature to have 2 confinement shapes, one for the “smooth” confinement, and one for the “hard” edges.

[gaborkb]

Interesting idea! We’ll look into this!

[tbngrd]

@gaborkb

Interesting idea! We’ll look into this!

Cool! I tested it some more and it really seems to be the solution I’ve been looking for all along.