Finally got down to progressing on this project. This was a total rework of the camera system to enable way more features and keep the process overhead down.

The system is far more flexible now and has the following features all under one blueprint (and a data struct).
It also uses the 'cast to' system so no interface required.

- Blend time - ability to set the blend in and out time per camera. 0 means the view snaps instantly to the new camera.

- Fixed / Track player - simple switch for this. - Use Spline - move to a position along a spline that is nearest the player.

Another system I'm working on is procedural buildings that populate from a Blueprint.

So far only the doors, windows and radiators populate from a random seed. This video shows of the current progress of the camera system with the addition of a flashlight to show how it might work at night. I'd like to add a series of different light types (each maneuverable by the player) at a later date - but for now it's ok.

More progress today as I re-scripted the logic and variable system so it's much more streamlined and has a more robust way of handling the complex camera scenarios.

Another major contribution was the design of a 'Point of Interest' function which allows the camera to look in front of the player pawn when in third person (as pioneered in games like Mario 64). Furthermore the camera will only pursue the player pawn when it moves - static rotation is ignored. This avoids the more common view of being locked behind the player.

I threw in a simple light iteration just to show off the POI system and how it makes for more a cinematic effect.

I rewrote most of the original logic for this version of the system. I did away with using two cameras for the Player Follow camera and now I use one that changes it's properties (position, rotation, lag etc) when switching between first and third person.

The main development breakthrough on this stretch was completing the logic that handles contiguous camera boundaries. The system now allows multiple overlapping trigger volumes to trigger a single camera. This is great when you have multiple or irregular areas that need to be viewed by a single camera.

Working out what should happen whilst the player enters and leaves overlapping triggers was a nightmare though - I found so many bugs along there way.

I'm just beginning work on a third person camera system for a personal project I'm working on. Here I'm showing how, once a player enters a given volume, the view switches to fixed angle camera or a rail-based camera. Both options follow the player and the rail system tries to ensure it's as close to the player, whilst remaining on the rail at all times. This gives me the freedom to achieve some level of cinematography during gameplay (not just in cut scenes).

I spent a few hours today playing around Unreal's SSGI implementation. For now it remains a little limited as it doesn't seem to respond to skylights and also seems to inject far less light than expected.

System that allows naturalistic weather processions. The system starts by generating a weighted chance (based on the time of year) for a weather type (drizzle, rain, storm, snow) to happen within a defined slot (can be set by user), then it checks to see if conditions allow for that weather type to occur (for example a storm cannot happen if it hasn't been raining). Then the system deploys the weather type for the remainder of the slot and the whole cycle starts over. The slot system is disabled here to show different weather types.