In my game the Cinemachine Virtual Camera has Noise (Handheld_wideangle_strong) and in the inspector I can see Amplitude Gain and Frequencey Gain values I can adjust.
Is there possibility to access these values from another C# script? What I’m trying to do is when the player moves away from certain point the camera starts to shake more and more as player gets “sick and dizzy” in the game. So using the Vector3.distance I could add Amplitude Gain and Frequency gain higher when the player moves far enough.
How can I change the Follow and LookAt transform with C#? In the beginning of the game I need to find player who is spawned for the virtual camera with GameObject.Find.
I quess I need to access the m_Follow and m_LookAt in the Cinemachine Virtual Camera script.
The Cinemachine documentation is not yet part of the Unity manual online. Until is it, we ship documentation directly with Cinemachine. You can access it from Cinemachine/About:
You don’t need to import anything. It should work. What parameters are you trying to access? Can you post the code that’s giving you trouble? Also if you look at the CinemachineExamples, there is a scripting example there which demonstrates how to access the parameters.
I want to access this to control footsteps on a FPS camera setup i’ve done, thing is i have multiple virtual cameras, so is there a way to directly access some global noise parameter throught the cinemachine brain or something? my setup is simple, one idle camera (with its noise profile), walk cam, run, cam, etc. so, unless there can be some sort of event that can be triggered in the noise profile that i dont know off, i would like to trigger a footstep lets say, when some of the values of the noise profile is above 0.99f and below -0.99f(assuming a -1 to 1 fluctuation) and yes, i did a custom noise profile that resembles a head-bobbing when you walk/run, etc. any way to do this? or is it a better way lol? @Gregoryl
I’m not sure I fully understand your question. You are implementing head bobbing using perlin noise components on your vcam, with custom head-bobbing noise profile? And you want the bobbing to be turned on/off depending on some global setting? Perlin noise on the vcam probably isn’t the best approach. Better would be either with Impulse (emit the bobbing impulses when your character walks) or with a custom extension that applies a perturbation in response to events that you control.
I was trying to do it the other way around, i already have the cameras set with the head-bobbing noise, what i asked, in short, is this: Can i access the current noise being played in the current camera by code? i figured that way i could sync my footstep sounds with the current head-bobbing, thats already there. Or is it possible in any way to trigger an event in an specific moment, previously setted in the noise profile asset? like pretty much what you do when you mess around with the curves and the events in the animation import settings of some characters animation? if thats not possible, it could be a nice feature for the future i think
I understand better now, thanks for the description.
There is no event that can be fired from the noise profile. You could possibly write some code that monitors CinemachineBrain.State.CurrentCameraState.OrientationCorrection (or PositionCorrection, depending on how you set up your noise profile). The noise value will be in there. However, if you have other CM extensions (e.g. Collider, Confiner, others too) then they may also contribute to this value and confuse your code, so it’s not foolproof.
Much better would be to implement the footsteps with Impulse: emit one impulse per footstep. You can have multiple listeners that respond to the impulses, so it’s a much better paradigm for what you’re doing, I think.
What I think is really useful in the ParticleSystem modules is that they provide additional “multiplier” properties (see here). This allows to drive particle values without having to backup the original value first.
Rather than manipulating m_AmplitudeGain directly, Cinemachine could provide a m_AmplitudeGainMultiplier that is only used by user-code and initialized with 1.
Internally, Cinemachine would calculate the amplitude gain as m_AmplitudeGain*m_AmplitudeGainMultiplier then.
User code then only needs to modify m_AmplitudeGainMultiplier. Want to have 50%? Just specify 0.5.
This allows to change Cinemachine properties easier than it’s right now. It wouldn’t even break backwards compatibility. What do you think?
Well, that’s kind of what amplitude gain already is: a multiplier for the noise coming in from the signal.
Are you suggesting that we add this sort of thing for all vcam properties that someone might want to change by script?
I’m trying to say that properties, that don’t mess with the original values, for things that are expected to be changed via scripting make working with the system nicer.
For example, if I enter “2.66” as amplitude gain in the Inspector, I still want to use this “designed” value in my game when I modify the noise. In my particular case, a racing game, I want that the noise intensity depends on the speed.
0mph = 0 amplitude gain
60mph = the designed amplitude gain, in this case 2.66
In game code I would calculate a weighting factor between 0…1 which represents the 0…60mph range, lets just call it t.
Now I have several options…
I can cache the designed amplitude gain:
float m_DesignedAmplitudeGain;
void Start()
{
m_DesignedAmplitudeGain = noise.m_AmplitudeGain;
}
void Update()
{
var t = CalcWeightingFactor(speed);
noise.m_AmplitudeGain = t * m_DesignedAmplitudeGain;
}
I can ignore the designed value in the Inspector and hard-code it:
void Update()
{
var t = CalcWeightingFactor(speed);
noise.m_AmplitudeGain = t * 2.66;
}
Or what I would prefer and think it’s the better solution of the three, I set a multiplier and not the actual value as shown below.
void Update()
{
var t = CalcWeightingFactor(speed);
noise().m_AmplitudeGainMultiplier = t;
}
where noise represents vcam.GetCinemachineComponent<CinemachineBasicMultiChannelPerlin>().
I already understood the ask, and I get it. It makes sense. It’s just hard to know where to draw the line for things that are “expected” to change. People make all kinds of stuff, and I am often amazed at what people try to do. It’s quite wonderful, actually. The thing is, we have to weigh the advantage of the convenience of the extra setting against the disadvantage of adding more clutter and complexity to an already complex and cluttered system.
Yes, I agree. I would probably approach this on a per-request basis, rather than adding it everywhere from the get-go. If you have further insight into what values users most often modify, then these could be good candidates for multiplier properties as well.
