UNIT 49 CAMERA/CONTROLLER IMPLEMENTATION

 

 

After creating a simple level and importing my character I implemented the first steps of my plan.

The first three camera’s are based around trigger boxes. After dragging a new camera in and adding a trigger box for it I moved onto the level blueprint. Here I referenced both the camera and the box trigger.

This camera system is simple. The camera is fixed to watch a set area. When the player triggers it the player camera switches to this camera. Giving a shot of your player running across the new camera’s view. Resident evil used this system a great deal as it can convey a great sense of emotion. Revealing hidden threats that the player could not see before. It can also be used to create fear in it’s transition. With the player anticipating a threat based upon their previous experience of the long camera shot.

With my onactorbeginoverlap i required a node that would enable me to change camera from the default. One of my lecturers was happy to show me a node that allowed that, set view target with blend, the blend being a variable transition from one camera to the next. In order to call this to the blueprint I needed to to summon a new, essential node, get player controller. This allowed me to set the camera transition via the player itself. After this I connected the overlap to the set view via the execution string. The player controller was the target, and the new camera was the new view target.

Unfortunately they only showed us the first part of the process.

first half of trigger box cam

As a result I just copied the code, hoping it would just reverse the process, reversing the camera back to my third person camera. Upon playing my character triggered the camera, showing a long shot of me as I ran by. The problem was when I exited. The camera stayed active and didn’t switch back to my player camera. The solution was not as simple as the first process. Assigning a new target camera worked one way but not the other. I needed to find a way to remedy this. How to move the remote camera back to my third person camera. Firstly I would need to assign my character, then target it’s default camera.

My first effort at resolving this was to cast to Sawyer(my third person character), for this I called a cast to actor class, it’ class was a get player controller with a get class linking. Next was a cast to sawyer, with get player character. Followed by a set, finally I used the set view target with blend, with get player controller.

Trigger camera fail1.PNG

It worked, with one small problem, the camera was centred in the middle of his body. This was due to the follow camera’s boom position.

2018-06-22 (3)

One of my colleagues pointed that the set node was pointless as cast to sawyer had already done this, also the get actor class was unnecessary for the same reason. I got rid of these but still needed a way to connect cast to sawyer to set view target. I needed to assign player camera. Dragging a pin from the as sawyer, on cast to sawyer. Scrolled down to the bottom and selected the first person camera. I still needed a node to connect to the set view target with blend, the same colleague helped me again pointing out that the owner is needed, I typed this in to get a ‘get owner’ node, which i connected , then tested. The camera switched back upon exiting the trigger.

Trigger camera success2.png

The tutor then showed us an optimal way of finishing the code he had started.It required a couple of new nodes between the end overlap and the set view target with blend. The first was a node that would assign a new target camera, get all actors of class. I needed to assign the camera to the character via a dropdown box in the node itself. I searched for my character, Sawyer, and set him here. I still couldn’t connect this to the set view node as I needed an intermediary node. The node in question was, for each loop. As far as I can tell this node fires out an execution pulse on loop until the order is given for it to stop, or the action is complete. If not used properly loops can fire off forever severely compromising the performance of the computer. Having called this node into my blueprint I connected it to the get actors of class via both the exec and out actors nodes. I the duplicated the set view node and the get [player controller node, from my overlap begin string, connecting the exec from for each loop to the set view and the array element from for each loop to the new view target, the get player controller was already connected to the target node as before.

camera shit

As a word of warning, with the get all actors of class, the tutor said that if you change anything in the string the get all actors of class node would need to be replaced. I tested it, he was right.

In comparison, the two strings worked well and had the same results. The tutors was the more efficient but it showed that there are more than one way to reach the same conclusion. I suspect that the more efficient codes will have a smaller effect on the engine during game play. This is paramount for my needs.

Upon testing my new cameras I found that the environment they set was satisfactory, giving a feeling of being lost within something monolithic. It had an added bonus. As I navigated, via the keyboard and mouse, the cameras distorted the smooth control of the character. In a stressful situation this could be something that could heap on the pressure. Below are some screenshots that will give some idea of the feeling mentioned.

 

 

 

 

This slideshow requires JavaScript.

The jaunty angle of the second camera added to the confusion when passing from the corridor to the control room. The whole sequence reminded me of resident evil, and the franticness that is involved. This was an accident but I am happy to leave it as it is as it works for me as it did for them.

The next step was to create a seamless transition from camera change to camera change. This was done by trial and error. Moving the trigger boxes closer solved this, though if they are too close the new camera does not activate, leaving me in third person view. Too far apart there is a flick from one camera to the next with a moment of third person view.

 

My next task is to implement a third to first person toggle.

Firstly make sure that you are in the correct blueprint, your playable character. I forgot this and built a string in the third person, then scratched my head for ten minutes wondering why the blueprint wouldn’t work. I then realised and built the string in my imported character and, hey presto, instant toggled view.

So, in your character blueprint, add a new camera component and call it ‘Firstpersoncamera’. Assign the socket to the head and check the ‘Usepawncontroller’ box. Change to the viewport tab and re-position the camera to its correct orientation and position ( so the face is framed by the front of the camera.

Viewport camera position.PNG

Head back to the event graph to start on the string.

Firstly we need to choose a key for our toggle, I chose V for View. As this is a toggle the next node will be a flip flop, allowing us to change between the two options. The next two nodes are going to be the two camera’s we need to toggle between. We need to activate them, or set them active, the node would be set active. The first will be with the reference to the,default, follow cam, the second is the with a reference to the newly created ‘firstpersoncamera’.

camera selection

These will act as the upper string, executed from the ‘A’ node on flip flop, or our third person view. Duplicate these and paste them below. Executing from the ‘B’ node on flip flop, this will be our first person view.

On the set active nodes there are some check boxes, new active ( the current active) and reset ( cancels activity). On the upper string, in the first set active check the new active box, signifying the camera connected is the view cam, in this case it is  follow camera. In the second set active, the first person camera, check the reset. This disables the first person camera.

When done move to the flip flop ‘B’ string. Check reset in the follow camera set active node and new active in the first person set active. This enables us to to activate one, then the next, with the press of the ‘V’ key. Allowing us to switch easily between the two views as often as possible.

The final nodes are simply set nodes, these are to be used later to implement a crosshair, set into my first person view. These are attached to the player controllers yaw. So pull out a string from one of the second set active nodes and type ‘Yaw’.

tp-fp toggle yaw.jpg

Select the ‘Set Use Controller Rotation Yaw’. This will give you a set node which you need to duplicate and attach to the other set active. Check the top strings ‘Use controller rotation yaw’ box. The string should now look like this.

third to first person string.PNG

Test it and toggle your view until your head falls off ( may not actually happen).

I have just been playing with a ‘right mouse button’ and set field of view node. I heard about the nod in a tutorial and decided to test it. A little bit of research proved that 90 is the default unreal view setting of first person, i decided to halve it. The right mouse was chosen for ease of testing, though any key can be used in it’s place. I added my first person camera to the field of view. When pressed I set the angle to 45, when released to 90. This gives me a nice first person zoom.fp zoom.PNG

I tested this string on the third person and found it lacking. Obviously it zoomed in but it only gave me a closer look at my characters back. I altered the pressed setting to 120 and discovered a nice zoom out. This could be used to help the player see more in a scene. With both of theses zooms , set up in the two perspectives, I now had a more in depth field of view. An interesting side effect to the third person was when I changed the pressed value to 200. The screen zoomed out properly but it also inverted the scene, I can’t think of any use for this at the present. I lowered the value to 190 and found the same result. At 180 something odd happened. The screen changed to a single white circle at the centre with a horizon flowing out from it’s centre, white above and blue below. I suspect this is the transition between the out zoom and the inversion. I proceeded down in increments of ten and found the zoom worked properly, zooming out to the set distance, the only problem was the distortion of the scene, like looking through a fish eye lens. I decided to stick with my first setting of 120 as this seemed the best, natural, view.

 

Next was to add a matinee as my character enters the large chamber. I have some experience with matinee but still needed to re-fresh my skills with a little research.

To begin I started by clicking on the dropdown, next to the cinematics tab at the top of the viewport, here I selected ‘Add Matinee (Legacy). This will give me a simple matinee, for a more in depth cinematic I would need to choose add master sequence. This would allow me to film and splice a full cinematic sequence, with changing camera angles and locations. For the time being I am only interested in the much simpler Matinee Legacy.

Once selected a second screen will open, this is the Matinee window. Here you can control the keyframe creation. Doing this is easy.

Matinee_.5

Once the matinee window is open move to the border in the bottom left, right click and select ‘Add new camera group’, then rename the camera to something suitable. Once done there will appear two text boxes at the top of the border, one called movement, the other FOVangle. It is important to know that for every key to take effect in the sequence the movement must be highlighted.

 

 

 

The number bar at the bottom of the screen is the timebar, allowing you to accurately add keyframes. The green section is the tracks editor, this is where the keyframes will appear.

Matinee_3

On the timebar, at the edges of the tracks length, are two red and two green arrows, one of each at each end. These signify the entire running length of the matinee. Moving the rightmost two will lengthen, or shorten, the overall length of the sequence.

The White bar with a thick black handle, in the timebar, is the scrubber (as far as I can tell). This allows you to move to the next desired keyframe position accurately.

As far as making a matinee, when you created a camera group earlier, not only did it spawn the movement and FOV Angle, but also a camera, in the viewport, this spawns wherever your viewport is positioned. Now you have a camera all you need to do is make a sequence.

The first is at the, default, starting position. For every subsequent one you first need to move the scrubber to the desired time lapse position, then move the camera, using unreals deafult move and rotate tools, in the same manner you would move any other mesh. A handy window appears at the same time as the camera in the lower right of the viewport, making it easier to line up your camera’s flight path.

Matinee_7

Trial and error will teach you how to space the key incriments, especially when the camera is turning, to keep it smooth requires more key frames. Just keep in mind how long the incriments you use are, for a camera to travel twenty metres in game, in a half second, will cause the camera to zoom. This can more easily be seen by looking at the track itself as you create your sequence.

Matinee_6

The yellow line is the camera’s track. The yellow squares are a keyframe. The yellow dots are the incriments of it’s movement between each keyframe. In this instance all the keyframes are half a second. As you can see, in places the dots are closer together, giving me a smooth transition from one frame to the next. The further apart the dots are the faster the camera must travel to fit in the half second frame. This could be used really well in the filming of a rollercoaster, or in atltering terrain to give a rollercoaster effect.

Once the matinee has been shot, save and exit. Now is the time to implement it’s use into the game.

A matinee is mostly used at the beginning of a level , or game. This would naturally be attached to the ‘Event begin play’ node. In my case this is in the middle of a level so a trigger box is required, I chose ‘On actor end overlap’ to begin my sequence.

Take a reference to the matinee, in the viewport, and add to to your level blueprint. From here pull out a ‘Play’ and attach it to your overlap end. Next we require the camera used, so take a reference of that and add it to your blueprint. To attach this to the play node we need a ‘set view target with blend’, summoning this requires the ‘get player controller’ node. When summoned connect the set view with blend to the play and the camera to the new view target node. Next you will need a delay, set to the same time as your sequence.

From here we need to assign the original camera back to the player character. This is done with the ‘All actors of class’ node, making sure to assign the correct character to it’s dropdown. Next we need the ‘For each loop’ node to assign the program to look for it. Finally we need another ‘ Set view target with blend’, again accessed through a get player controller node, with the array element, from the ‘for each loop’ , connected to the new view target, on the ‘set view with blend’. Everything should run fine.

One problem I came across when testing the results is that as the sequence played I could still move my character in the scene. The solution was simple. I inserted a ‘Disable Input’ node, after ‘play’, and an ‘enable input’ node at the end of the string. Both had a ‘get player character, and controller attached to the target and player controller nodes. This sorted the problem, leaving my character motionless as the sequence played and fully controllable after it ended.

Another problem I encountered was upon exiting the room, running across the matinee trigger box, the player would freeze, causing me to exit the game. Again the solution was simple. At the end of the string I added a ‘Destroy Actor’ node, attaching a reference to the trigger box. This sorted the problem out. Allowing me to freely exit the room and continue through my level.

 

My next camera was to be a security camera. For this not only would I need the camera but also a surface to show it’s results upon. I found a tutorial by Tesla Dev, shownig how to add a scene capture component ( a more detailed camera than the standard).

These camera’s are used mainly for security camera’s in game. Acting like a tv screen receiving information from a camera, or a live feed. Now I need to find a way to have multiple scene capture components displayed through one screen, with a toggle or a selected key for each camera.

Firstly I needed a trigger, so I placed a box in the scene. To see if I was in the trigger I needed a variable, boolean, called ‘In trigger box?’ I set it to each of the trigger overlaps, checking the one attached to begin. A colleague told me of a sequencer he had used for camera switching called ‘Switch on Int’. I attached this to the begin set.

For the program to recognise these options I required another string to see when it was to activate, it needed to be ever watching. Event tick seemed the obvious choice. I dragged in the variable reference ‘In trigger box?’ as a get but needed a condition with true or false. I had previously seen branch, this node allows you to set these conditions. I added it, with the variable as the condition, and connected it to the switch on int.

For my string to work I need a way of transferring the selected camera to the next across the games blueprints. Again my colleague pointed to something called a game instance.

There is a default one created on commencement of play, this can be found in project, maps ans modes.

To create a new one, go to the content browser, create a blueprint, and type game instance in the search bar. Inside it has all the same functions as any other graph. It is created when the game starts and destroyed when the game ends. The game instance is global. Matthew Wadstein has a tutorial with a clear description of how it works.

 

I began by dragging a cube into the viewport from the modes panel, resizing it until I had a desirable screen. I created a new folder in my contents of the content browser and called it materials. In here I right clicked, in the folder window, hovered over ‘materials and textures’ and selected the ‘render target’.

A render target is a texture added to a mesh that you can add new textures to, here is a link for it’s official description:

https://docs.unrealengine.com/en-us/Engine/Rendering/RenderTargets

 

Security camera_7

I named this ‘Security camera feed_text’, this is my screen the camera will display onto. Now I had to create a material for it to attach to. Again I right clicked in the material folder window and selected material. I then opened this and dragged in the security camera feed as a texture sample, connecting it’s uppermost, white, pin to the base colour of the security camera screen node.

Security camera_8

This only displays the attached camera, I took it in turns to display each of the two camera feeds but could find now way to add them both to the base colour node.

One more time I right clicked in the material’s window, this time selecting blueprint class, actor. Inside the blueprint I added two components, a cube and a cone, resizing them into a small camera shape. Finally I added another component, ‘Scenecapturecomponent2D’, this was the lens for my camera and needed to go at the front most of my mock camera.

Security camera_1

The final step in setting up the camera was to add the camera view to the screen. This was done by clicking on the security camera feed_text, then clicking on the small white arrow next to the box labelled ‘texture target’, under the ‘scene camera’ menu in the ‘security camera _bp’ details panel. This allowed the camera view to be displayed on the screen.

Security camera_2

Finally I positioned my camera in a suitable place and checked the results in game. It worked.Security camera_4Security camera_5

When done I exited back to the viewport and dragged the new security screen mat onto my prepared screen. It was black. This is because I do not yet have a camera.

My next aim is to have multiple cameras displayed, through a toggle, on the one screen.

I chose to use the same camera, moving it’s location around the map. This would require a set world location and rotation node, the object would be my cube ( the root of my previously built camera. Now I need  trigger, placing it in the ‘securitycamera_bp’, labelling it box.  For the multiple cameras I needed a node that would allow this, after some consultation the best was a node called ‘*Switch on Int’, this also contained the ability to add as many outputs as I needed. To change camera’s I required a variable. Here I added my new game instance. In here you can add as many variables as required, all accessed through any other blueprints. It would be more convincing if I added meshes of camera’s in the camera locations.

Camera toggle( gi)

 

After creating one, labelled ‘cam_GI’ I added the varible ‘selected cam’.

camera toggle GI (selected cam variable)

I created a node called a node ‘cast to cam_gi’. To the object I dragged a pin ‘get game instance’. From the ‘as cam gi’ I got a ‘selected cam’ node and connected that to the selection pin on the switch on int.

My next problem was how could I ensure the trigger wasn’t always active? I needed a condition.  A variable, ‘In Trig?’. I would also need an event tick, to watch for it. from here I added a branch with ‘in trig?’ as the condition. I connected it to the ‘cast to cam_gi’ input node. Between the the begin on overlap and cast to cam_gi I set the same condition.

Camera toggle ( security camera bp)

 

For this to be active I needed it to begin on play, to which a set world location and rotaion, with the box as the target, ensured this.

trigger box (security camera bp)

Now the conditions were set for the trigger box I needed to assign it’s activation to a target, my player. In the ‘Sawyer’ blueprint I assigned a key, number 1, node, cast it to the game instance, and set the selected cam, which i also numbered one. This would correspond to the numbers on the switch on int node in the security camera bp.

Camera toggle ( Sawyer bp)

Upon testing it worked intermittently, sometimes selecting the camera’s and sometimes not, sometimes it even teleported my character to  a new location. I need to look further into this.

 

The next camera was one that added a screen shake. Having never done this before it required some research. It turns out that the shake is a simple addition to have, and effective.

I decided to add it to some movable blocks. I created a new blueprint class in the puzzle block folder, within the content browser. The only thing I needed to do in here was to manipulate the oscillation, amplitude, and frequency of the tremors. As I had no concept of how these settings worked in the world it was all trial and error in the world.

First I needed to attach this effect to my blocks. The blocks moved through a trigger box and seemed set for a perfect place to begin. Dragging a pin from the final node of the block (set simulate physics) I typed ‘shake’. This gave me an option for cast to camera shake. I dragged out, from the object pin a get player controller node, all this did was vibrate the player. I changed this to a get player character node, for it only to repeat the vibrating character, both had also compiled with warnings. My next step was to choose a node called ‘ play world camera shake’. Next I chose my ‘Puzzle block shake’ from a dropdown menu. It had no effect in the game. I obviously needed to effect the block when the player entered, and as the block moved around the scene I needed something specific. Pulling a string from the epicenter pin I called the ‘Get Actor Location’ node, connecting it’s target to the ‘as sawyer’ on the ‘cast to Sawyer’ node from the moveable blocks string. This solved the problem but the shake required some fine tuning, plus it wouldn’t stop after I exited the trigger box. Dragging a string from the pin of the last node, i again typed ‘shake’. In the available nodes wasone called ‘stop camera shake and one called ‘Stop all camera shakes’. As there were no other shakes going on in the game I chose the latter, just to be safe. I tried to compile but an error stopped me. I needed something else. The player was the variable in the situation so I needed top attach it to him. From the nodes ‘target’ pin I called the ‘get player controller’ node, which summoned another node labelled ‘ target  player camera manager’, obviously I required this for the controller to be recognised.  I compiled and saved and tested it. Success, not only did the camera shake when I entered the trigger but it stopped when I exited too. I then applied this to the other block blueprint. Both worked well.

Screen shake1

Now I moved back to the shake settings. The pitch and yaw amplitude was set to three, the frequency to twenty. Next, after a lot of either, too little, or too much screen shake, I set the x and z axis tremors to an amplitude of twenty, their frequency to ten. There was no need for the y axis to be used as the blocks were only able to move across the floor. This worked well. No blueprinting was required.

Screen shake 2

Below are screenshots of the different cameras, the final one( in front of block) does not show the actual shake so I have added a video link also below.

 

This slideshow requires JavaScript.

 

 

Having all of these trigger boxes isn’t causing much of a drain on gameplay but at some point this will become a problem. I need to find a way to deactivate all of the triggers, only making those live that I require.

If I could have the hallway ones only active at one each side of the current one it could save me trouble, later on when I have many triggers. Even if the adjacent rooms are active too the drain will be negligible.

In a search for a suitable node, or string I found a node called ‘ Set collision enabled’. This does what it says, enabling, or disabling, whichever collision you want. I hope it effects the trigger box collision to an off position. Leaving the trigger box inactive, not looking, until activated.

trigger box management

It has a dropdown in it with four options, two of which I am interested in, ‘No collision’, and ‘Collision enabled (query and physics). I added two on each end of each of the hallway strings. Activating the next one, and one before, in the hallways, and any adjacent rooms attached to them too.

I tested it by disconnecting random strings to see if their boxes would trigger, they didn’t.

On a ‘begin play’ event I also attached one with every trigger in the level, except for the first, I needed a starting point.

Trigger management 2.PNG

All I need now is confirmation that it indeed works the way I have imagined.

 

Keymapping: The ability to assign, not only, your own keys, but also, the mapping of any external peripheral is a simple procedure.

On the main screen, access the edit menu, select project settings , and input. Here are all of the potential interactions. All with their own drop-downs, containing every key and options for shift, ctrl, and cmd pairing. Altogether an extensive choice. This gives the developer a masterful control for creating a keymap for ease of play.

Under the dropdown axis manipulation, move forward, the first two were w and s. I know these are the default forward and backward. So I changed these to e and d respectively. The next dropdown, move rate, contained the next to default movement keys, a and d. I altered these, applying s and f. I left the spacebar as the jump key. As far as the mouse I left the turn, mouse x axis, and look up, mouse y axis, these were found also under the axis mapping menu. These worked well, though not as easy to access the alt key as when using the traditional wasd setting.

As I did this I also noticed, under the same menu’s, the option to change, not only, gamepads, but also, motion controllers, oculus touch and remote, and steam vr knuckles . I do not own a wired controller so I couldn’t test my results, where i changed the movement inputs from thumbstick axis to the dpad. I also changed jump the left shoulder.

At the top of each menu there is an option to add your own mapping, doing so creates another input box. Leaving the option to map the entire keyboard, four times.

I found a good tutorial on how to efficiently use keybindings, it also shows where to access them in blueprinting.