How to move a Virtual camera with a target Framing Transposer

I have a camera controlled by a cinemachine virtual camera (CVC).
The CVC Body algorithm is set to Framing Transposer, it’s target is the player object.
Everything works nice and smoothly.

What i’m also interested in to moving the CVC with a constant horizontal speed at the same time.
(Please note, i want to move the camera not the player object!!!)

How can i achieve this too?

Hi, put gamobject under your player and set on your CVC to follow that object and then you can easy rotate that child object from your code and you wont rotate player.

1 Like

sorry, but i do not want to rotate or move the player as i mentioned, i simply want to move the CVC camera with a constant speed whilst keeping everything else intact (so CVC follow camera should keep following the target (the player))

You can animate he Framing Transposer’s Tracked Object Offset field.

7650841--953950--upload_2021-11-12_8-54-42.png

its’ kind of a catch 22 it seems to me, it has the same effect like moving the followed object

the goal would be to create a side scroller effect, keep the player object steady (till not moved by the user input) but keep everything that CVC could provide too with the framing transposer

(creating the scroll effect via moving the layers instead of the camera is not an option as the layer(s) can contain grids with tilemaps + rigidbodies + composit coliders, moving a layer like that is extremely expensive it seems)

I think at this point it would be helpful for you to show some pictures or videos of what you’re trying to do. I don’t really understand from your description.

i try to simplify it as i can

  • one (flying) player object with the usual controlls (using physics to move it, it has a dynamic, simulated rigidbody 2D + polygon collider 2d)
  • one, by a constant speed, from left to right scrolling terrain with multiple layers (with parallax effect)
  • player could collide only the content of the foremost layer that is built up from a grid + tilemap + static rigidbody 2D + tilemap collider 2D + composit collider 2D terrain

it has the effect like the player goes to the right in a cave (classic sidescroller)

there are multiple options here to implement the side scroll effect

  1. moving the layers, first i’ve implemented this one and used a CVC camera (to Framing the player, etc.), worked nicely but it has a huge performance issue because of the phyisics simulation of the foremost layer (yes, the composit collider 2D is configured correctly, it shows only 2 huge colliders, one for the “cave” upper part and one for the lower part) it clearly can be seen in the profiler that the Physics simulation takes the most time, resource

  2. moving the camera(s), i have an implementation of this too using normal Camera stacks, working nicely, using much more less resources than Option 1 but at the same time it has multiple side effects, apart from it’s complexity compared to Option 1, i’ve lost a lot of functionality the simple CVC usage gave me, like cool effects of Framing Transposer,

Actually i’d like much better to stay with Option 1 and using a really simple camera set-up that is why i’m interested in how to use CVC + Framing Transposer on a player object but at the same time moving the CVC camera with a constant speed from left to right

hope this clarifies the issue

It helps a little, but I still don’t understand exactly how you want the camera to behave.

You say that you want it to move at constant velocity left/right, AND that it should follow the player, but the player is controlled by the user so does not have constant velocity. How do you want the camera to behave, relative to the player?

i want to achieve exactly the same effect like in Option 1 i could

in that case

  • the terrain moves (it creates the parallax effect too and most importantly moves the foremost layer that gives the effect like the player is flying with a constant speed from left to right)

  • the player is framed by the CVC “Framing Transposer”, so

  • it moves the camera up, down a bit according to dead and soft zone heights

  • it does not let the player and the camera move “back” (left) as the CVC also has an attached CinemachineConfiner added to it

  • it moves the camera “even” further to the right (speeds up the scroll effect that way a bit) if the user reaches the right side “Framing Transposer” soft and hard zones

so,

  • camera “moves” constantly from left to right

  • player can move inside a framing box and

  • cannot go “backward” (out of the screen left side)

  • will “speed up” the scroll if tries to go out from the box on the right side (so never can go out on the right side either, it even cannot reach it ever)

does it make sense?

here you can see a simplified demo video about the result of the Option 1 setup

https://drive.google.com/file/d/1-DnRNOVL6oy890CL3M-t5EhB5Kl9zjCt/view?usp=sharing

Thank you, I think I understand now.

The parallax effect is not relevant here, since your parallax code should position the layers according to the current camera position, no matter how the camera moves. Make sure that this code executes after Cinemachine has positioned the camera (you can do this by using the CinemachineCore.CameraUpdatedEvent event).

If I understand correctly, you are restricting the player’s movement horizontally so that it can never affect the camera speed - unless the player moves very fast to the right, in which case the camera can accelerate to keep up. Is that correct?

I would set it up like this:

  • Have an invisible box, travelling at constant speed using a simple script that you create. Its width should be such that the horizontal movement of the player is limited the way you want it. Its height should be big enough to handle any desirable vertical movement of the player.
  • Keep the player inside the box. You don’t need physics for this, just some simple clamping code.
  • Have an invisible Game object that will serve as your vcam target. Attach a custom script to it that positions itself every frame horizontally at the center of the travelling box, but vertically at the Y position that matches the player.
  • Use that invisible object as the Follow target of the FramingTransposer vcam. Set the Y damping as you like it to soften the vertical movement. You don’t need a CinemachineConfiner on this vcam.
  • You will need some special case code in your script that moves the travelling box, to handle accelerating to the right to keep up with the player.

yepp, parallax is not playing here, just wanted to give some background what i wanted to achieve

“If I understand correctly, you are confining the player’s movement horizontally so that it can never affect the camera speed - unless the player moves very fast to the right, in which case the camera can accelerate to keep up. Is that correct?”

yes, exactly

i will give a try to your hints, thank you!

it seems to me a bit similar to what i had to add to my solution of Option 2, in that case i synced the main (base) camera y position to the player follow CVC with the transposer set up, so it “mimiced” the CVC behaivour (only the speed up reaching the right edge was not implemented, but that might also be just an extra script work as you mentioned in the last step and seems it is a must have in both cases)

just one more question, i cannot see now how it would handle the case when the user does not move the player object

i think i forgot to mention and maybe it was not visible on the video either, but in that case the player should stay still (till it does not hit the foremost terrain of course)

i guess you meant, and probably that is just accidentally left out from the description, that the player object either should be moved with the same speed than the first invisible box or must be a child object of it

am i right?

If the player has a script on it that clamps its position every frame to be inside the box, then it will automatically move along with the left-most edge of the box when the user is not accelerating. You are forcing the player to be inside the box, and if the box is moving then the player will move with it. No need for parenting.

sorry, than i was right in the assumption that it will not work this way, as i mentioned in the previous reply, i forgot to state an important requirement and unfortunately i forgot to make a few frame about it in the sample video

the player must stay still in the box, at the position it is actually, not at the left-most edge always

this is the most simpler case when the user does not do anything with the controller, the player object just travels “still” at the point where it is left by the user, it could be anywhere in the box (as i said of course only till it is not hitting something or the user does not start controlling it)

(watched back the video meanwhile, this can be seen for a few seconds at the beginning and at the end of the video)

One possibility: every frame, add the current velocity of the box to the player’s velocity. You could also try it with parenting, but then when the box accelerates to keep up with the player you might have some problems. You will find a way to make it work, there are just a few details to sort out. On the whole I think it is the right approach. Good luck.

tried it out meanwhlie (hope i was doing everything like you suggested) it gives the same result like i experienced earlier when tried to add external follow targets

  • the camera starts to move only when the invisible follow target reaches the hard zone edge (maybe can be handled with a correct soft and hard edge + damp tolerances settings, but i cannot find a proper settings, played with this a lot earlier too :frowning: as you can see on the video the soft and hard zones should totally be missing on the left edge, only at the top, bottom and right edge should trigger the camera moves)

  • because of the player is physics controlled every manipulation of its state outside of FixedUpdate and via function calls that does not respects phisics calculations in the background lead to player movement jittering

i still dont give up but actually cannot make this work up to now

The camera should be horizontally hard-locked to invisible target (which, if it were visible, would always be at the same x-coord on the screen, at the same horizontal position inside the travelling box). No soft or dead zone. Only vertical soft/dead zones. See point #3 in my earlier post.

The jittering can be fixed by turning physics interpolation on for the player, or - even better - not using physics and doing everything in Update. As a general note: do not mix Update and FixedUpdate for target movement. Either do it all in Update or all in FixedUpdate, otherwise you will get jitter because damping cannot be properly simulated.

oh, i missed that, i will try hard locked, thanks!

yes, it is clear that mixing Update and FixedUpdate could cause the jittering easier that is why i mentioned that manipulation of the player state on those ways would lead to the jittering
yes, it is already interpollated

ok, i was not precise again, i did not mention one more requirement, i would like to keep usage of the physics simulation, it makes a bunch of stuff much more convenient, collision detection, prevents colliding objects to get through each other, can simualate e.g. flying rockets, enemies with/without gravity, etc.

i cannot decide what to do, as implementing these above manually seems to be a really hard way (yes, i know there is reycasting, collision triggering events, etc.) and usage of physics has a bunch of advantages, but at the same time it seems using it has a huge runtime performance penalty too and could cause issues e.g. always have to care about not mixing Update and FixedUpdate, etc.

i’m a bit lost now i think