SmallBurger

Why Are Traditional Terrains Performance Killers on Mobile? Z-Terrain (Zero Deform Ultimate Mobile Landscape) Development Insights and Solutions

2026-08-12T10:59:32.521+08:00

For a long time, implementing expansive, open-world landscapes on mobile devices has been an extremely tricky task. Because running Unity's native Terrain system directly on mobile phones incurs completely unacceptable performance overhead, the industry's conventional compromise is to use plugins like Mesh Terrain Editor Free or Terrain To Mesh to convert the terrain into Meshes for rendering.

However, this long-standing conventional pipeline hides three "fatal pain points" that cause the most headaches for R&D teams:

Pain Point 1: Unnecessary Waste of Geometry in Flat Areas (Vertex Pressure)

When traditional plugins convert native terrain to a Mesh, they typically can only use a naive, uniform subdivision algorithm. This leads to a very absurd phenomenon: a perfectly flat beach or grassy plain is assigned the exact same density of triangles and vertices as a steep cliff.

These densely packed vertices, which offer zero visual contribution, needlessly waste the computational resources of the Vertex Shader on mobile GPUs, resulting in a severe geometric performance burden.

Pain Point 2: Water Bodies and River "Relocation Hell" (Extremely High Late-Stage Maintenance Costs)

The traditional Terrain-to-Mesh pipeline is a "destructive, irreversible" one-way process. In large-scale scene development, terrain rarely exists in isolation; it is often deeply integrated with water systems like lakes, rivers, and waterfalls.

When a Level Designer (LD) or Director casually says late in development: "We need to expand the village here, move this river 50 meters to the left, and make the lake a bit larger," the nightmare for artists officially begins: They have to 'level the previous holes and dig new ones,' and then re-export the Mesh.

Excavation and lining are required to construct a lake.

Pain Point 3: Transition Blending Between Cliffs (Scene Objects) and Terrain

Because traditional Terrain inherently suffers from vertical UV stretching issues, the system does not automatically add vertices (Vertices) on steep cliffs with extreme height differences to distribute the resolution, leading to severely distorted textures.

To solve this visual disaster, artists typically have to "place a large number of rocks, mountains, and other scene objects" in these areas to forcefully cover up the ugly parts. But this introduces a new problem: extremely stiff seams (complete disconnects in lighting and textures) appear at the intersection of the objects and the terrain. To hide this rigid seam, artists are forced to densely pack the surrounding area with grass and small pebbles. For project teams with extreme demands on visual quality and scene cleanliness, this approach is not only extremely tedious but also needlessly stacks a massive amount of Draw Calls and polygon counts.

There is a noticeable hard edge where the terrain meets the mountain.

Pain Point 4: Quantity Limits on Multi-Layer Texture Blending (Splat Mapping)

To express surface richness, traditional terrain needs to blend multiple Textures like grass, rocks, and sand. If conventional Texture2D is used directly for multi-layer blending, the Shader will declare failure right at the compilation stage due to hardware limits on Sampler registers and Texture Binding counts (for example, on conventional mid-to-low-end Android OpenGL ES 3.0/3.1 devices, the upper limit is only 16).

A common compromise solution in the industry is to use Multi-Pass (multi-channel rendering) to split up the layers. However, large terrains already have a very high vertex/polygon count; this approach not only doubles the geometric pressure but also causes severe Overdraw bandwidth overhead on mobile devices by forcing the terrain to be repeatedly drawn across the full screen, with lighting and shadows calculated multiple times.

When Unity's native terrain needs to blend more than 5 layers of textures (in this case, 2 control maps, along with 8 albedo and 8 normal maps), the underlying system is forced to switch to Multi-Pass rendering. Through the Frame Debugger, we can clearly see that the terrain is brutally rendered twice, resulting in a severe waste of performance.

Solving the Landscape Dilemma: Z-Terrain's Underlying Architecture and Core Philosophy

Having developed mobile games for a long time, I noticed that the terrains artists create are actually mostly flat ground, and ultimately, atmospheric richness is achieved by stacking a large number of scene objects. Furthermore, I have personally deeply felt the pain of late-stage artists having to repeatedly level and re-dig terrain when "moving lakes and changing rivers."

So I thought: Is it possible to completely solve the terrain by solely "placing scene objects"? Let the terrain itself have absolutely no Deform (geometric bumps or depressions). If I can just handle the "edge transition blending between objects and the ground" perfectly, and allow the ground to "reveal objects situated below the surface (like lake bottoms or underground rivers)," wouldn't that perfectly achieve the goal of a large open terrain while simultaneously liberating the artists' productivity?

Z-Terrain in-game rendering: The ground is a completely flat mesh with zero deformation (Zero Deform). All landforms (lakes, mountains, and even underground cracks and depressions) are pieced together from independent objects, and perfect edge transition blending and downward surface penetration are achieved through the underlying Shader.

Letting the Data Speak: S8 Performance Benchmark (13-Layer TileMap Blending)

The concept sounds wonderful, but can the performance really hold up when actually deployed to the underlying hardware?

To test the limits of Z-Terrain, we deliberately chose an extremely outdated mobile device by today's standards—a Samsung Galaxy S8 (Mali-G71 GPU)—for a hellish stress test.

We crazily stacked 13 layers of detail texture blending on the Z-Terrain (including 13 Albedo and 13 Normal maps, totaling 26 texture assets and 28 samples), and used a brush to arbitrarily paint complex landscape details on the ground.

The actual test results completely shattered the performance ceiling of traditional terrain systems:

Even on the legacy S8 platform (Mali GPU), a 13-layer blend—including both Albedo and Normal maps—still manages to run at a locked 60 fps with stable performance.

Frame Debugger panel: The entire open-world ground rendering consumes only 1 Draw Call. The other Draw Call circled above is independently occupied by the lake object.

Once you exceed 5 layers on a native Unity Terrain—meaning you open a second Control map—you have to draw (render) the Terrain two or more times.

Revealing the Core Black Magic: How Did I Force a 13-Layer Blend on Mobile?

The main reason traditional terrains cannot use One-Pass rendering is that their TileMaps do not utilize TextureArray, causing the number of Texture Bindings to exceed hardware limits. So, simply replacing the single-texture architecture of the TerrainLayer with a TextureArray should do the trick.

But it's not that simple; multiple Control Maps suffer from the exact same hardware flaw. Therefore, Z-Terrain comprehensively consolidates both of these into TextureArrays, suppressing the number of Texture Bindings used to the absolute extreme:

It consolidates the 13 layers of ground surface details (Albedo/Smoothness) into a single Texture Array of 13 Slices, occupying only 1 texture slot.

Multiple Control Maps cannot escape the fate of being arrayed. Under a 13-layer surface blend, a single terrain chunk originally required 3 independent Control Maps (12 channels); Z-Terrain directly consolidates multiple Control Maps into a single TextureArray, fundamentally resolving the register and Texture Binding limits during multi-layer blending.

Breaking the Visual Bottleneck: Perfect Edge Transition Blending Between Objects and Ground

This is the utmost priority of the entire Z-Terrain system. Since we opted for a "Zero Deform all-object workflow," the transition quality at the contact surfaces between objects and the ground directly determines the success or failure of the entire large scene.

To achieve perfect visual effects, Z-Terrain adopts the following architecture at the base level:

Live Demo: When dragging the object or tweaking the sliders, the mountain base textures and normals blend together dynamically with an extremely smooth gradient.

Implementation Philosophy: Globalized Assets and Multi-Dimensional Transitions

The core to Z-Terrain achieving seamless transitions lies in the globalization of Control Map (weight map) and Tile Map (detail texture) data:

World Space Sampling: Whether it's the flat Quad ground serving as the foundation, or any scene objects placed on top of it (like mountains or rocks), they all uniformly use world coordinates (World Space Position.xz) within the Shader to sample textures and weights. This means objects and the ground share the exact same data perspective at the pixel level, naturally possessing continuity.
Height Blending Weights: Utilizing the Global weight data from the ground's control map, combined with the depth relationship of object pixels, it dynamically controls the transition range and blending weights of edge materials via blending sliders, achieving a visual deception effect identical to native Terrain Deform (terrain upheaval).
Dual Blending of Texture and Normal: If blending is only done on the Albedo texture, lighting will instantly reveal the trick because the normal directions of the object and the ground don't match. Z-Terrain achieves smooth transition of both textures and ground Normals simultaneously at the boundaries, ensuring that shadows and highlights remain completely continuous and unbroken when lit.

This is a fantastic solution for the notorious terrain UV stretching issue. It turns out that even when utilizing Unity's Terrain system, scattering environment assets remains unavoidable.

Another Key Point: Downward Surface Penetration (Reveal Processing)

For traditional terrain systems to create lakes, rivers, or cracks, the only pipeline is to use a heightmap to Deform (dig out a depression downwards) and then cover it with a Plane Mesh (water surface mesh) on top to simulate the water body.

The core goal of Z-Terrain is to completely abandon this high-maintenance deformation operation. We want to be able to simply place a lake object to quickly modify a level. But this brings a soul-searching challenge: on a completely flat ground mesh, how do you allow the line of sight to penetrate the ground and see objects hidden below the surface?

The lake depth fade and shoreline textures blend seamlessly.

The crack asset can also seamlessly intersect with flat surfaces and achieve a perfect edge blend.

Abandoning Stencil, Pivoting to an Extreme Blending Rendering Strategy

In the early stages of technical implementation, the most intuitive approach was to use the Stencil Buffer to carve out the ground. However, after actual stress testing, to ensure the perfect blending quality of semi-transparent transitions for ground materials, I ultimately abandoned the Stencil solution and adopted an extremely clever combination technique:

Alpha Blending + Cull Off + Back-face occluding forward surface.

Although this approach slightly sacrifices some Overdraw overhead on mobile TBDR architectures, the return is unparalleled: we successfully achieved a pixel-level, high-quality "downward surface penetration effect" that perfectly complies with correct perspective occlusion relationships on a completely flat Quad mesh. Artists no longer need to re-bake heightmaps; simply drop a lake object, and the underlying Shader automatically digs open the ground.

By disabling culling (Cull Off) and implementing occlusion logic, the system ensures that the terrain mesh is precisely hidden under any perspective view, revealing only the intended underlying content.

The Cross-Control Map Boundary Issue (Breadth Solution)

When facing an extremely massive terrain, the resolution of a single Control Map usually hits an upper limit. The conventional industry practice is to slice the terrain into many chunks (Pages). However, this triggers a catastrophic pipeline disaster during "object blending": when a massive mountain crosses a chunk boundary, the object Shader cannot dynamically decide which Control Map to sample.

Z-Terrain stress test: Even when the object is placed directly at the center of a four-page quad-intersection, the underlying system maintains absolutely precise, fluid, and seamless material blending.

Pixel-Level "Breadth" Slice Conversion Mechanism

Z-Terrain comprehensively processes Control Maps into TextureArrays. No matter how many Pages the map is divided into, to the GPU, they are simply different Slices within the same texture register. The Shader directly uses the pixel's world coordinates to perform breadth mathematical formula conversions, dynamically calculating exactly which terrain chunk grid the current pixel is stepping on. This ensures that it only ever needs to sample the corresponding chunk's Control Map exactly once.

The Soul of the Toolchain: Real-Time Editing with TextureArray

If the rendering performance is robust but causes the artist to experience severe lag during editing, the system is still a failure. To end this pipeline pain point, Z-Terrain utilizes a proprietary brush tool driven entirely by Compute Shaders:

Z-Terrain Brush Editing Interface

Precise Pixel-Level Addressing: Compute Shaders possess extremely powerful parallel read/write capabilities (RWTexture2DArray). It precisely addresses and overwrites weights solely for the pixels covered by the current brush radius.
Inherently Friendly Output Targets: Because CS can directly write data into specific Slices of a TextureArray, the brushing feel is incredibly silky smooth, completely solving the historical nightmare of "unbearable lag".

For more details on the Compute Shader brush, please refer to my previous article here:

Unity Brush Technology: Breakthroughs and Practical Insights — From SetPixels to Compute Shader

Conclusion: The Ultimate Answer for Next-Gen Mobile Terrains

Z-Terrain wasn't born to reinvent the wheel, but to forge a bloody path for art pipelines and rendering bandwidth within the extreme constraints of mobile performance. We can intuitively see the decisive differences:

1. Geometry Polygon Pressure: Unity Native Terrain (Extremely High) vs. Z-Terrain (Zero Pressure - flat quad mesh).
2. Landform Modification Cost: Traditional Plugins (Destructive pipeline hell) vs. Z-Terrain (Extremely Low - all-object workflow, place and modify at will).
3. Multi-Layer Material Blending: Unity Native Terrain (Forces Multi-Pass > 5 layers) vs. Z-Terrain (Powerfully supports 13+ layers in 1-Pass).
4. Cross-Page Edge Transition: Traditional Plugins (Unsolvable) vs. Z-Terrain (Perfectly seamless via global world coordinates).
5. Mobile Draw Call Overhead: Traditional Plugins (Increases linearly) vs. Z-Terrain (Extreme batching, constant 1-Draw Call via SRP Batcher).

Z-Terrain proves one thing: in mobile graphics development, the top-tier optimization isn't usually optimizing the old pipeline, but rather thoroughly subverting and reconstructing from the base data structures and art pipelines.

The reference youtube：

You can get it here：

Z-Terrain: Zero Deform Ultimate Mobile Landscape

Associated Asset Page：

https://assetstore.unity.com/publishers/86820

Development Insights: GPUDrivenForwardPlus

2026-03-03T09:44:00.001+08:00

I have always been deeply fascinated by Forward Plus lighting architectures. Before the official URP Forward Plus was released, I implemented a custom Forward Plus solution for URP based on Depth Pre-pass, known as ForwardPlusURP

The core logic of that version followed the classic Tile-based Forward+ approach: it rendered a depth pre-pass to calculate the depth range for each tile and performed light culling to reduce the cost of light loops in the fragment shader.

The Challenges of Mobile Platforms

However, during practical testing and development, I realized that this path faced structural issues on mobile platforms:

Cost of Depth Pre-pass: On mobile GPUs (TBDR architecture), a depth pre-pass adds a significant geometry rendering stage, which often disrupts hardware-level optimizations like cache efficiency and Early-Z behavior.
Dependency on Interlock Operations: The implementation relied heavily on Pixel Interlock (or similar atomic operations) to maintain light lists. On mobile GPUs—specifically Mali and PowerVR architectures—this often leads to pipeline serialization and unstable performance.

Due to these factors, I decided not to pursue that specific direction further.

A New Inspiration: Clustered Shading

When the official URP Forward Plus (based on CPU-side Job System light culling) was released, it provided a different perspective: a "stable, predictable, and depth-pre-pass-independent" light management model.

This sparked a new question: Is it possible to design a GPU-driven light culling architecture specifically for mobile—one that doesn't rely on depth pre-passes or heavy interlocks, while maintaining compatibility with the standard Forward workflow?

This goal led me to explore Clustered Forward Plus, resulting in the implementation of GPUDrivenForwardPlus.

Implementation Workflow

Frustum Voxelization: Subdivide the Camera's View Frustum into AABB Clusters.
GPU Light Culling: Use a Compute Shader to perform intersection tests between AABB Clusters and visible lights.
Light Indexing: Record the culling results, including light indices and counts, into a buffer.
Shading: Convert screen-space coordinates to the corresponding cluster index to retrieve light data for final shading.

Key Features & Optimizations

Custom Light Culling: Since Unity’s SRP default Visible Lights count is limited to 32 (including the main light), I re-implemented the culling logic to support up to 64 lights per camera.
Performance Balancing: To ensure performance stability, each cluster currently supports a maximum of 8 additional lights.
Mobile Friendly: By avoiding the Depth Pre-pass, this solution is highly efficient for mobile hardware and naturally supports Alpha-blended (Transparent) objects.
Supported Light Types: Currently supports Point Lights and Spot Lights.

Resources：

SmallBurger Plugins Now Support Unity 6.3 LTS

2026-01-08T20:51:00.000+08:00

A selection of SmallBurger Asset Store plugins has been tested and verified with Unity 6.3 LTS.

Currently, 8 out of 21 plugins have been validated on Unity 6.3 LTS.

Additional plugins will be tested and updated progressively based on project priorities.

You can find the complete SmallBurger plugin lineup on the Unity Asset Store publisher page:

👉 Smallburger

🌸GPU-Driven Poetic Dynamics: From Simulating Ghost of Tsushima’s Iconic Flower Field to the Birth of a Complete Vegetation System

2025-12-17T12:56:00.001+08:00

In my previous post, Simulating Ghost of Tsushima’s Iconic White Flower Field in Unity, I wrote:

“I hope it can eventually run just as smoothly on mobile devices.”

That goal was achieved sooner than expected.
And that white flower field is no longer alone.

Today, the same architecture can support twenty types of vegetation — all processed on the GPU — handling wind simulation, interaction, painting, and culling simultaneously.

This article is not merely a showcase of results, but a record of the journey — from a simple flower field experiment to a complete vegetation system.
A journey to find what I call “poetic dynamics” on the GPU.

1. Architectural Philosophy — Let the GPU Become Nature’s Executor

The core design of this system is simple yet ambitious:
every natural dynamic computation — vegetation generation, wind simulation, interaction, brush editing, and occlusion culling —
is done entirely inside the Compute Shader.

The CPU does only one thing: it sends the list of visible cells to the GPU — and then steps aside.
From there, all logic and rhythm evolve within the GPU itself.

In traditional approaches, wind motion and collisions are usually computed in the Vertex Shader.
That means every vertex redundantly performs the same wind and displacement calculations —
repeating identical work for thousands of grass blades.

On desktop platforms this might be tolerable,
but on mobile, that kind of repeated computation comes at a steep cost.

So I moved everything into the Compute Shader —
where each frame’s logic is calculated once and passed to the Vertex Shader as RenderTextures.
This eliminates redundant work and transforms each GPU dispatch into a self-contained ecological simulation cycle.

My goal was to let the GPU not just render nature,
but understand its rhythm.

With data flow kept closed and continuous,
the system can maintain 57–60 FPS even on mid-to-low-end mobile devices.

2. Compute Shader Workflow

This is the technical heart of the entire system.
Every blade of grass, petal, gust of wind, and interaction is processed within a single Compute Dispatch.

a. Cells and Visibility

The scene is divided into cells using a Quadtree structure.
The CPU performs View Frustum Culling to determine the VisibleCellList,
then sends that list to the GPU.
That’s the only part the CPU handles.

b. Procedural Generation and Coordinate Conversion

The GPU procedurally generates each instance’s transform and spline data,
using a Voronoi algorithm to simulate natural clustering.
Each instance’s world coordinates are computed relative to its cell,
avoiding the memory and loading costs of pre-generated transforms.

c. Unified Compute Dispatch

Within a single dispatch, all of the following are computed:

PerInstanceCulling: view frustum, camera distance, and FilterMap-based filtering
Wind simulation: real-time calculation of wind direction and strength
Interaction (Displacement): player or object-driven grass deformation

d. Writing the Results

Based on FilterMap data, the system generates GrassBlade or Billboard Petal instances,
and writes results into the corresponding RenderTextures.

Each dispatch thus becomes a complete cycle of natural simulation.

3. Vertex Shader — Petal Attachment and Motion

Petals are rendered as billboards,
but I didn’t want them to simply “stick” to the ground.

Instead, each petal dynamically attaches to the tip of its corresponding grass blade,
swaying in sync with the wind.

This small detail transforms the scene from mere simulation
into something that feels like it’s breathing.

4. FilterMap and Brush System

a. FilterMap Structure

G channel: vegetation type (index)
A channel: density / intensity
It uses ASTC compression to keep memory usage under control for large open worlds.

b. GPU-Based Painting

Brush editing is handled entirely on the GPU via Compute Shaders, supporting TextureArray editing directly.
All brush results are written to RenderTextures — no CPU feedback required.
Saving is done asynchronously with AsyncGPUReadback.Request, allowing smooth, real-time saving of multiple FilterMap layers even in large scenes.

This design lets artists literally paint landscapes —
while keeping full consistency within GPU data flow.

5. RenderTexture Data Flow Design

I initially used AppendBuffer, but found it unstable on mobile devices.
Some GPUs have limited support for unordered buffers,
leading to inconsistent performance.

Switching to RenderTextures for all data storage solved this:
each channel now holds a different attribute — position, height, index, or type —
and integrates seamlessly with shaders, brushes, and occlusion systems.

This shift significantly improved compatibility
and maintained 57–60 FPS even on mid-tier mobile hardware.

6. HeightMap Raycasting and Ground Conformity

During the editing phase, the system continuously performs HeightMap raycasting
to capture terrain and object height data.

That data is used to align vegetation precisely to the surface —
ensuring every blade and petal follows the true contour of the scene.

The results are shown instantly to the artist,
enabling true what-you-see-is-what-you-get vegetation placement.

Once editing is complete, the HeightMap is saved as a static texture,
and no further raycasting is done at runtime.

This approach strikes the perfect balance:
accurate editing, lightweight runtime —
smooth, stable, and efficient.

7. Mobile Performance Test

All tests were performed on a Samsung Galaxy S10.
Even on this mid-range device, the system maintained a steady 57–60 FPS.
Initialization time was between 0–65 ms, essentially instant.

For smoother video recording, I used a Samsung Galaxy Z Fold2 5G,
which further confirmed that this GPU-only workflow
is not just theoretically sound — it’s practically proven on mobile hardware.

8. Epilogue — The Poetry of the GPU and the Logic of Nature

It all began with a simple wish —
to recreate the swaying white flower field of Ghost of Tsushima.

But through countless iterations,
the experiment grew into a tool capable of expressing wind and life.

I realized that the GPU is more than a processor —
it can be part of nature, capable of expressing breath and rhythm.

And thus, this system was named GPUFloraPainter.

Its birth is not just the completion of a technology —
but the discovery that, in the digital world,
poetry too can be computed.

9. Related Video

10. 🌸 You Can Find It Here…

GPUFloraPainter

11. Other Assets

SmallBurger Assets

Camera-Adherent GPU Particles 1.0.3 — Multi-Light, Forward+, and Hybrid Lighting Upgrade

2025-11-25T23:49:00.002+08:00

The 1.0.3 update brings a major visual improvement to the Camera-Adherent GPU Particle system.

This release focuses purely on foreground, camera-facing particle effects—such as wind swirls, impact bursts, weapon trails, magic glows, atmosphere streaks, UI-adjacent FX, and any particle that stays tightly aligned to the screen.

These particles now react to lighting in a way that matches the rest of your scene’s illumination—without losing the performance advantages of a camera-adherent GPU pipeline.

🌟 1. Full Multi-Light Support (URP Forward & Forward+)

Camera-adherent particles traditionally rely on unlit shading because they live in screen-space rather than world-space.

This update changes that.

Point lights and spotlights now illuminate camera-aligned GPU particles.
Correct color, intensity, and distance attenuation are applied.
Fully compatible with URP Forward+ clustered lighting, enabling dozens of realtime lights on supported hardware.

Even though the particles are screen-aligned, the shading now reflects world lighting conditions—adding depth and realism to close-up effects.

🌈 2. Hybrid Lighting Pipeline (Auto Per-Pixel / Per-Vertex)

To balance visual fidelity and performance—especially on mobile and mid-range GPUs—the lighting pipeline now adapts automatically:

Material Setup	Lighting Mode	Behavior
Normal Map enabled	Per-Pixel Lighting	High-quality shading for glossy, detailed effects
No Normal Map	Per-Vertex Lighting	High-performance mode without sacrificing color accuracy
Storm Mode enabled	Lighting disabled	Recommended to avoid combining Storm + Lighting

This pipeline ensures that camera-adherent particles stay lightweight while still supporting physically meaningful lighting when needed.

🌫️ 3. URP Fog Integration

Camera-aligned particles now respect URP fog:

Smooth depth-aware blending
Consistent screen-space behavior
Matches scene mood and atmosphere

This prevents the visual mismatch that screen-aligned particles often have in foggy or atmospheric environments.

🔧 4. Naming Consistency Improvement

The material parameter:

MaskMap → lightMaskMap

This better reflects its role in controlling specular and emission contribution under the new lighting pipeline.

📝 1.0.3 Changelog

Fixes

Renamed MaskMap → lightMaskMap for clarity.
Fixed an issue where lightMaskMap did not correctly influence specular and emission.

Improvements

Multi-light support
- URP Forward & Forward+ clustered lighting
- Correct color & attenuation
Hybrid Lighting Pipeline
- Per-Pixel (normal map) / Per-Vertex (no normal map)
- Storm Mode disables lighting for consistency
URP Fog support
- Proper fog blending for camera-aligned particles

🎬 Demo Video

Get Camera-Adherent GPU Particles

All SmallBurger Assets on the Unity Asset Store

Simulating Ghost of Tsushima’s Iconic White Flower Field in Unity

2025-10-13T13:36:00.003+08:00

I’ve always been fascinated by the vegetation system in Ghost of Tsushima.
After finishing the grass part earlier, I finally decided to tackle the iconic white flower field.

To keep the performance suitable for mobile platforms, the flowers are rendered using Billboards,
while the stems are generated procedurally through a Noise Spline Blade system.
The main challenge here is making each Billboard follow the endpoint of its corresponding Spline Blade,
so the flowers can sway naturally with the wind.

This was also my first attempt to handle multiple instance types within a single Compute Dispatch — managing both the simulation and culling processes together.
Honestly, I didn’t expect the Billboard effect to look this good,
but once I saw the entire field moving with the wind, it completely exceeded my expectations.

Youtube Video Link：

This is only the first stage of development.Next, I’ll be focusing on improving the editor tools and optimizing performance on mobile devices. Hopefully, this system can eventually run smoothly on phones as well.

Building a Cross-Platform GPU Procedural Grass System in Unity URP (Optimized for Mobile)

2025-09-30T14:59:00.001+08:00

Recently, I’ve been working on a project called UnityURP-Procedural-DrawMeshInstancedIndirect, and I’d like to share some advantages of procedural generation.

Unlike traditional methods that rely on massive Transform Buffers or GameObject instances, this approach dynamically generates grass using ComputeShaders. For culling, I use a RenderTexture to store results (since SSBOs aren’t supported in many mobile VertexShaders), ensuring compatibility with most mobile devices.

This architecture significantly improves load times and performance, especially on mid- to low-end phones. Let’s break down the key design concepts step by step.

Why Not Use Traditional TransformBuffer-Based Grass?

Unity’s built-in grass and tree systems, or approaches using DrawMeshInstanced/DrawMeshInstancedIndirect, often require the CPU to prepare huge amounts of data before passing it to the GPU. When your scene contains hundreds of thousands or even millions of blades of grass, the memory and load cost of Transform Buffers becomes overwhelming.

My solution: Don’t prepare this data at all. Let the GPU handle procedural generation. This way, grass distribution, size, rotation, and wind can be generated dynamically—saving memory and increasing flexibility.

1. Creating and Binding CountBuffer and RenderTexture (No AppendBuffer)

First, create and bind the CountBuffer for instance counting in the ComputeShader. Next, set up a RenderTexture to store culling results, and bind it to both the ComputeShader and the material.

m_instanceCountBuffer = new ComputeBuffer(1, sizeof(uint),
    ComputeBufferType.Counter);
m_instanceCountBuffer.SetCounterValue(0);
m_targetProceduralInstanceFilterCS.SetBuffer(0, msr_instanceCountBufferID,
    m_instanceCountBuffer);

m_filterResultRT = new RenderTexture(m_filterResultSize.x,
    m_filterResultSize.y, 0, RenderTextureFormat.ARGBHalf);
m_filterResultRT.enableRandomWrite = true;
m_filterResultRT.filterMode = FilterMode.Point;
m_filterResultRT.Create();
// ...
m_targetProceduralInstanceFilterCS.SetTexture(0, msr_filterResultRTID,
  m_targetFilterResultRT);
m_targetGrassMaterial.SetTexture(msr_filterResultRTID,
m_targetFilterResultRT);

2. Visible Cell Culling List

Use the VisableCellsCuller class to get the visible cell list, pass it to the ComputeShader, and use it to compute world positions for grass. Since each cell contains a fixed number of grass instances, it also helps calculate thread group counts.

private void OnBeginCameraRendering(ScriptableRenderContext context, 
    Camera camera)
{
    if (IsSkipCamera(camera))
        return;

    var cullingCamera = camera;
#if UNITY_EDITOR
    if (m_isOnlyViewMainCameraCulling)
        cullingCamera = Camera.main;
#endif //UNITY_EDITOR

    Bounds renderBounds;
    Vector2 cellSize;
    m_grassParamsSector.GetRenderBoundAndCellSize(out renderBounds, 
        out cellSize);

    m_visableCellsCuller.ProcessCulling(cullingCamera, in cellSize,
        in m_proceduralGrassData.m_worldRect, in msr_worldMinMaxHeight);

    var visibleCellIndices = m_visableCellsCuller.GetVisibleCellIndices();
    var visibleCellIndexCount = visibleCellIndices.Count;
    if (visibleCellIndexCount <= 0)
        return;

    m_targetProceduralInstanceFilterCS.SetVector(msr_cameraPositionID,
        camera.transform.position);

    visibleCellIndices.CopyTo(m_visibleCellIndices);
    m_visibleCellIndexBuffer.SetData(m_visibleCellIndices, 0, 0,
        visibleCellIndexCount);    
}
3.DispatchComputeInBatches
Wrap the ComputeShader dispatch logic in a DispatchComputeInBatches function to handle the 65535 dispatch count limit. If the count exceeds this, split into multiple dispatches.
private static void DispatchComputeInBatches(ComputeShader targetComputeShader,
    int processInstanceCount, int kernel = 0, int threadGroupSize = 64, 
    int maxDispatchCount = 65535)
{
    // Set the total number of instances for the shader to access
    // (for bounds checking)
    targetComputeShader.SetInt(msr_maxProcessCountID, processInstanceCount);

    // 'offset' tracks how many instances have already been processed
    int offset = 0;
    while (offset < processInstanceCount)
    {
        // Calculate how many instances remain to be processed in this batch
        int remainInstance = processInstanceCount - offset;

        // Dynamically calculate how many thread groups are needed for this batch
        // This is crucial: the last batch may not fill a whole thread group,
        // so we must recalculate based on the remaining instances.
        int groupCountThisBatch = Mathf.CeilToInt(remainInstance / (float)threadGroupSize);

        // Clamp the number of thread groups to the API limit (65535)
        int dispatchThisBatch = Mathf.Min(groupCountThisBatch, maxDispatchCount);

        // Set the offset for this batch so the shader knows the starting index
        targetComputeShader.SetInt(msr_offestCountID, offset);

        // Dispatch the current batch
        targetComputeShader.Dispatch(kernel, dispatchThisBatch, 1, 1);

        // Update offset to mark processed instances
        offset += dispatchThisBatch * threadGroupSize;
    }
}
4. ComputeShader Implementation
The core is procedural generation of transforms, using SimplexNoise for natural height and width variation. Culling includes both view frustum and a WeightMap filter, so grass only appears if its weight exceeds the minimum threshold. Results are stored in a RenderTexture.
/// <summary>
/// Author: SmallBurger Inc
/// Date: 2025/09/19
/// Desc:
/// </summary>

#pragma kernel CSMain
// ...
[numthreads(64, 1, 1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{ 
 uint instanceIndex = id.x + _OffsetCount;
 if (instanceIndex >= _MaxProcessCount)
  return;

 float2 position2D, randomOffest2D;
#if !defined(PROCESS_BILLBOARD)
 half yawRadians;
 GetInstanceTransform(instanceIndex, position2D, randomOffest2D,
  yawRadians);
#else
 GetInstanceTransform(instanceIndex, position2D, randomOffest2D);
#endif //!defined(PROCESS_BILLBOARD)

 if ((position2D.x < _WorldMinMax.x) ||
  (position2D.y < _WorldMinMax.y) ||
  (position2D.x > _WorldMinMax.z) ||
  (position2D.y > _WorldMinMax.w))
  return;

 float3 delta = _CameraPosition - float3(position2D.x, 0.0f, position2D.y);
 float viewSquareDistance = dot(delta, delta);
 if(viewSquareDistance > _MaxViewSquareDistance)
  return;

 half grassWeight = 1.0;
#ifdef PROCESS_WEIGHT_MAP_FILTER
 grassWeight = _WeightMap.SampleLevel(sampler_WeightMap, GetWorldUV(position2D), 0).a;
 if (grassWeight <= sc_skipWeightRatio)
  return;
#endif

 float4 absPosCS = abs(mul(_ViewProjectionMatrix,
  float4(position2D.x, 0.0, position2D.y, 1.0)));

 //do culling test in clip space, result is the same as doing
 //test in NDC space.
 //prefer clip space here because doing culling test in clip space
 //is faster.
 if ((absPosCS.z > absPosCS.w) ||
  (absPosCS.y > absPosCS.w * _MaxInstanceSize) ||
  (absPosCS.x > absPosCS.w * _MaxInstanceSize))
  return;

 uint index = _InstanceCountBuffer.IncrementCounter();
 
 uint offestIndex = index * 2;

 half2 worldUV = GetWorldUV(position2D);

 _FilterResultRT[int2(offestIndex % _FilterResultRTSize.x, offestIndex / _FilterResultRTSize.x)] =
  float4(worldUV, GetDestSize(position2D, grassWeight));

 ++offestIndex;

 half wind = CalculateWind(position2D);

#ifdef PROCESS_BILLBOARD 
 float hash = frac(sin(dot(position2D, float2(12.9898, 78.233))) * 43758.5453);
 float angle = hash * 6.2831853;
 float2 randDir = float2(cos(angle), sin(angle));

 half3 randomAddToN =
  (_RandomNormalWeight * randDir.x) * _CameraRightWS +
  (_RandomNormalWeight * randDir.y) * _CameraForwardWS;

 half3 windAddToN = wind * (-0.25 * _CameraRightWS);
 half3 normalWS = normalize(half3(0,1,0) + randomAddToN);
#endif

 _FilterResultRT[int2(offestIndex % _FilterResultRTSize.x, offestIndex / _FilterResultRTSize.x)] =
  float4(
   wind,
#if !defined(PROCESS_BILLBOARD)
   sin(yawRadians), 
   cos(yawRadians),
   0.0
#else
   normalWS
#endif //!defined(PROCESS_BILLBOARD)
   );
}
5. WeightMapFilter: Artistic Control Over Grass Distribution
Procedural generation alone can make grass look “too regular.” I added a WeightMapFilter mechanism so artists can paint grass weights directly onto a texture. The ComputeShader uses this filter map during generation, allowing artists to control large-scale distribution while procedural generation handles fine details.
With FilterMap

Without FilterMap

6. Prefer ComputeShader Over VertexShader for Instance Logic
Many DrawMeshInstancedIndirect solutions compute normals, random size, rotation, wind, etc., in the VertexShader. If you only need one instance’s data, move as much logic as possible to the ComputeShader.
half wind = CalculateWind(position2D);

#ifdef PROCESS_BILLBOARD 
 float hash = frac(sin(dot(position2D, float2(12.9898, 78.233))) * 43758.5453);
 float angle = hash * 6.2831853;
 float2 randDir = float2(cos(angle), sin(angle));

 half3 randomAddToN =
  (_RandomNormalWeight * randDir.x) * _CameraRightWS +
  (_RandomNormalWeight * randDir.y) * _CameraForwardWS;

 half3 windAddToN = wind * (-0.25 * _CameraRightWS);
 half3 normalWS = normalize(half3(0,1,0) + randomAddToN);
#endif

 _FilterResultRT[int2(offestIndex % _FilterResultRTSize.x, offestIndex / _FilterResultRTSize.x)] =
  float4(
   wind,
#if !defined(PROCESS_BILLBOARD)
   sin(yawRadians), 
   cos(yawRadians),
   0.0
#else
   normalWS
#endif //!defined(PROCESS_BILLBOARD)
7. GrassShader Implementation
Parse RenderTexture data: each instance uses two pixels—one for position and size, another for wind and normal (or rotation for non-billboard mode).
void GetInstanceTransform(in uint instanceID, in float4 filterResultRTTexelSize, in float4 positionOS,
    in half3 normalOS, in half2 windDirection, in float4 interactorCollisionSphere,
    in half interactorAffectWeight, in half windNormalWeight,
    out half2 worldUV,
    out float3 positionWS,
    out half affectWeight,
    out half3 normalWS,    
    out float viewDistance)
{   
    float2 position2D;
    half2 sizeFactor;
    half wind;
#ifdef PROCESS_BILLBOARD
    GetGrassInstanceData(instanceID, filterResultRTTexelSize, worldUV, position2D, sizeFactor, wind,
        normalWS);    
#else
    half yawSin, yawCos;
    GetGrassInstanceData(instanceID, filterResultRTTexelSize, worldUV, position2D, sizeFactor, wind,
        yawSin,
        yawCos);
#endif //PROCESS_BILLBOARD

    float3 instancePosition = float3(position2D.x, 0.0, position2D.y);
    viewDistance = length(_WorldSpaceCameraPos - instancePosition);

    affectWeight = positionOS.y;
    
#if !defined(PROCESS_BILLBOARD)
    GetRotateWorldPosition(positionOS.xyz, instancePosition, sizeFactor, yawSin, yawCos, positionWS);
#else
    GetBillboardWorldPosition(positionOS.xyz, instancePosition, sizeFactor, viewDistance, positionWS);
#endif

    float2 windOffest = windDirection * wind * affectWeight;
    positionWS.xz += windOffest;

    ApplyInteractorOffest(instancePosition, interactorCollisionSphere,
        step(0.5, affectWeight) * interactorAffectWeight, positionWS);
    
#if !defined(PROCESS_BILLBOARD)
    CalculateNormal(normalOS, yawSin, yawCos, windNormalWeight * affectWeight, windOffest, normalWS);
#endif
}
8. Collision Handling
As mentioned, try to move as much logic as possible to the ComputeShader, especially when handling multiple interactors—doing this in the VertexShader is not ideal for performance. In this project, since there is only one interactor and moving it to the ComputeShader would require extra pixels, I kept it in the VertexShader. But feel free to refactor if needed.
void ApplyInteractorOffest(in float3 instancePosition, in float4 collisionSphere,
    in half applyWeight, inout float3 positionWS)
{
    float3 delta = instancePosition - collisionSphere.xyz;
    float squareDistance = dot(delta, delta);
    float maxCheckRadius = _MaxInstanceSize + collisionSphere.w;
    float maxCheckSquareRadius = maxCheckRadius * maxCheckRadius;
    if (squareDistance > maxCheckSquareRadius)
        return;

    // linear falloff (1 at center, 0 at radius) — can be changed to smoothstep/pow/exp
    float falloff = saturate(1.0 - (squareDistance / maxCheckSquareRadius));

    // Direction: from interactor to instance (avoid divide-by-zero)
    float3 dir = (squareDistance > 1e-5) ? normalize(delta) : float3(0.0, 0.0, 0.0);

    // Use interactor.w as base strength (multiply global scale here if needed)
    float magnitude = falloff * collisionSphere.w;// *_InteractorAffectWeight;

    // Storage format: float4(dx, dy, dz, strength)
    float3 displacement = dir * magnitude;

    positionWS.xz += applyWeight * displacement.xz;
}
9. Loading Time
With no precomputed Transforms or runtime initialization, loading is extremely fast—often under 0.1 seconds. (Games like Ghost of Tsushima likely use similar techniques.)
Demo Video

Github
UnityURP-Procedural-DrawMeshInstancedIndirect
References & Further Reading
If you want to support more vegetation types, advanced brush tools (ComputeShader-based brushes), optimized multi-interactor collision flows, or mesh-conforming features, check out:
GPUPlantPainter
For more complex procedural workflows (procedural random curve vegetation effects, similar to Ghost of Tsushima), check out:
GPUGrassBladePainter

Unity Shader Keywords: shader_feature vs multi_compile — Complete Comparison Table and Usage Guide

2025-09-26T10:31:00.001+08:00

Many Unity Shader developers often get confused about the differences between shader_feature and multi_compile, and when to use each one. I’ve encountered similar confusion myself, so I’ve put together this comparison table and practical guide to help everyone quickly understand the correct usage.

Keyword Type	Variant Depends on Material	Global Scope	Material Keyword State Saved	Runtime Dynamic Switch	Typical Usage
shader_feature	✔️ (Yes)	✔️ (Global)	✔️	❌	Static config, lean build
shader_feature_local	✔️ (Yes)	❌ (Local)	✔️	❌	Static config, lean build
multi_compile	❌ (No)	✔️ (Global)	❌	✔️	Runtime switching
multi_compile_local	❌ (No)	❌ (Local)	❌	✔️	Runtime switching

Unity Brush Technology: Breakthroughs and Practical Insights — From SetPixels to Compute Shader

2025-09-01T12:53:00.001+08:00

During the process of developing a brush system in Unity, I found that in-depth discussions about the “principles of brushes” are quite rare online. Many developers tend to use the engine’s built-in tools directly, rarely exploring the underlying mechanisms. In reality, only by truly understanding how brushes work can we break through the limitations of existing tools and create fully customized brushes tailored to our needs. This is also my motivation for writing this article — to share my technical explorations and practical insights, and to help more people understand and build their own brush systems.

SetPixels32 Brush: Moving Data from CPU to GPU

Let’s start with the simplest: SetPixels32. Anyone who has worked on fog of war systems is probably very familiar with it. Some might think using Graphics.CopyTexture is more efficient, but since brushes usually need to support arbitrary sizes, such approaches aren’t really suitable.

The following code is a typical SetPixels32 implementation: it iterates over every pixel within the brush coverage area, calculates the color based on distance and weight, and finally applies the entire texture to the GPU in one go.

var destColor = new Color32(0, 0, 0, 0);
for (int rowIndex = startRowIndex; rowIndex<=endRowIndex; ++rowIndex)
{
    for (int columnIndex = startColumnIndex; columnIndex<=endColumnIndex; ++columnIndex)
    {
        Vector2 gridCenter = new Vector2(
            worldMin.x + columnIndex * gridSize.x + halfGridSize.x,
            worldMin.y + rowIndex * gridSize.y + halfGridSize.y);

        int index = columnIndex + rowIndex * mapWidth;
        float sqrDistance = (brushCenter - gridCenter).sqrMagnitude;

        sqrDistance = Mathf.Clamp(sqrDistance, sqrhalfBrushInnerSize, sqrhalfBrushSize);
        float weightRatio = 1.0f - (sqrDistance - sqrhalfBrushInnerSize) / (sqrhalfBrushSize - sqrhalfBrushInnerSize);
        
        destColor = editColorBuffer[index];

        ProcessPixelColor(weightRatio, speed * 0.033f, isAdd, sqrDistance, sqrhalfBrushSize,
            in mouseDelta, ref destColor);
        
        editColorBuffer[index] = destColor;
    }
}
editTexture.SetPixels32(editColorBuffer);
editTexture.Apply();

The principle here is simple: the CPU processes each pixel in the brush area, then sends the entire texture data back to the GPU at once. This causes a large amount of CPU → GPU data transfer. The bigger the texture or the more textures you process simultaneously, the more apparent the performance bottleneck becomes. For brush operations that require real-time feedback and fine control, this approach is often not sufficient.

Fragment Shader Brush: Shifting Computation to the GPU

After understanding the performance bottleneck of SetPixels32, another way to optimize brush operations is to move the pixel processing from the CPU to the GPU — that is, using a Fragment Shader to achieve brush effects. This greatly reduces the CPU-to-GPU data transfer and allows each pixel’s calculation to be efficiently handled in parallel by the GPU.

The following shader code demonstrates how the calculation of pixel weight and color within the brush area is entirely handled by the Fragment Shader:

bool GetBltTextureColorAndBrushWeight(in VertexOutput input, 
    out half brushWeight, out half4 bltTextureColor)
{
    half2 dsetUV = input.screenPosition.xy / input.screenPosition.w;
    bltTextureColor = SAMPLE_TEXTURE2D(_MainTex, sampler_MainTex,
        input.screenPosition.xy / input.screenPosition.w);
    uint rowIndex = _TextureArrayIndex / 2;
    uint columnIndex = _TextureArrayIndex % 2;

    float2 wordPosition2D = float2((columnIndex + dsetUV.x) * _BrushInfo.z,
        (rowIndex + dsetUV.y) * _BrushInfo.w);

    float distance = length(wordPosition2D - _BrushTransform.xy);
    if (distance > _BrushTransform.w)
        return false;

    distance = clamp(distance, _BrushTransform.z, _BrushTransform.w);
    brushWeight = (1.0 - (distance - _BrushTransform.z) / _BrushInfo.y) * 
        unity_DeltaTime.z * _BrushInfo.x * sc_weightApplyRatio;
    return true;
}

This code mainly does two things:

Calculates the current pixel’s world position based on screen coordinates, then determines whether it falls within the brush radius.
If it is within range, it calculates the weight (brushWeight), which determines the brush’s influence on that pixel.

Advantages

Fully handled on the GPU: No need to send pixel data from CPU back to GPU, resulting in a significant performance boost, especially suitable for high-resolution or multi-brush operations.
Real-time feedback: Provides a more immediate and nuanced brush feel.

Disadvantages

Must traverse the entire RenderTexture: Even if the brush only covers a small area, the Fragment Shader still processes the entire texture, causing unnecessary computation.
Input/Output RenderTarget limitation: During processing, the input and output RenderTargets cannot be the same texture. Each draw requires copying (blitting) the original content to another RenderTexture before processing, which adds an extra GPU pass.
More complex for multiple targets: Managing and optimizing brush operations on TextureArrays becomes even more challenging.

P.S.: Unity’s official Terrain brush also uses this approach. For reference, see this link:
PaintTexture.shader

Compute Shader Brush: OnePass High-Efficiency Processing, TextureArray Support

After understanding the limitations of Fragment Shaders regarding Input/Output RenderTargets, we can further leverage the features of Compute Shaders to effectively solve these bottlenecks:

Input can be equal to Output
You can read and write directly on the same RenderTexture, without the need for extra Blit copies, significantly reducing resource consumption and latency.
Only process the pixels within the brush area
No need to traverse the entire RenderTexture; instead, calculations are performed precisely on the area affected by the brush, greatly improving performance.
Full support for TextureArray
You can directly read and write to TextureArrays, easily meeting advanced multi-layer texture requirements, offering greater flexibility and scalability.

These advantages make Compute Shader brushes far superior to traditional Fragment Shader brushes in terms of both performance and functionality, achieving true OnePass efficient painting.

The following Compute Shader code demonstrates these features:

Input is Output: Directly read and write on the target texture.
Only process a local area: Only computes the Rect area covered by the brush.

[numthreads(8, 8, 1)]
void CSMain (uint3 id : SV_DispatchThreadID)
{   
    if ((id.x >= _BrushPixelsColumnCount) ||
        (id.y >= _BrushPixelsRowCount))
        return;
    
    TextureIndex textureIndex;
    half brushWeight;    
    if (!GetDestPixelWeight(id.xy, textureIndex, brushWeight))
        return;

    SetEditTextureValue(textureIndex, half4(_TintColor,
        saturate(GetEditTextureValue(textureIndex).a + brushWeight)));
}

As shown above, the Compute Shader only processes the area affected by the brush (controlled by _BrushPixelsColumnCount and _BrushPixelsRowCount), and directly reads and writes on the target texture (which may be a TextureArray), fully leveraging the advantages of OnePass and high efficiency. Here, TextureIndex refers to the index of the TextureArray.

Comparison of the Three Approaches

SetPixels32 Brush
Advantages: Simple to implement, easy to understand.
Disadvantages: Large CPU→GPU data transfer, obvious performance bottleneck.
Fragment Shader Brush
Advantages: All computation is done on the GPU, improved performance, great real-time feedback.
Disadvantages: Must traverse the entire texture, computational waste; Input/Output RenderTarget limitations.
Compute Shader Brush
Advantages: Only processes the affected area, Input is Output, supports TextureArray, best performance and flexibility.
Disadvantages: More complex to implement, requires understanding of GPU parallel computation.

Among these three solutions, the Compute Shader brush stands out not just for its performance advantage, but as a cleaner, more direct, and elegant solution.

It transforms brushes from a process of data shuffling and repeated copying to a real-time creative process on the canvas by the GPU.

This shift brings not just “faster” performance, but an entirely new experience:

Artists can feel real-time feedback as if using a real paintbrush.
Engineers can implement complex brush requirements with cleaner logic.
Project development gains a highly efficient solution for large scenes and multi-layer textures.

From now on, SmallBurger’s Brush tool plugins will gradually transition from FragmentShader to ComputeShader.

SmallBurgerAssets

A Hidden Benefit of RenderGraph in Unity 6 URP: Public Access to Core Render Resources

2025-08-12T14:09:00.000+08:00

While exploring Unity 6’s URP, I noticed an interesting change: In the 2022.3.x versions, many internal render textures (like m_DepthTexture) could only be accessed via reflection, which was neither convenient nor safe. However, with the introduction of the RenderGraph architecture in Unity 6, these internal resources are now exposed through public APIs!

This means we can now access these core rendering resources in a much safer and more stable way, without relying on hacks or reflection. In my opinion, this is a great “side benefit” brought by RenderGraph, making custom rendering workflows more flexible and projects easier to maintain.

If you need to deeply customize your rendering pipeline, definitely take advantage of this improvement!

Tile3DInstancer: A Practical Solution for Large-Scale, Multi-Type GPU Instancing in Unity

2025-07-30T22:49:00.002+08:00

Have you ever run into this when building a large-scale scene?

You used DrawMeshInstancedIndirect to render millions of objects, and at first, it seemed like the perfect solution.

But then, as the number of instance types increased, things got messy. You had to break things up into multiple buffers, issue multiple draw calls—and worst of all, you had no way to know which instances were actually visible.

That means for every type of object, even if it’s not visible at all, the CPU still needs to issue a DrawMeshInstancedIndirect call to the GPU. That’s wasted draw overhead and CPU-GPU communication cost—for absolutely nothing rendered.

And on top of that? You’re manually managing transforms, rotations, scaling, and LODs for potentially millions of instances. Eventually, your scene becomes an unmaintainable blob of dense matrix data.

That’s exactly why we built Tile3DInstancer.

Tile3DInstancer was born from a very simple idea:

"Why are we duplicating every object, when we could just reuse templates?"

Just like building a puzzle, we only need to store where each piece goes, not copy every piece over and over again.

We implemented a Template Cell architecture that takes this concept to the extreme—and the results were not just elegant, but shockingly powerful:

🔁 All instance data is expanded only when needed
💾 No more transform bloat or memory overload
🚀 Per-instance culling via CPU Jobs
🧠 NonSync Jobs for lightweight objects (e.g. grass, pebbles), to avoid blocking the main thread
🏔 Sync Jobs for rare large objects (e.g. mountains), to ensure rendering is visually correct

Unlike traditional instancing systems that flatten every transform into a dense memory buffer, Tile3DInstancer keeps things modular and scalable. Our Template Cell system reuses transform data, and only expands real geometry at the right time.

We also provide a full TileMap Editing Mode, allowing you to paint out large areas using tile-based layout, and preview results in real time. No more planting thousands of objects manually in the Hierarchy view—everything is fast, visual, and GPU-backed.

Want even more control? Our CellHolder Brush Tool lets you create reusable templates with ease. You also get per-cell instance count monitoring, so you can paint freely without accidentally overpopulating your scene.

The result?

A Unity toolset that combines GPU-friendly batching, per-instance culling, and real-time TileMap editing—letting you build and run massive, complex, multi-type 3D worlds with performance that works even on mobile.

🎥 Demo Video:

📦 Try Tile3DInstancer now:
Tile3DInstancer

🧰 More tools by SmallBurger:
SmallBurger

TestAPK

Just Released: MobileSSAO with Full Unity 6 Support

2025-07-22T09:51:00.001+08:00

What's New in the Unity 6 Version of MobileSSAO?

✅ Full support for RenderGraph architecture

✅ Now compatible with URP Forward+ rendering path

✅ Edge Down Sampling remains available for optimal performance

🔗 Asset Store:MobileSSAO

🔗 More Assets by Us:SmallBurgerAsset

Tile3DInstancer

2025-07-04T17:47:00.000+08:00

Tile3DInstancer is built on the core architecture of InstanceCollector (with instance culling and collection handled outside of the same job), and incorporates cell template processing for objects. It can load over 5 million instance transforms in just 2 seconds, while significantly reducing memory usage. I am currently developing an editor for it.

If you are interested, you are welcome to download and test the APK here:
https://drive.google.com/file/d/15rysW3nFSwX7JLdYAuyf-ojaHWueCHjQ/view?usp=drive_link

GodViewFakeDOF: Introducing Blur Rect Height Ratio for Better Performance

2025-06-16T17:27:00.005+08:00

Although GodViewFakeDOF already supports Mask Filter, it still processes the entire screen’s pixels.
This can easily lead to performance bottlenecks when using a high Render Scale and setting Blur Quality to High.

However, in practice, only about 40% of the screen height actually requires blur processing.
To avoid unnecessary computation, we introduced the concept of a Blur Rect — only applying blur to a designated area, significantly reducing GPU workload.

This update also introduces a new parameter: BlurRectHeightRatio, allowing users to customize the vertical range of the blur area according to the needs of their scene, enabling more flexible performance tuning.

🔹 The upper portion of the diagram below represents the area where blur is actually applied:

🟢 Final result shown below:

📦 Plugin location:
GodViewFakeDOF

📎 Related plugin references:
SmallBurger Assets

Optimizing SSAO on Mobile: Introducing EdgeDownSample in MobileSSAO (SmallBurger Assets)

2025-06-07T01:37:00.002+08:00

On mobile platforms, SSAO (Screen Space Ambient Occlusion) has always been a performance-intensive visual effect.

In MobileSSAO, we have already optimized the PreDepthNormalPass using MRT (Multiple Render Targets), but under high-quality settings with increased Sample Count, performance bottlenecks can still be noticeable.
This is especially true on mid-to-low-end devices such as the Galaxy S8, where achieving a balance between visual quality and smooth frame rates remains a key challenge.

To address this, we’ve introduced a new feature in this update: EdgeDownSample.
This is a flexible SSAO optimization technique that maintains high Sample Count in the center of the screen, while dynamically reducing SSAO sampling costs along the edges of the screen, resulting in significantly improved performance.

This design concept also aligns well with the current trend of Foveated Rendering, which is widely adopted in VR devices and supported by many modern hardware solutions. It is also highly suitable for portrait-mode mobile games, where UI elements are often positioned around the edges of the screen. In such cases, reducing SSAO sampling precision in these peripheral areas has minimal visual impact but can greatly reduce GPU workload.

Using the EdgeDownSampleScreenSizeRatio parameter, you can easily adjust the size of the edge zone.

This makes the feature especially effective for portrait-mode mobile games, where the main UI is typically placed along the screen edges—perfectly aligning with the principles of Foveated Rendering.

Performance Comparison (Galaxy S8, High-Quality Mode):

Without EdgeDownSample enabled:

With EdgeDownSample enabled:

ScriptableRenderPass to RenderGraph: Smooth Transition in Unity 6 URP

2025-05-28T11:22:00.003+08:00

With the official release of Unity 6 LTS, RenderGraph is no longer an experimental toy—it has become a significant evolution in Unity’s rendering pipeline. For developers using the Universal Render Pipeline (URP), how to seamlessly transition from the traditional ScriptableRenderPass to RenderGraph has become a hot topic.

I created the URPRenderGraphBridgeExample project with the hope of helping everyone maintain compatibility with different versions of Unity’s rendering systems on a single codebase, making it easier to learn and use RenderGraph.

Next, I’d like to share some design ideas and insights, which I hope will help those of you who are exploring RenderGraph!

Let me start with a key takeaway: “Always bind your resources precisely.”
When working with RenderGraph, this should be like a warning label stuck on every developer’s monitor. The core philosophy of RenderGraph is explicit resource declaration—you must clearly state what you’re using and how you’re using it. No ambiguity, no wishful thinking.

Now, let’s go through the overall workflow:

1. Retrieve relevant bound resources from ContextContainer (frameData):
In the Unity RenderGraph workflow, you typically obtain the necessary context for the current frame (such as camera data, command buffer, resource handles, etc.) from RenderGraphContext or a similar container.

2. Create a RenderGraphBuilder interface and corresponding PassData:
You call RenderGraph.AddRenderPass<T>("PassName", out passData) to create a pass, which returns a RenderGraphBuilder. You use this builder to set up resource reads/writes, dependencies, and more.

3. Bind the required resources precisely:
With the builder’s ReadTexture, WriteTexture, ReadBuffer, etc., you explicitly declare which resources the current pass needs. RenderGraph will automatically track dependencies.

4. Use the RenderGraphBuilder interface to call SetRenderFunc:
You must use a lambda function here; you cannot use a global function, or it will cause garbage collection (GC) issues.

5. The entry point: RecordRenderGraph:
As the name suggests, this is where you collect your rendering pass requirements. The order and process of rendering are managed by RenderGraph. For example, instead of worrying about how many times you call ConfigureRenderTarget, you just need to specify what you want to bind (remember: bind precisely!).

Let’s take a look at the implementation of a typical render object pass, CustomRenderObjectPass:

First, retrieve the relevant resources:

UniversalResourceData resourceData = frameData.Get<UniversalResourceData>();
UniversalRenderingData renderingData = frameData.Get<UniversalRenderingData>();
UniversalCameraData cameraData = frameData.Get<UniversalCameraData>();
UniversalLightData lightData = frameData.Get<UniversalLightData>();

Next, set up the Builder interface:
Use the builder to clearly define how each resource will be accessed.
SetRenderAttachment and SetRenderAttachmentDepth are especially important here—unlike UseTexture, RenderGraph will batch render state changes for these attachments. For other UseTexture calls, if the resource is not written to, just specify read.

P.S.: If you’re using ForwardPlus, you must set builder.UseAllGlobalTextures(true). I personally disagree with this approach—shouldn’t we specify resource usage precisely? Using everything means no optimization. I think Unity should provide a handle for ZBins-related buffers so we can bind resources precisely. See the code comments for more details.

Then, RenderStateBlock:
Since RendererListParams requires a RenderStateBlock, you must provide one even if you don’t use it—just set it to RenderStateMask.Nothing if you rely entirely on material definitions.

Finally, SetRenderFunc:
This is where the actual rendering call happens. In my tests, you must use a lambda function to avoid GC. If you don’t like this style, consider calling a static function within the lambda to maintain a reusable structure.

As for the example of a full-screen rendering pass (DistortionPass), there’s nothing particularly special to mention, except that the render target written to is only used by the current pass. So here, use builder.UseTexture(activeColorTH, AccessFlags.Write); and call Blitter.BlitCameraTexture to handle the full-screen pass.

Finally, regarding compatibility between 2022.3.x and Unity 6:
I use partial classes to separate the logic, unlike Unity URP where everything is written in a single RenderPass. Here’s a summary:

Shared parts: Elements like RenderEvent, ShaderTagID, FilteringSettings, and ProfileSampler are kept in the original RenderPass.
Original RenderPass: Override Execute and use the command buffer as before.
RenderGraphPass: The file name is suffixed with _RenderGraph, and you override RecordRenderGraph.

Why use partial classes instead of inheritance? Mainly because the event sources are different, so inheritance doesn’t fit well. If anyone has better suggestions for splitting the logic, feel free to comment and discuss.

Related GitHub project:
URPRenderGraphBridgeExample

Try It Now – MobileSSAO Now Supports RenderGraph (Unity 6 Ready!)

2025-05-23T23:19:00.001+08:00

We’re excitgd to announce the latest update to **MobileSSAO**:

✅ Fixed an issue where shader variants might fail to compile.
✅ Added initial support for the new RenderGraph pipeline (tested in Unity 2022.3.x and newer).
✅ Fully tested and verified in both Unity 2022.3.x and Unity 6.0.

This update ensures smooth compatibility with current and next-gen Unity versions, while maintaining maximum performance for mobile platforms.

MobileSSAO Asset

SmallBurgertAssets

A Tribute to Ghost of Tsushima: Creating a High-Quality, Mobile-Friendly GPU Grass System

2025-05-12T17:53:00.002+08:00

GPUGrassBladePainter

The vegetation system in Ghost of Tsushima left a lasting impression on me. Its rice-plant-like grass blade design avoids the common unnatural look of billboards and eliminates the visual flaws of cross-plane meshes when viewed from above. This became the starting point for developing GPUGrassBladePainter—my goal was to create a grass system capable of delivering similar visual quality on mobile platforms.

A Framework Tailored for Mobile Platforms

Since the target platform is mobile devices, the first challenge to tackle was the bottleneck of memory usage and loading performance. Traditional approaches often rely on pre-storing large amounts of Transform data, which not only consumes memory but also slows down loading times. To address this, I adopted a fully procedural method for randomly distributing grass positions—saving resources while improving efficiency.

Another common issue is the use of SSBOs (Shader Storage Buffer Objects), which either perform poorly or are completely unsupported on many mobile devices. To ensure both compatibility and runtime performance, I chose to store grass culling results using RenderTextures instead.

Storing culling results in a RenderTexture

Creating Rice-Plant-Like Grass Blades

Capturing the look and feel of rice plants was the most important goal of the entire system. I used randomly generated curve parameters to give each grass blade a naturally curved shape. This procedural approach produces non-repetitive, non-linear blade forms, recreating the layered and swaying beauty of rice fields as they move with the wind.

To prevent the grass from looking too chaotic, I integrated a Voronoi Clamp algorithm, which automatically clusters the blades into visually coherent patches—achieving a natural “growing in clumps” effect.

A case of being extremely close to the clamp center point

Pre-generated Voronoi Clamp texture

Dynamic Simulation of Natural Wind

The swaying of the grass isn’t just a simple animation—it simulates the global behavior of a natural wind field. By integrating wind parameters with the dynamic curves of each grass blade, I achieved a natural effect where wind intensity changes over time and space, resulting in varied swaying patterns across different areas. This brings the scene to life with a more dynamic and organic feel.

Demonstration of Randomized Wind Integrated with Curve Parameters

Performance-Oriented GPU Culling Techniques

In scenes with a large number of grass blades, performance management is crucial. I implemented GPU-based frustum culling and mask filter techniques to ensure that only visible areas are rendered. This significantly reduces rendering costs and improves frame rate performance.

Only display grass within the view frustum and areas with MaskFilterMap values.

Mask Filter map

Brush Tools Designed for Artists

GPUGrassBladePainter is a brush-based toolset that allows artists to intuitively paint grass masks—wherever you paint, grass grows. Beyond that, it supports automatic alignment to surface height, even on non-Terrain objects, allowing grass to naturally conform to the ground without manual adjustments.

To further enhance the editing workflow, GPU-based brush functionality is integrated, enabling real-time visual feedback. This "what you see is what you get" approach greatly improves editing efficiency and fluidity.

Using GPU-based brushes to improve grass painting smoothness.

Character Interaction and Grass Response

To bring more life to the scene, I added character interaction functionality. When a character walks through the grass, the blades dynamically bend and react in real time. This deformation is fully handled on the GPU, ensuring that it doesn't impact the performance of the main thread.

Character Push Interaction Demonstration

Conclusion: Bringing Console-Quality Grass to Mobile

The core goal of this system is to enable developers to achieve near-console-quality grass rendering on mobile platforms. Whether you're building a stylized meadow, an open-world environment, or looking to deliver smooth and responsive grass interactions, GPUGrassBladePainter offers a powerful balance of performance and flexibility.

This project is both a tribute to Ghost of Tsushima and a challenge taken on from the perspective of a mobile developer. I hope it inspires you to craft your own immersive natural landscapes.

Demo Video：

The Asset link:
GPUGrassBladePainter

DepthEdgeFlow — Geometry-Free Soft Edge FX for Unity URP

2025-05-12T14:41:00.000+08:00

Simulate shoreline motion and fog boundaries using depth reconstruction and noise, without any vertex displacement, tessellation, or raymarching. Optimized for mobile platforms.

Simulating shoreline transitions in Unity often involves vertex displacement or mesh tessellation —
which can be expensive or even impractical on mobile platforms.

That’s what led me to design a screen-space alternative I now call **DepthEdgeFlow** —
a technique born from my ongoing effort to bring geometry-free solutions to real-time mobile graphics.

Let’s take a look at how it works, starting from a common shoreline scenario.

Traditional oceans have a situation where the triangle count is even higher.

Let us first examine the traditional approach to simulating water surfaces.

This typically involves geometric tessellation to approximate wave motion.

A common implementation displaces vertex positions directly within the Vertex Shader, producing an oscillating surface that mimics wave dynamics.

However, this technique has inherent limitations:

When the mesh lacks sufficient vertex density, the surface deformation appears overly rigid, resulting in a “block-like” movement that resembles gelatin — visually unrealistic and lacking fine detail.

Conversely, increasing vertex density to achieve higher visual fidelity

can significantly impact performance on mobile platforms,

often causing frame rate degradation before the water surface even enters view.

These issues are further amplified in large-scale oceanic environments,

where the computational cost scales poorly with area coverage.

Let’s take a look at the top-down view scenario.

Traditional sea in a GodView scenario.

From this perspective, the only area where water surface undulation is actually visible is the narrow zone near the shoreline. The large central area of the water shows little visual variation, and players typically won’t pay much attention to it either.

So we started asking ourselves:

Is there a way to preserve only the detailed changes near the shore,

while skipping unnecessary simulation for the rest of the water surface?

Let’s start by watching the video below.

You’ll notice subtle vertical motion along the shoreline —

the water appears to ripple as if it’s being displaced by actual geometry.

But here’s the twist: there’s no tessellation or vertex deformation involved.

If you’ve implemented water shaders before, you might be familiar with a common technique:

reconstructing world position from the depth texture,

then comparing it to the water level to control transparency near the shore.

In this case, we simply added a bit of noise to the reconstructed height,

introducing minor fluctuations that create the illusion of dynamic movement.

This adds depth and natural detail — with virtually no extra cost.

What you just saw in the video is the result of this entire process.

I call this approach Depth Edge Flow.

Next, let’s take a look at the implementation details of this approach.

In DepthEdgeFlow.hlsl, there's a function called CalculateSoftEdgeFlowWeight. We simply need to pass in the NDC coordinates, positionWS, DepthParams, and PerlinNoiseParams from the Fragment Shader to compute the SoftEdgeFlowWeight.

half CalculateSoftEdgeFlowWeight(float2 positionCS2, float3 positionWS,
//x:range, y:power, z:offest surfaceHeight
float3 depthParams,
//x:worldScale, noiseSpeed, rangeRatio
float3 perlinNoiseParams)
{
float2 offestXZ = positionWS.xz * perlinNoiseParams.x +
_Time.y * perlinNoiseParams.y;
float surfaceHeight = positionWS.y + Snoise(offestXZ) *
perlinNoiseParams.z - depthParams.z;
return GetSoftEdgeFlowWeight(positionCS2, surfaceHeight,
depthParams.x, depthParams.y);
}

If you have your own noise implementation, you can also directly call GetSoftEdgeFlowWeight and pass in the computed height value.

half GetSoftEdgeFlowWeight(float2 positionCS2, float surfaceHeight,
float depthRange, float depthPow)
{
float3 groundPosition = ComputeWorldSpacePositionFromDepth(
positionCS2);
float depthRatio = saturate((surfaceHeight - groundPosition.y)
/ depthRange);
depthRatio = 1.0 - pow(1.0 - depthRatio, depthPow);
return depthRatio;
}

As for the ComputeWorldSpacePositionFromDepth part, it calls Unity's built-in ComputeWorldSpacePosition function, which already handles the inverse projection from depth to world space. We just need to provide the NDC coordinates, depth value, and UNITY_MATRIX_I_VP.

float3 ComputeWorldSpacePositionFromDepth(float2 positionCS2)
{
//float2 destPositionCS = positionCS;
#if UNITY_REVERSED_Z
float depth = LoadSceneDepth(positionCS2.xy);
#else
// Adjust z to match NDC for OpenGL
float depth = lerp(UNITY_NEAR_CLIP_VALUE, 1,
LoadSceneDepth(positionCS2.xy));
#endif
float2 positionSS = positionCS2 * _ScreenSize.zw;
return ComputeWorldSpacePosition(positionSS, depth, UNITY_MATRIX_I_VP);
}

As for the actual call to CalculateSoftEdgeFlowWeight, I'll use the AreaFog Fragment Shader as an example. It's easy to see that this part simply calculates an alpha transition weight called SoftEdgeFlowWeight.

half4 FragmentProgram(VertexOutput input) : SV_Target
{
real3 normalWS = real3(0.0, 1.0, 0.0);

half softEdgeFlowWeight = CalculateSoftEdgeFlowWeight(
input.positionCS.xy, input.positionWS,
float3(_Depth, _DepthPow, _OffestHeight),
float3(_PerlinWorldScale, _PerlinNoiseSpeed, _PerlinRnageRatio));
half maskWeight = SAMPLE_TEXTURE2D(_MaskMap, sampler_MaskMap,
input.baseUV).r;
#ifdef VIEW_SOFT_EDGE_FLOW
return half4(softEdgeFlowWeight, 0.0, 0.0, 1.0);
#else
return half4(_Color, softEdgeFlowWeight * maskWeight);
#endif
}

However, SoftEdgeFlowWeight doesn’t necessarily have to be used for alpha transitions.

For example, in the case of a water shoreline, what we want is a refraction distortion effect.

In this case, we use the URP’s After Opaque pass, and apply noise-based distortion based on depth to blend with the background.

The water itself remains an opaque object.

half4 FragmentProgram(VertexOutput input) : SV_Target
{
InputData inputData;
half3 normalTS;
InitializeInputData(input, inputData, normalTS);

half softEdgeFlowWeight = CalculateSoftEdgeFlowWeight(
input.positionCS.xy, input.positionWS,
float3(_Depth, _DepthPow, _OffestHeight),
float3(_PerlinWorldScale, _PerlinNoiseSpeed, _PerlinRnageRatio));

half3 diffuse = lerp(_ShallowColor, _DeepColor, softEdgeFlowWeight);
half4 specularGloss = half4(1.0, 1.0, 1.0, 1.0);
half smoothness = 0.5;
half3 emission = half3(0, 0, 0);
half alpha = 1.0;

half3 lightResult = UniversalFragmentBlinnPhong(inputData, diffuse,
specularGloss, smoothness, emission, 1.0, normalTS).rgb;

//Handling refraction blending
half2 distortionScreenUV = input.positionSS.xy / input.positionSS.w +
_RefractionDistortion * softEdgeFlowWeight * inputData.normalWS.xz;
half3 sceneColor = SampleSceneColor(distortionScreenUV);
return half4(lerp(sceneColor, lightResult, softEdgeFlowWeight), 1.0);
}

The related video is as follows:

DepthEdgeFlow is simple, efficient, and flexible —

ideal for situations where visual fidelity matters but resources are limited.

If you find ways to expand or adapt it for your own use case,

I’d love to see what you come up with.

### 🔗 GitHub Open Source
You can try DepthEdgeFlow yourself — the shader and sample scenes are open source:

AkilarLiao/DepthEdgeFlow

Includes demo scenes, shader code, and URP integration steps.

FakeVolumeFogPainter

FastRiverPainter

FFTOcean

InfinityStylizedWater

InifityQuadOcean

Optimizing Performance through InstanceCollector

2025-05-12T14:17:00.005+08:00

As SRP Batch technology has advanced, Unity’s automatic instancing feature is often disabled, leading to performance degradation when rendering a large number of objects.

While manual instancing (such as using Graphics.DrawMeshInstanced) offers better performance, it is typically limited to rendering large amounts of single-type objects and lacks support for full-scene optimization.

since Graphics.DrawMeshInstanced requires a pre-passed matrix array, a typical approach is to divide the scene into a grid, with each cell corresponding to a matrix array. Culling is then performed based on the bounds of each cell, or by using QuadTree or OctTree structures. However, this method does not perform per-instance culling, resulting in the rendering of more objects than with SRP batching, which can lead to poor performance.

There is no per-instance culling.

In addition, since the grid cutting is predetermined, if the camera zooms in and out, it can lead to an unsuitable size for the grid, resulting in an excessive number of draw calls when zooming out. Unless batching can be performed, this approach also prevents the number of arrays from being predetermined, and such processing can severely impact performance.

There are no batch cell draw calls.

The unique advantage of InstanceCollector is its ability to optimize GPU instancing across the entire scene. It not only effectively collects instance objects but also leverages Unity’s Job System for precise culling calculations, ensuring optimal rendering performance. If the culling is not accurate enough, the performance might even be worse than SRP Batch, highlighting the core strength of InstanceCollector’s technology.

Per-instance culling allows for one draw call in the batch.

Generally speaking, compared to DrawMeshInstanced, DrawMeshInstancedIndirect offers better performance because it gathers matrix data in the compute shader. However, the biggest issue arises when the object count is zero. Since the CPU cannot determine the number of objects, it still calls the rendering API, and it seems like additional data is being sent to the GPU. When there are many different types of objects, this may lead to a performance drop. Therefore, to handle instance collections for multiple object types, we choose to use DrawMeshInstanced along with culling via the job system.

Example of Using DrawMeshInstancedIndirect for a Single Type of Object.

Instance Collector uses the Job System (without occupying the main thread) to dynamically collect instances and supports multiple types of objects. Below is the related feature list.

Precise per-instance culling.
Dynamic instance collection using the Job System, without occupying the main thread’s resources.
Supports multiple types of instance objects, and even full-scene GPU instancing.
Provides a matrix array output tool to speed up scene loading and reduce memory usage.
Without using SSBO, it has better cross-platform compatibility.
For hardware that doesn’t support GPU instancing, the rendering process will fall back to using.
Simple instance object setup process (just add the Instancer script and enable “Enable GPU Instancing” in the material).
Compatible with SRP Batcher.
Customizable maximum visible object count for each type, adjustable based on project memory and performance requirements.
Support URP and Built-in render pipeline.

Relevant videos are as follows:

You can find it here:
InstanceCollector

MobileSSAO adds MRTTerrainLit shader

2025-05-12T14:08:00.005+08:00

It is well known that Unity’s Terrain has a high number of polygons, and rendering shadows requires an additional pass. On top of that, running the official SSAO post-processing effect, especially using the DepthNormal mode, requires a total of three rendering passes, which significantly impacts performance.

MobileSSAO recently added the MRTTerrainLit shader feature, which uses the MRT processing workflow to allow Terrain to render only once (excluding shadow rendering) while achieving SSAO effects with the DepthNormal mode. Below are the relevant reference images.

Unity terrain with SSAO applied.

Unity terrain without SSAO applied.

Unity terrain applies MobileSSAO’s triangle count.

Relevant videos are as follows:

You can find it here:

MobileSSAO

An Overview of FFTOcean

2025-05-12T14:01:00.002+08:00

FFTOcean is one of the most complex challenges I’ve faced in my game development career. This project involves multiple technical aspects, including ocean simulation, Fourier transform algorithms, projected grids, rendering pipeline planning, and water lighting simulation. In particular, improper handling of the MRT texture rendering and RenderPass operation flow can lead to performance issues. The main goal of this project is to ensure smooth operation on mobile platforms.

From left to right, and top to bottom, the first four images are displacement maps, followed by two slope maps, and the final one is a Jacobian foam map. The entire process uses Fourier transform to calculate the RenderTexture results.

To support ScreenSpaceDecals, it’s necessary to generate depth textures for the ocean. Considering that this project will run on platforms supporting OpenGLES 3.0 and above, we adopted the CopyDepthPass approach. However, since this method causes issues when running in the Editor (which uses its own independent RenderTexture), we implemented AppendDepthPass to address the problem.

Another noteworthy aspect is the integration of planar reflection textures in the distance. The rendering result transitions to the reflection based on the camera’s distance, achieving a seamless blend with the sky at far distances and avoiding visible edge lines.

In the image above, there is no visible edge line where the ocean surface meets the skybox.

As for the lighting effects, standard BRDF is used with no particular differences. However, it’s worth mentioning that sub-surface scattering is simulated here, resulting in a gem-like green tint visible on the water surface.

Additionally, a special mode called Infinity Quad Mode is provided. This mode uses only four vertices to render the entire infinite water body. It can be beneficial for hardware sensitive to vertex count or scenes with excessive triangle numbers, potentially improving performance.

Throughout the implementation process, Ceto and CRest provided a wealth of reference material. You can find their GitHub links below:

Scrawk/Ceto

wave-harmonic/crest

Relevant videos are as follows:

Actual performance on mobile devices:

You can find it here:

FFTOcean

An Overview of GodViewFakeDOF

2025-05-12T13:46:00.004+08:00

The concept for GodViewFakeDOF originated from the challenge I faced while developing a war strategy game, where I needed to implement a fog effect based on height considerations. However, the project requirements specified that fog should not affect any content in the center of the screen, regardless of altitude. To meet this requirement, I used a mask texture to filter out the fog effect from the center of the screen. Later, when trying to apply DOF effects for a GodView perspective, I found that the top-down view resulted in overly uniform depth values, making the DOF effect less pronounced. Building on my previous experience with height-based fog effects, I developed GodViewFakeDOF specifically for this type of perspective.

Traditional DOF techniques are based on depth data for processing. However, alpha-blended objects lack depth information, which makes them challenging to handle. Even if depth is output using alpha test depth pass, edge transition issues still arise, especially with alpha-blended effects, which are completely unmanageable.

Let me explain the entire processing procedure:

Create a ScreenSpaceBlurPass and run it before performing post-processing.
Write the related Dual-Kaswase Blur Shader.
Use UV (0.5, 0.0) as the center point to calculate the blur ratio based on screen distance.
If a Mask texture is used, apply the Mask data directly.

Since depth data is not used and only screen UV distance data is applied, it supports alpha-blended objects.

The related videos are as follows:

You can find it here:

GodViewFakeDOF

An Overview of SpriteRendererNAV

2025-05-12T13:38:00.002+08:00

The motivation behind developing SpriteRendererNAV stemmed from the desire to recreate the NAVMesh pathfinding tool, originally developed for a 2D scene editor in Cocos2d-X, within Unity. Additionally, users have expressed the need for a quick development tool that includes pathfinding functionality for 2D scenes, but they do not want to use the traditional A* algorithm, as it often creates a grid-like appearance unless the grid is made extremely fine, which can severely impact performance. As a result, I embarked on the development of the SpriteRendererNAV asset.

The related videos for the custom Cocos2d-x scene editor:

The entire process is not very complicated. The following are the steps involved:

Add the World quad mesh to MeshBuildSources.
Create Mesh colliders for all SpriteRenderers.
Use Physics.BoxCast to scan all Colliders in the scene and generate the corresponding block line data.
Based on the block line data, create a block line mesh and add it to MeshBuildSources.
Create NavMeshData, use NavMeshBuilder.UpdateNavMeshData, and pass in MeshBuildSources.
Finally, add the generated NavMeshData to the NavMesh.

For pathfinding testing, the PathCalculator script is provided to directly call NavMesh.CalculatePath and add NavMeshObstacle (Dynamic Obstacle) for pathfinding tests.

The related videos：

You can find it here:

SpriteRendererNAV

The Solution to Excessive Terrain Mesh Data

2025-05-12T13:31:00.000+08:00

When dealing with Terrain, tools typically offer deformation capabilities, allowing users to adjust its undulations. However, these functionalities often limit adjustments to height alone, constraining the representation of the terrain. Consequently, this can lead to texture stretching issues. Therefore, to address these issues, people often need to add additional terrain features. However, doing so may introduce transition problems at the boundaries between the Terrain and the added features.

When dealing with rivers or lakes, terrain tools are typically used to excavate the water bodies. However, if we focus on the details of their edges, it is often necessary to provide additional shoreline meshes for processing. This can also result in transition issues at the boundaries between the terrain and the water bodies.

Since the current designs are all based on mobile platforms, with a predominant top-down perspective, the terrain essentially appears flat. Hence, the idea arose to use mountains and riverbeds to create variations in elevation. The biggest remaining challenge then becomes how to handle the transitions at the edges effectively.

Furthermore, for mobile platforms, a large amount of grid data can potentially lead to performance issues. Through the aforementioned approach, we can address this problem. Essentially, the terrain is treated as a quad, with higher grid data only applied to mountains and riverbeds within the visible range.

Another common issue with Terrain is the repetitive tiling of textures. All the aforementioned related problems have been addressed in FastScene, where you can find solutions to them.

FastScene