UCameraShake is atrocious for C++ users

General Feedback & Requests
1

Hello! I would like to provide some feedback.

I tend to avoid blueprints for low-level stuff when possible because they’re bound to break very easily when something changes in a parent C++ class – name, path, parameters, etc. My philosophy for blueprints is simple: the mapmaker right-clicks the C++ class, creates a blueprint based on it, sets any cosmetic values, and uses it as they see fit, modifying the exposed properties if need be etc. So basically, I’m trying to make the project as portable and non-programmer friendly as possible. Unfortunately, the way UCameraShake works right now prevents me from doing that as much as I’d like to.

For some reason, in order to apply shakes on the camera, I am forced to create a blueprint of the UCameraShake class. Why? For instance, in Valve’s Source it’s as easy as calling a static method named UTIL_ScreenShake(). I don’t really see the reason why I’m forced to use blueprints here. Animations, FSM and materials, I can understand, but this? And what if I want my shake to be dynamic? Do I create 500+ camera shake blueprints?

My first attempt was to try and use one blueprint for everything. But it didn’t work. Simply obtaining the blueprint object and modifying it in-code doesn’t work because of the way the responsible engine function is designed. The values are restored to whatever was set inside the blueprint.

Unfortunately, this is hardly doable without modifying the engine source code, and that is something I am not willing to do because that will be the death of any portability and ease of future upgrades that I have in mind. Please, consider making UCameraShake C++ friendly. If not, i will just have to create a custom shaking algorithm, which is of course not a problem, but in a nutshell, I would be reinventing the wheel for no real reason.

Thanks!

2

The reason you should create a new CameraShake class in blueprints is so that you can quickly tune and iterate on changing the shake.

Think about from a data-driven design perspective. The shake defines how to shake the camera in a particular way. This needs to be easily tuned at design time.

Why do you want to have to create this class in c++?

You can still use it from c++ - just expose a UProperty and set it in BP.

btw - you should not need to modify engine source to do any of this…

This may help:

Mathew does a great job explaining.

3

Yeah me too, I found limitations in this system, plus the BP have a design error leak that you can’t edit the const vars at spawn it, so yeah I vote for some better solution +1

Plus the camera shakes are limited and if the camera is a near 90º then do rare things cause the grimbal lock…

4

Yes, it helps during design/debug, but afterwards I would like to be able to migrate to my native environment, which is C++. This is possible with most features, just not this one for some reason.

As I already said, I’m a C++ user. I have experience with engines that “do it” mostly within code, I’m used to that kind of approach and I prefer it.

As I said, this is not an option for dynamic shakes, unless I’m going to have tens of shake blueprints, which is messy and inefficient.

Instead of creating tons of blueprints, I could simply do something like this:



UCameraShake* CameraShake = UCameraShake::StaticClass()->GetDefaultObject<UCameraShake>();

CameraShake->OscillationDuration = 0.25f;
CameraShake->AnimBlendInTime = 0.1f;
CameraShake->AnimBlendOutTime = 0.2f;

CameraShake->RotOscillation.Pitch.Amplitude = CurrentlyDesiredAmplitude;
CameraShake->RotOscillation.Pitch.Frequency = CurrentlyDesiredFrequency;
CameraShake->RotOscillation.Pitch.InitialOffset = EInitialOscillatorOffset::EOO_OffsetZero;

GetOwner()->GetPlayerController()->ClientPlayCameraShake(CameraShake);

If you have experience with C++, or any other programming language for that matter, you will see how this approach is infinitely less cluttersome than the one currently available.

Sorry but I’m not sure how any of those links are supposed to help me. Do you mind pinpoiting the exact time on either one of those videos?

5

Interesting; I have never messed with camera shake through C++ so I have no opinions on this.

6

Uh… Why reply then? Get your message count up? <grins>

teak

7

To see if someone know something about this.
Would be cool to see some code snippets.

8

Sorry for necro-ing this thread. Was having the same issues and stumbled upon this thread.

I managed to find a solution for this and thought I’d share it for future googlers.



UCLASS(BlueprintType)
class GAME_API UMeleeWeaponHitCameraShake : public UCameraShake
{
    GENERATED_BODY()
};

UCLASS(BlueprintType)
class GAME_API ABaseCharacter : public ACharacter
{
    GENERATED_BODY()
public:
    UPROPERTY(EditDefaultsOnly)
    TSubclassOf<UCameraShake> OnReceiveAttackHitCameraShakeClass = UMeleeWeaponHitCameraShake::StaticClass();
}

With the code snippet above, you can set still the value in editor but in the event that you want to control everything via c++ code, you can simply not touch it in the editor and it will choose the default value you specified.