I'm using Cinemachine Confiner extension to prevent virtual camera from reaching out 2D boundary. But it seems not work as expected. Here is my step: 1. create a plane with box collider as large as the scene 2. drag the plane to Bounding Volume of Cinemachine Confiner Please have a look. Thanks.
It's working for me. I'm using CM 2.1 RC4. What behaviour are you expecting, and what are you getting? Note that even in a 2D scene, the box collider needs to be a 3D object, whose position is such that the camera will be inside it. So, if the camera is 10m in front of the game plane, then the box collider needs to include the plane where the camera is: either position it at z = -10, or have its Z size big enough to include the z=-10 plane. Here is my vcam setting: And here is my collider plane:
Worked! I guess the reason why the camera beyond the bound is I did not check "Confine to screen edges"...Is it be good if it was by default?
I just want to share my thoughts on the way the Confiner 2D works, or should works more specifically. I struggled for some time before I realized something : Each time I assign a new PolygonShape2D (for example) to the confiner, I had to call "InvalidatePathCache" method. To me it is not intuitive because the confiner let us know (the client of the API) of its internal "poutine" and it should not work that way. Of course, when I assign a new Shape to the confier, it should invalidate automatically its internal cache, that's the contract I have with the confiner. Suggestion, instead of having a public member m_BoundingShape2D, give us a method or a property, in that case you could invalidate the cache automatically each time a user set a new BoundingShape... That my 2 cents..
hey, cinimachine 2.5 does not have an check box option of confining screen edge, and I am having problems to confine the camera in a 2D polygon collier. Have any idea what may went wrong? I was following what this tutorial said and It did not work out. It is step 5 and 6.
Hi! Is this already fixed? I dont know if that is the problem I am having but everytime I set new bounds (at runtime) they dont work properly, But if I reload the scene with the new bounds set before hand they do work! Edit: Yes it was exactly that. I just added the InvalidatePathCache() before changing the bounds and now it works. At least I only wasted like 4 hours on this!
Something else to add to the list of fixes with Confiner2D: When editing a Polygon Collider 2D's points while the editor is running the game, it will completely break the cinemachine camera. I say completely, but essentially when the screen edge hits the updated collider, it will--what it appears to do anyway--is immediately teleport(or move quickly with enough dampening) the camera to a location that is within the polygoncollider2d's original boundaries before being changed. If I double the size of my polygon2d collider's extents--this is a very significant unity space jump. Took me several hours to figure out this bug. Was honestly ready to throw cinemachine in the trash and just code my own solution, but lucked out and saw the above mentioned bug and tested it out myself in the editor's game window while playing to see if it was a similar issue. It's more than assigning a new collider--even changing the collider's extents seems to cause mayhem.
@robcbryant For performance reasons, the confiner will not check every frame if the polygon points changed, and will just use cached values. If you change the polygon, you must call confiner.InvalidatePathCache().
You can use the new Confiner2D extension, which ships with CM 2.7.1. It can confine screen edges for perspective cameras also.
Hi, just a quick question, my project use 2020.3.7f1 version of unity and the last version available for cinemachine seems to be the 2.6.4 where i cannot find the new confiner 2d extension.
You need to enable preview packages. Edit -> Project Settings -> Package Manager -> Enable Preview packages or Enable Pre-release packages.
Good morning! Sorry for the distraction, but I need help. I have not found any clues on either google or youtube. I have several locations on the same stage. And for each location, I need to make a CameraConfiner so that the camera does not go beyond the edges of the location. I know how to do it in one location, but I don’t know how to do it in all locations. And if you teleport, the player teleports, and the camera stays at the first location, because the confiner blocks any exit from the camera. I have a 2D Top-Down game.
@Crazy_Moose You could create a CinemachineVirtualCamera (vcam) with a specific CinemachineConfiner2D extension for each location. When you enter a "location", you could activate the specific vcam for that location using trigger volumes (CinemachineTriggerAction). For an example on trigger volumes, see our example scene called "Trigger volume". If that's not useful, then please provide more details. For example, a drawing of your map layout, and where you would like to put your confiner areas. Why don't you have one 2D confiner around the whole map?
Because I have several locations. A teleport leads to each location. There is no other way to enter and exit them. And when I teleport to any of the locations, the camera remains in the location in which it was originally, because the confiner does not allow it to move with the player.
I don't understand a little ... I created a CinemachineVirtualCamera (vcam) with a specific CinemachineConfiner2D extension, but how do I do this for each location? And how to activate a specific video camera for that location using trigger volumes (CinemachineTriggerAction)? Sorry, I'm a little dumb ...
CinemachineBrain will pick the vcam that is enabled and has the highest priority value. To activate a vcam, you can disable all other vcams, and enable just the one you want active, or you play around with priority values. When you enter a portal, you know which vcam you want active. For example, portal 1 - vcam 1, portal 2 - vcam 2, etc.
Thank you! It works. But a new problem has emerged. confiner which is located in a location with a bunch of corners. He breaks my camera. The camera does not see the player everywhere. What can you do about it?
Hey Greg, I've got an interesting case I was hoping you might be able to lend some advice - my game is 2D, but with overhead view and using a Perspective camera (so I can do parallax, etc). It seems like the default behavior if you have a Perspective camera and use a CinemachineConfiner2D is that it confines the 'screen edges'. This doesn't work well for my game for two reasons: 1) Narrow vertical hallways - the player could be playing with their resolution set to any aspect ratio, so if I set up the PolygonCollider2D to be the appropriate width for the hallway for 'widescreen', then someone playing with 'ultra-widescreen' wouldn't allow the camera to pass through that hallway at all. 2) I do a lot of zooming in/out (by changing the Field Of View). I don't want this to affect the camera boundary. I think the ideal solution for my case would be that I set up a Polygon2D that would only confine the CENTERPOINT of the camera (not its 'screen edges'). Do you know if there is any pre-built functionality to achieve this, and if not - do you think this would be something I could modify/customize the existing code for? Thanks a ton for any help! We're actually right at the end of development and in crunch mode so if I could get this checked off of my to-do list it would be amazing Also quick note - the scene layouts in my game are complex with lots of weaving hallways, so I don't think I can use a 3D shape (like a 3D Box collider). Edit: Forgot to mention I'm using version 2.8.4. Would be glad to update if that adds any relevant functionality!
If you have no control over the size and aspect of the camera, I don't see how you can expect to confine it at all, beyond perhaps a global bounding shape to contain screen edges at the stage boundaries. Or perhaps I'm not understanding your situation. Could you describe a little more the behaviour you expect? Some images to illustrate better would also be helpful. Feel free to DM me if you don't want to post details publicly.
Hey Greg, thanks a ton for the quick response! Seriously appreciate it. I think my end goal is to confine the centerpoint (ignoring the z-axis) of the camera within a PolygonCollider2D. This would make it so the aspect ratio and the FOV don't affect the confining system. Here is a screenshot of a hallway where the player can go from the topleft of the screen to the bottom right of the screen, this is around what the level of zoom (FOV) would actually look like when playing the game: Here I zoomed out a bunch in Scene view to show this whole section of the scene: What I'd like to do is confine the centerpoint of the camera within a PolygonCollider2D: Any thoughts on this? From your response I'm starting to wonder if the Confiner functionality was more intended to confine the whole view (aka the 'screen edges') rather than what I'm looking to try, which would be just keeping the centerpoint of the camera within the boundary? Thanks again
If you use a CinemachineConfiner extension (as opposed to the CinemachineConfiner2D), and set its mode to 2D, then you can provide a 2D polygon to which the camera center will be confined. However, I'm wondering: assuming that your camera is tracking the target, won't it just follow along naturally without the confiner? Given that you can't control he aspect ratio, you're committed to accepting that sometimes the areas outside the corridor will be visible. So what is the confiner bringing that you don't already have?
Nice, this seems to be exactly what I'm looking to try out! Thanks for being interested enough to ask that question Our game is set up so there is foreground-visuals (that is pitch black colored, so it matches the default pitch black of any empty area beyond) surrounding the edges of the gameplay areas/walkways/etc. So our reasoning for the camera confiner isn't to restrict what the player sees, its purely to give the player the sense of where they can't go. We have a lot of nooks & crannies in the game, and we think a lot of players might end up "hugging the walls" trying to see if any of the nooks & crannies are places they can actually go. But if the camera stops moving as they walk into one of the nooks/crannies, thats a really good indication that they can't go through there. I recorded a little video of what I mean - first with the confiner applied (so as I go down into the nook at the bottom of the screen, the camera stops following the player, indicating they can't go down there), and then I removed the confiner and walked down into the nook: https://i.imgur.com/YkRb3be.mp4 If you have any further thoughts/feedback I'm all ears! I think the only thing I'm noticing with using this setup is that I'll have to be very careful about making my 'corners rounded' with the 2D Polygon shape. I tried out a 90 degree edge and since the confiner is basically positioning the camera at the "closest point within the polygon", as I crossed over the 90 degree edge the camera would pop from one side to the other. I'm hoping that after I do some more testing I can figure out how to shape the corners of the 2D Polygon to avoid that popping. And again thanks a ton for your help! Edit: Oh, I did actually have one more question - I was hoping to use a single PolygonCollider2D for the confiner for the entire scene (for simplicity's sake). But this would mean potentially hundreds of vertices for that polygon. Do you have any recommendation on how many vertices would be approaching "too much"? The content in our scenes are also split into 'rooms', so we could instead have one PolygonCollider2D per room, rather than a single one for the entire scene, but that would mean a lot of extra work making the room-polygons match up with each other where the rooms overlap. (also just FYI we wouldn't need to
Thanks for the explanation. It makes sense. It stands to reason that polygons with more sides will take longer in the FindNearestPoint algorithm. Under the hood, it's going to have to iterate the segments and compute closest distance from each. Dividing into smaller polygons is probably a good idea.