🔒 EXCLUSIVE: App/ - Complete Album!

I've gotten quite a few questions on my instagram[www.instagram.com] about the foliage system recently, and as it is a big part of making the jungle really feel like a jungle, I figured I'd write about it in some more detail.

So first up, it's important to understand that all the foliage is instanced. This means the CPU submits a single draw call to the GPU for many instances to be rasterized on screen. This is standard in basically every game with foliage, and allows many many many instances of grass in a big open world game to become visible when you're in range (typically controlled in graphics settings).

Given that I'm using UE5’s Lumen and Nanite systems, most foliage is authored with fully opaque materials, with the exception of geometrically complex plants like ferns. The objective is to minimize overdraw, which occurs when the renderer cannot efficiently reject fragments from plants that are partially or fully occluded by other geometry.

Here is an extreme example of what happens when you don't properly optimize materials for Nanite, from UE's website (orange/yellow is overdraw, blue/purple is good culling):

And here is a look at a denser section in my game, also note that the hotspots mostly appear on the ferns which intentionally aren't using an opaque shader:

Most modern games still rely on masked materials with opacity maps for foliage, however, masked shading usually increases overdraw and can negatively impact performance, particularly in dense scenes, like a prehistoric jungle. My choice to focus on opaque materials improves lighting performance under Lumen, but also supports the artistic goal of achieving extreme foliage density, allowing the jungle to read as overgrown and dense without incurring the typical transparency-related performance penalties.

But also, that mostly doesn't matter lol. People seem to obsess over minimizing overdraw, but it's rarely the culprit of bad performance. Almost always, shadows are the problem. 

Typically, shadows for objects are calculated once, then cached in memory so they can be used again efficiently. But, foliage tends to move in the wind, meaning the shadows have to be recalculated constantly. So to minimize this cost, foliage typically has wind animation up close, but not farther away, so at least the distant shadows can stay cached. Sometimes however, when a plant transitions from wind to no-wind at range, there can be an unpleasant visible hitch where the plant snaps into it's static no-wind position, an issue I have fixed in the shader by slowly fading the wind animation away as we move farther from the plant, which is what this section in the shader helps calculate:

The wind animation for all plants is done entirely in the shader, so its very performant. This is mostly standard practice for foliage nowadays, but most of the time the animation itself ends up looking jank and wobbly, like the plant is underwater or something. So, I did a bunch of research into vertex colors and spherical re-projections to simulate the swaying and bending motion of individual plants, which makes the wind animation look really, really cool (you can see some of that here[www.instagram.com]).

So the vertex colors of each plant in Silicon Gate tend to look like this:

Each frond of the plant gets a slightly different shade of blue, which is used to offset the overall swaying animation per frond. Then a gradient of red is applied to the overall plant to control where the swaying animation is allowed to play (i.e. no red at the base means the base of the plant will stay still). Then a gradient of green is applied to the tips of the leaves, which controls where the fluttering wind effect is applied for some added flare. Combining these colors together gives the above image, which looks pretty cool.

And the latest and coolest part of the foliage system is being able to actually bump into and interact with the plants (check that out here[www.instagram.com])!

I've tried a bunch of different ways of doing this, but the one that looks the best is the rigid body simulation that I'm currently using. Basically, a rigged version of each plant is authored, and the system swaps out nearby instances for these rigged versions, which have collision and physics simulations built in. The rigged versions all look something like this:

There are constraints between each capsule that are always trying to return the plant to it's "stable" position, kind of like little servos in a robot. By playing with the strength and damping coefficients of these constraints, you can create a natural looking bendiness when the capsules collide with the player, and get really clean looking foliage interaction! This is a more 'expensive' effect though, so you cant have this running on all plants at the same time, so I implement a management system that only swaps the nearby instances for their physics counterparts, then swaps them back at range, all seamlessly!

So that's a short overview of the features in my foliage setup right now, I definitely learned a whole lot while making everything, and hopefully you now know more about game foliage as well!

Btw, if you like these kind of updates, and want to see more just like them, you should join my mailing list![subscribepage.io]