I’m confused on the dependencies and why you chose to make this a bp. I have a similar camera system that is extremely flexible and all in a small bp that I just drop into projects and go. I haven’t taken a look at how yours works yet but it sounds like it might be possible to thin it way down? I’m not trying to critique your work by any means though just curious is all because it seems like we both have a very similar thing but they are created very differently.
Ahh yes suppose that does make more sense. I haven’t worked with C++ in the engine yet myself so that may be where the confusion on my end came from. And yes I know I need to get on it and start working in that end I am terrible about learning the C++ end of this only because blueprints are so much fun and so easy to use for most of my work. I get having fun with those and then look at code and go aw do I have to lol They gave us to many fun toys.
Yes it will. The camera transition is where you get the “scrolling” effect moving from one screen to the next. Each screen should have a camera volume and when the player crosses from one screen to the next and it transitions from one camera to the next the transition is where you get the zelda style screen movement from. You should also move the character a few steps in the direction of the new screen. You might need to adjust the proximity of each camera bound as well as the transition between cameras and character movement until you get it exactly how you want but yes it will work.
**Important! **This update requires all camera volumes in your maps to be updated.
So, select all camera volumes in your map by “Ctrl + Shift + A” hotkey or with World Outliner, press “Update Volume” button in it’s properties, and save your map.
Added ability to rotate camera volumes. This means that orientation limitation is no longer exits, and now you can create not only plane-constrained side-scrollers, but not side scrollers at all.
Of course rotated volumes supports all provided features - static and movable cameras, camera blocking, camera transitions, etc…
Here is a video of new side-scroller example:
And a video of new “not side-scroller” example:
So, camera will be rotated even in runtime with dynamic volume.
Old and new math takes the same camera update time (~0.1ms) in packaged build, so there is no changes in performance.
Added OnCameraVolumeChanged event, that fires when camera volume changed. It returns camera volume actor reference and passed side info.
This event can be useful, for example, if you want to play some sound when passing through closed side of volume with cut transition:
Documentation will be updated in next few days.
I want to thank to everyone who have interest and supports this project!
Added camera collision settings. Well, camera collision is not really required in side-scroller camera games, but maybe you will find it useful for some other game types. Camera collision will work only when there is no camera volume and in camera volumes with movable camera settings. Collision settings is the same as used in SpringArmComponent.
Added new Top Down example. For now its supported by default and not requires any additional coding.
Added ability to disable main box primitive component collision. So, you can add other primitive collision components to customize volume activation area. You can find bDisableMainBoxCollision control in Volume category:
Added functionality to make camera rotate around volume’s central axis. It can be activated by bUseCameraRotationAxis checker in Camera category.
You can use this feature, with disable main box collision feature, in case you want camera to rotate around some cylindrical objects or rounded corners. Also, it supports camera blocking on top and bottom sides. Here is how it looks like:
One more update with fixes and improvements.
I’m sorry, but UE 4.21 was removed from Camera Volumes System on Marketplace, because Marketplace supports only 3 latest engine versions for code plugins.
Updated versions 4.22, 4.23, 4,24.