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…
11. Other Assets
沒有留言:
張貼留言