Post Processing Stack V2 - the Playmaker Actions

About Post Processing Stack V2 - the Playmaker Actions – Unity Editor Tool & Plugin

Post Processing Stack V2 - the Playmaker Actions Unity Asset Overview

Modifying camera effects dynamically during gameplay has historically been one of those minor tasks that ends up taking way too much time. Honestly, if you have ever had to write a custom C# script just to gently lerp the intensity of a vignette when a player takes damage, or adjust depth-of-field focus during a sniper scope zoom, you know how annoying the boilerplate code can be. You have to grab the PostProcessVolume, extract the shared or local PostProcessProfile, check if the specific effect override exists, and then safely write to the parameter value.

The Post Processing Stack V2 - the Playmaker Actions asset solves this structural friction by acting as a direct bridge between Hutong Games’ PlayMaker visual scripting engine and Unity's legacy Built-in Render Pipeline post-processing package (Post Processing Stack V2). Instead of managing complex component references and casting types in C#, this toolkit exposes virtually every parameter within your post-processing profile as a native, configurable PlayMaker action.

Under the hood, the architecture relies on caching references to your scene’s active volumes and profiles. Rather than doing expensive reflection or string-based lookups on every single frame, these actions cache the active post-processing effects and override properties during the state initialization phase. This keeps the runtime footprint incredibly lightweight and prevents CPU spikes, which is critical when you are running performance-heavy visual states on hardware like mobile devices or older consoles.

Core Technical Features & Highlights

Granular Parameter Control

This package does not just let you toggle profiles on and off; it gives you precise control over individual properties inside each effect. You can target specific properties such as color grading wheels, focus distance, bloom intensity, or ambient occlusion direct settings directly within your state machine flow.

Runtime Interpolation & Lerping

Many of the included actions feature built-in interpolation. You can specify a target value, transition duration, and easing curves directly inside the PlayMaker action UI. This eliminates the need to set up complex multi-state loops in your FSM just to perform a simple transition.

Supported Effects & Overrides

• Bloom: Dynamically alter intensity, threshold, diffusion, fast mode toggles, and color tints.
• Depth of Field: Animate focus distance, aperture, focal length, and kernel size for real-time camera focus pulling.
• Vignette: Change intensity, smoothness, roundness, and color parameters during gameplay events.
• Color Grading: Adjust exposure, contrast, saturation, white balance temperature, tint, and color filter values.
• Chromatic Aberration: Instantly spike aberration intensity during screen shake or explosion events.
• Motion Blur: Modify shutter angle and sample count on the fly based on player speed.

Optimized Garbage Collection

In my experience, bad integration scripts often allocate memory in the heap by querying components using strings. These actions are written to minimize GC Alloc by keeping reference caches of the target properties. This ensures that even when your state machine updates values on every single frame, your garbage collector remains quiet.

Ideal Use Cases & Game Genres

Indie RPGs & Adventure Games

You can use these actions to alter the mood of an entire level as the player transitions between zones. For example, moving from a bright, sunlit forest to a dark cavern can be achieved by writing a state machine that transitions the exposure and temperature values of your Color Grading settings over a three-second window.

First-Person Shooters (FPS)

Animate the Depth of Field focus distance property to shift dynamically whenever the player aims down sights (ADS). You can also tie the intensity of a Vignette or Chromatic Aberration directly to a player's health variable in PlayMaker, creating a visceral sense of damage as health drops.

Horror Games

Horror titles thrive on optical manipulation. With these actions, you can easily implement sanity mechanics where a character's declining mental state causes the screen to desaturate, the grain to increase, or Ambient Occlusion to darken, all driven directly by your existing PlayMaker gameplay logic.

Quick-Start Unity Setup & Integration Guide

Getting this asset configured is straightforward, but it does require that you have your camera and post-processing layers set up correctly in the Unity Editor first. Here is the key takeaway: the actions rely on standard Built-in Post-Processing Stack V2 components, so your scene must have a working post-processing setup before you start calling PlayMaker actions.

Step 1: Verify Scene Prerequisites

1. Ensure you are using the Built-in Render Pipeline.
2. Confirm that the Post Processing package is installed via the Unity Package Manager.
3. Verify that your main camera has a PostProcessLayer component attached and its Volume Layer is set to your post-processing layer (e.g., "PostProcessing").
4. Ensure you have a PostProcessVolume in your scene set to "Is Global" with a valid profile assigned.

Step 2: Adding the PlayMaker Action

Once you import the package, the new actions will appear under a dedicated post-processing category inside your PlayMaker Action Browser. Let's write a simple FSM state that adjusts Bloom intensity when a trigger is entered.

// Conceptual logic of how the custom Playmaker Action manages the Bloom override under the hood
using UnityEngine;
using UnityEngine.Rendering.PostProcessing;
using HutongGames.PlayMaker;

[ActionCategory("Post Processing Stack V2")]
[Tooltip("Sets the intensity of the Bloom effect in a target Post Process Volume.")]
public class SetBloomIntensity : FsmStateAction
{
    [RequiredField]
    [Tooltip("The GameObject with the PostProcessVolume component.")]
    public FsmOwnerDefault volumeObject;

    [RequiredField]
    [Tooltip("The target Bloom intensity value.")]
    public FsmFloat bloomIntensity;

    public bool everyFrame;

    private PostProcessVolume _cachedVolume;
    private Bloom _bloomEffect;

    public override void OnEnter()
    {
        GameObject go = Fsm.GetOwnerDefaultTarget(volumeObject);
        if (go != null)
        {
            _cachedVolume = go.GetComponent<PostProcessVolume>();
            if (_cachedVolume != null && _cachedVolume.profile != null)
            {
                _cachedVolume.profile.TryGetSettings(out _bloomEffect);
            }
        }

        DoSetBloom();

        if (!everyFrame)
        {
            Finish();
        }
    }

    public override void OnUpdate()
    {
        DoSetBloom();
    }

    private void DoSetBloom()
    {
        if (_bloomEffect != null)
        {
            _bloomEffect.intensity.Override(bloomIntensity.Value);
        }
    }
}

Step 3: Configuring the FSM

1. Create a new FSM on an empty GameObject called "PostProcessManager".
2. Add a state called "Idle" and another called "Flashscreen".
3. In the "Flashscreen" state, add the Set Bloom Intensity action.
4. Set the target variable to a high value (like 25.0f), and transition back to "Idle" using a standard Wait action combined with an interpolating lerp value to return the intensity to normal.

Pros & Cons Assessment

Pros

• Zero Code Required: Artists and designers can control complex camera settings without writing C# scripts.
• Full Parameter Exposure: Accesses complex properties like color wheels and focus lengths that are typically difficult to edit via visual scripting.
• Highly Performant: Caches volume and profile settings to keep runtime memory allocation and garbage collection to a minimum.
• Time Saver: Standardizes operations that would otherwise require writing custom scripts for every new project.

Cons

• Legacy Pipeline Only: Strictly designed for Built-in Post-Processing Stack V2. If you migrate your project to URP or HDRP, these actions will not work with their volume systems.
• Dependency Bound: Requires both PlayMaker and the external Unity Post-Processing Stack V2 package to be configured beforehand.

Related Unity Tools Assets