In this post, I will be using the grass as an example in all images, videos and writing to keep it consistent. However, the shader is not limited to grass or any specific effect. It’s a flexible system that only requires a unique UV setup in DCCs to function correctly. 
The core benefit: it dramatically reduces the number of unique foliage actors needed in a scene, as well as their polygon count.

The shader was designed to solve three major workflow and performance issues the team encountered:

1. Variation: Artists' overhead of needing to create 2 to 6 unique variations of each foliage type to handle blending and edge terminations.

2. Lack of Context Awareness: Foliage colours, scales, and variations often lacked accuracy or cohesion within the scene or with the surface they sat on.

3. Manual Workflow: Placement requires time-consuming, manual adjustments and fine-tuning for each foliage instance.

The shader was built with the goal of working for artists, not against them. It automates much of the contextual behaviour that previously required manual work.

At its core, it uses pre-baked pivot points stored in a UV channel for each foliage card. This allows each card, even when part of a larger instance, to understand its relative world position. With this, we can leverage the information for highly complex and detailed transitions and interactions by simply dragging and placing foliage into the scene. Adapting to its surroundings and the surfaces it sat on dynamically for the art teams to use and so remove, extremely time-consuming blending with the use of a single actor.

This example shows the only foliage grass type used in the examples below.

Followed by the example of a random value per card, baked in U and the height of each card baked in V. 
Data baked in Hodiuini, presented in Blender. 

In the end, it made the scene dramatically more performant, reducing foliage tri counts by up to 60%, allowing us to use very large and specifically designed foliage assets that scale with LODs. The LODs are very aggressive in the scene and have specific card layouts to maximise coverage and produce the perception of very thick-looking foliage density, even at a distance.  

Full WPO shader graph. 

The information generated in this section of the graph is passed to all other channels. They then use that to manipulate their values to create truly interesting variations when they sway in the wind or based on the surface they are sitting on. 

Finally, the shader also had to take real-time or pre-baked wind, and the currently unreleased character interactions.


Thank you!


Below are examples of the WPO features being tuned.

The final video shows shader data generation if no prebaked information is present or necessary. 

I had the opportunity to produce a FLIP fluid, Lava simulation in Houdini for Splitgate 2: Inferno. This was processed into an Alembic Geometry Cache at specific framerates, custom motion vectors and applied a vertex colour driven shader in the Editor. The whole file was 48 frames long, with a footprint of 9.3MBs and a BP LOD system. Meeting our performance requirements while finely tuned for smooth playback rates and quality. 

The creation process was broken down into 4 stages. 

1. Collision set up. Taking level geometry and Cached landscape data to produce fluid collision sources. 
2. Source set up. Creating emitters, setting velocities, attributes and making random connections to timelines for variation during emission. 
3. The Lava Simulation stage. Using the above information to produce a Cached particle simulation. 
4. Simulation Processing. The final stage is used to set Vertex colours, create a seamless Loop from the simulation, process the particles into an optimised piece of geometry and create LODs.
   
   

Collision creation and export.

FLIP Simulation emitter setup and attribute set.

Particle Simulation FLIP network & Result.

Final conversion, optimisation, colouring and export graph.

Examples of the simulations running from Houdini and UE5 and a Geometry Cache.