Cinemachine Collider Component Not functioning as Expected....is it a bug?

To start some background info on me. I am completely new to game dev. I know literally nothing and may just be completely wrong about this. Knowing that I may just be doing something wrong I thought it best to ask rather than try to file some formal issue bs or anything. So here goes I hope I can explain it well enough.

I am using unity2017, freshly installed today. I am trying to get a virtual camera to collide with a wall and stop itself from penetrating the wall it collides with. I don't want it to do anything else other than track and look at one object, a cube in this instance. Should be a simple task I think but I can't seem to do it. I have made a test scene with 3 primitives created by unity all cubes and one virtual camera/main camera combo. The cubes are named ground, wall and target. The virtual camera is set to follow and aim at the target cube. I made it as absolutely simple as I possibly could. Everything was left at default the way it came out of the box except for the vCam which had a collider component attached with the line of sight check box disabled. The camera tracks perfectly, follows and aims correctly. When it gets pushed into a wall it will collide and push away or resist entering but only to the distance of the curb feelers roughly before it goes through the wall. If I want to keep the camera from entering the wall I have to set the curb feeler distance equal to the distance of the camera offset. If set to a reasonable distance the camera will enter a wall long before the cube gets to it.

to summarize: one camera tracks one object and the collider doesn't collide for very long with the line of sight disabled. When line of sight is enabled it does all the work. How do I get the collider to just collide and not slide down the wall because the line of sight feature forces it closer to the target instead of the collision taking over and leaving the camera high on the wall looking down at the target.


Attached is a copy of the test project if you need further clarification.

 

Help? Anyone?......even a simple it's supposed to be that way would work. I don't even know if I'm doing something wrong and the collider is supposed to require the line of sight checkbox to be active. It seems like the collider is broken to me. If it requires line of sight to be active why can I disable it? Does it work right for everyone else? Am I just not getting the hang of how it should work. Im completely lost here.

 

I hate to sound desperate but has anyone else used the collider component effectively?

 

Hi Franken. I am using but still have some problems. Waiting for the collision demo they promisse

 

At least I'm not alone

 

I had read in one of you other posts that you were on vacation so I wasn't really pushing the issue. That and I almost dont even feel right asking too loudly since I don't really contribute as of now. Im using the free unity and I'm not even experienced enough to answer questions on the forum much. Anything you guys do for me is just that, doing something for me, since im not doing much for you. I am glad you do these things and I hope to be able to give back in time. For now all I can do is say thank you for letting me know I was correct in my line of thinking. I am at the point in learning where I'm not always sure if im wrong or if it actually is a problem and you cleared that up for me.

I was working on a way of achieving close to what I wanted using the priority system on a cloud of cameras but that seems wrong to me even when it works. It's just too much going on to do what could be done by one virtual camera. I tried having the virtual cam following a cube with a rigidbody collider and addForce. I couldn't get it to follow quickly enough to suit me. Im looking for near perfect tracking with no dampening and just wasnt getting it good enough. I have been trial and error tinkering for a while now but just haven't come up with the right thing. Now that I know it is an actual bug that may get fixed I will move on to other things for a bit and see what happens.

 

I'm also having some issues with the Cinemachine Collider - it seems to be colliding with trigger objects.
Based on my experience working on chase cameras, you're going to need a lot finer control than picking a single layer for the camera to collide against. Being able to filter by tag as well would be simple but really useful.

I'd also like to be able to set a transition speed for the avoidance adjustment, so that the camera doesn't jump-cut. I know that risks clipping through things, but that's a trade-off I'd like to make the call on myself.

 

@Chris_Payne_QS we're working on Collider. It's 'not there' yet and we hear you. Tags is a great idea as is the transition speed, you're right, people need to make that call themselves.

It's going to get better, we will be releasing an updated version of Collider in the not too distant future.

 

I feel your pain - I wrote the chase camera for LEGO Worlds and it was an absolute nightmare trying to solve all the edge cases and even decide what the desired behaviour is in some awkward spots. In most LEGO games we solved tricky hub areas by placing a dedicated cam volume that ensured you got a workable view, but in a user-editable world you're relying 100% on code.

We had a whiskers-style solution for guiding the camera away from obstructions, but if the player took over we had to respect their choices and just dolly the camera in if they pushed it against a wall or something blocked your line of sight. Seeking that dolly distance instead of cutting made it look far nicer...and we latched it in that mode until the player moved again. In LEGO Worlds we solved the occasional near-clipping by nibbling the LEGO away if the camera got too close (also useful for when the editor camera embeds in a hillside).

We also had a LOT of custom behaviour depending on whether you were moving, or in a vehicle, or flying, or doing any of the wide variety of mechanics. Chase camera for an articulated truck with a trailer is also a nightmare...

 

Wow @Chris_Payne_QS great experiences. LEGO Worlds is awesome. Yes, collisions are one of the trickiest problems and we have the additional challenge of trying to design/build something which is as versatile and game-agnostic as possible. I'm going to checkout LEGO Worlds again to try and grok what you did.

Custom camera behaviors based on gameplay events can add so much to the overall presentation. Personal record is around 20 free-look rigs for a single character localmotion system. Many were just little subtle changes.

Thanks for your feedback and please don't hesitate to share more as we're always on the lookout for good designs and solutions to these problems. Your opinion and experience is valuable to us.

 

You'll probably find it's a lot better than I left it, as the team will have had a year to solve even more corner cases!
One interesting thing is that a lot of mouse/keyboard PC players did NOT like the console-style chase camera with smart avoidance of obstacles. They were used to a much more minimalist approach where the 3rd-person camera is basically a 1st-person camera pulled back a few metres, and they were 100% responsible for camera positioning....so we added that as an alternative mode.

 

Im tuned.....thank you. I will be sure to tell you what a great job you've done soon.

If this means a desired offset of 0,5,5 yields a result of 0,5,1 when 1 unit from a wall on the z axis you are my hero for the week.

 

Haa.. No not yet. I have been busy with my paid job to the point of exhaustion. I work in farming and it is harvest season. I just now got time to check in. I will be trying it out very shortly. Im sure I will be pleased. I will post back after I've had some time with it and let you know for sure but as of now just consider yourself personal hero.

 

@Gregoryl I have had a few hours with the new collider and I like the direction you went with it. Having preserve height vs preserve distance is something I hadn't thought of. I am still finding it a bit twitchy under certain circumstances but I haven't put a great deal of time into adjusting settings and perfecting things. I will say that it all seems to work as expected though so hero of the week is definately awarded. Just pin a small badge to ur rubber duckie and call him Darkwing for a week. Seriously though, good work and the problem I had was solved. THANK YOU.

There is one question I do have though in reguards to the way line of sight detects line of sight. It seems to me there is a single ray cast from camera to lookAt target that initiates the change in camera offset when broken. Works perfectly to keep the point it looks for in view but seems to only care about that single point. 90% of the target can be occluded but line of sight won't take effect until the center of the target becomes occluded. Obviously it would not be appropriate to take the entire mesh of the lookAt target into account but is there a way to widen the area it looks for? For example if an area for 1 unit radius from center of lookAt target is occluded initiate line of sight. Is there a checkbox or line of code I can alter to make it spherecast as opposed to a single point ray? Is there another method that I am completely missing?

 

Thought this might be the case but was hoping I could switch a raycast out for a spherecast or some other hack. Not a real big deal though. As for twitchy behaviour it only shows itsself when the camera is pushed into 2 surfaces one above and one to the side AND line of sight gets broken by another object with preserve height mode. So it is a edge case that can be avoided and adjusting some of the settings lessens it when it does happen which isn't often in the first place.

My use case works well now and the line of sight does what I would expect it to. It does still seem like the actual collision still dosent work other than that of the camera radius which works perfectly. The reason I say this is because the collider component completely quits functioning when the line of sight checkbox is disabled. Not a problem now that line of sight works correctly but it is a bit confusing to have an option that breaks the entire functionality of the component when unused. As far as I am concerned that checkbox could just be removed as there is no real need to use the collider without it. All in all good work though and I can say cinemachine can do anything I need well enough so I wont need to use any other options. Thanks for all of the help.

 

That makes perfect sense. I understand now. I hadn't thought of another way of using it.