00:00
00:00
Newgrounds Background Image Theme

Our goal is for Newgrounds to be ad free for everyone! Become a Supporter today and help make this dream a reality!

Any other Unity devs having trouble using camera relative movement with Cinemachine?

750 Views | 2 Replies
New Topic Respond to this Topic

Hey all, I'm messing around in Unity trying to make a 3d game, and I've been using the Cinemachine camera. It works wonderfully in terms of rotating around my character, etc. Feels good, works good, input for rotating it works. Simple.


However,


I need my player character's movement to be relative to the angle that the camera is facing instead of the worldspace so that you can actually, like, go places and understand what's happening lol. I found various tutorials, etc. on this and I managed to get it to work kind of but it doesn't quite... do it... right.


Instead of making the player's "forward" directly correlate to the direction the camera is facing, it just kind of... flips it? It's a bit difficult to explain. Basically when the camera's rotation is any positive value, the player just moves around in relation to the worldspace like I didn't program anything at all, then when the camera's rotation value is negative, the controls completely flip so the player is facing the opposite direction, but it's still only relative to the worldspace. Everything is just opposite.


My main question is: Anyone who has experience with Unity, does Cinemachine not work well with camera relative movement at all? If the answer is "no, it should work fine" and it's probably something in my code, I'll gladly post it and try to work through it if anyone wants to help out. If the answer is something like "Yes Cinemachine is terrible for that" then I'll just have to start over in regards to the camera.


BBS Signature

I ran into the same issue. My solution was to invert the z-axis, then unbind the camera from the phi-angle component of its PYR matrix. Then write your own function for transforming from whatever coordinate system you have the original movement occurring in to a 4-field (5 degrees of freedom with the phi angle held constant).


Make sure this function overrides Cinemachine's camera's PYR_to_Spherical method (look up documentation to see its signature but make sure you add an optional parameter for whatever constant you set your phi angle to) and programmatically un-invert the z-axis on invocation of this method.


If you're worried about a performance hit know that the Unity engine caches anything attached to Camera objects with "barriers-to-invocation" protocols for methods that had a camera parameter altering side effect. So further calls to your custom function won't actually have to execute any code once the z-axis has been re-enabled.


edit: I should probably explain why this works. Cinemachine was ported over from a similar open-source tool that the Unreal guys used for their last version of Unity. Matrix transforms in that version of Unity were using a naive Clifford algebra with a bug due to a faulty "twisting" matrix (for contorting 3d objects with a cylindrical force flow around some axis). Something as ridiculous as an rsin(theta) instead of an rcos(theta). The problem would only manifest when doing very SMALL scale simulations with low particle counts. But when this was used for Unity's twisty methods, it broke more than just twistiness because Unity's Clifford algebra type was implemented correctly but uses the same object name for the cylindrical force field method. So this override cascades into a lot of things in Unity's camera work. The problems have been fixed one by one (rather than fixing the underlying matrix - I have no idea why) and the camera issue hasn't been. When you write your custom function, the override by default calls an older class of camera objects that didn't even have fields as child classes.


= + ^ e * i pi 1 0


At 8/20/20 03:12 AM, sharpnova wrote: I ran into the same issue. My solution was to invert the z-axis, then unbind the camera from the phi-angle component of its PYR matrix. Then write your own function for transforming from whatever coordinate system you have the original movement occurring in to a 4-field (5 degrees of freedom with the phi angle held constant).

Make sure this function overrides Cinemachine's camera's PYR_to_Spherical method (look up documentation to see its signature but make sure you add an optional parameter for whatever constant you set your phi angle to) and programmatically un-invert the z-axis on invocation of this method.

If you're worried about a performance hit know that the Unity engine caches anything attached to Camera objects with "barriers-to-invocation" protocols for methods that had a camera parameter altering side effect. So further calls to your custom function won't actually have to execute any code once the z-axis has been re-enabled.

edit: I should probably explain why this works. Cinemachine was ported over from a similar open-source tool that the Unreal guys used for their last version of Unity. Matrix transforms in that version of Unity were using a naive Clifford algebra with a bug due to a faulty "twisting" matrix (for contorting 3d objects with a cylindrical force flow around some axis). Something as ridiculous as an rsin(theta) instead of an rcos(theta). The problem would only manifest when doing very SMALL scale simulations with low particle counts. But when this was used for Unity's twisty methods, it broke more than just twistiness because Unity's Clifford algebra type was implemented correctly but uses the same object name for the cylindrical force field method. So this override cascades into a lot of things in Unity's camera work. The problems have been fixed one by one (rather than fixing the underlying matrix - I have no idea why) and the camera issue hasn't been. When you write your custom function, the override by default calls an older class of camera objects that didn't even have fields as child classes.


Thank you so much! I will admit, a lot of what you conveyed is beyond me lol, I've I've never even messed with phi-angles or matrixes. Every time I start to think "Yeah, I'm a programmer!" something like this comes along that makes me feel just as clueless as I was on day 1 again, haha. I really do appreciate you giving me an explanation and a place to start, though! It may take me a while, but with your explanation I should be able to get this worked out. Is there any documentation on this our there about binding/unbinding the camera? Thanks again!


BBS Signature