(Article) Our Foliage System for Unity

Community Showcases
1

As everyone knows, Unity’s terrain / foliage system isn’t exactly modern. Hence, I’ve been doing everything I can to avoid the horrors of these systems. The first step in that direction was to build my own foliage system.

1082×613 864 KB

Full Explanation: https://www.ardenfall.com/2018/05/16/our-foliage-system-for-unity/

Enjoy, and tell me what yall think! I’m wondering if this project is worth sharing? As I mention in the blog post, doing so would mean some redesigning (since my game uses a special cell loading system) and such. Would anyone end up using it?

Josh

2 Likes
2

I actually find the cell loading system even more interesting, so I wouldn’t mind if it’s part of the foliage system. Even better though, if you would share this as a separate project. :slight_smile:

1 Like
3

I was thinking about that! Sadly it’s a bit messy, but it’s taken a LOT of work to design and I would love to make it so others could use it as well, might as well right?

At the very least I’ll be making an article on the design structure of the cell system, as well as another article on the save system. :slight_smile: It’s actually very cool how it works, I am very proud of it xD

1 Like
4

Actually, for what you show in your image, I think unity’s terrain system would render the scene at or above the refresh rate of most monitors and “be just fine”.

The problem

I think the problem people have with unity’s terrain system is that when they try to set the far clipping plane of the camera to 8k meters and then have 125,000 high resolution trees, 50,000 high resolution bushes, 35,000 high resolution rocks, 65,000 high resolution flowers, 1 million blades of grass, all with realtime lighting and shadows in a huge open world environment they become disappointed.

Also, this “Open World” problem is not a systemic problem with unity. (Think of all the places where you do not use a terrain)… Even though your solution treats it as such.

Your solution

You have essentially re-invented a scenegraph. I couldn’t find the exact data structure you are using, but a scenegraph is actually not the right solution to this problem. Evidenced by the fact that you are having to hack things like shadows.

A better solution would be to reframe the problem as a distance problem (using something like a kd-tree). In other words, “show me the closest 500 trees, show me the closest 100 bushes, show me the closest 200 clumps of grass”. That would scale to millions of yet to be instanced objects… and then your fancy pooling, culling, lod and imposter systems could go to work.

Again, don’t think of this as a generic solution for fixing unity. There is no problem with unity. This is a way to address the “Open World” problem discussed above.

Why am I posting this?

Software development (with other people) is about sharing ideas. You asked for my opinion about a piece of technology and I gave it. It is nothing personal and I think that you are a good person.

My particular experience with unity has led me to these conclusions.

Your mileage may very.

Thanks!
:slight_smile:
Brian

5

Ironically the reason I started working on this was because Unity didn’t support flat shaded trees on their foliage system :^) And now I’ve switched to non flat shaded leaves… oops…

However, from what I could gather, Unity doesn’t instance trees. This results in a very high batch count… for the same number of trees (Around 600, quite dense though), Unity’s foliage used 2k batches and mine used 30. I know these days batches are less important (since modern GPU’s are pretty fantastic), but still.

And yeah I’ve decided the terrain system is going to stay in my game, now that Unity is going to implement multiple terrain painting this year… (huzzah!)

I was originally using a Quadtree to store foliage data, but I quickly grew to realize that having such a fine level of detail is very much unneeded: hence, tiles (what I call chunks) and subtiles. The game already has a list of tiles that is near the player (since this is built into my world loading system), so all the code needs to do is find the nearest subtiles, and then cull if wanted.
How would finding the nearest 100 bushes help? I’m a bit confused by that. I’ve never heard of a game that renders by the number of objects to render, rather than a render distance… Either way, wouldn’t finding those 100 bushes be even slower than the tile system?

The shadow hack is simply due to the culling (since I don’t know how I would cull a shadow), nothing to do with the initial grab of what stuff to render.

Is this implying there are no systems that make Unity work better? Of course this system I built is specifically for me, just as Unity’s systems are specifically for whatever types of games they envisioned. (Naturally every system has its limits). But I guess I should have been more clear that this system is better for my game specifically.

Don’t worry, I’m not offended :slight_smile: Talking about stuff is great, and it’s easy to fall into a hole of technology and fancyness when it is unneeded. For me I get very excited about systems, and very often jump at the chance to make them, even when doing so is unneeded and a waste of time.

1 Like
6

You are still thinking in terms of how your current system works. What I proposed is that you throw your current system away and replace it with a system based on purely distance. (Research the difference between a quad or oct tree based scenegraph and a data structure such as a KD-Tree)

In such a system you would store the name of each tree, bush, rock, and flower along with its position in 3d space into a specialized data structure (such as a KD-Tree) that is optimized to return range queries. Then at runtime you would ask it for the nearest 1000 (for example) objects to your players position. These would be the objects that you instantiate (pool) and then display.

No, I am trying to say that I want you to focus on the “Open World” problem and not on trying to fix all of unity. Because I don’t think that all of unity has a problem. For example, create a dungeon runner game. You will not have this “Open World” problem.

Cheers!
:slight_smile:
Brian

7

I’m honestly a bit unsure about that. At one time, there are 9 chunks loaded at once. Since data is stored within these chunks, technically that means an instant grab off all foliage that’s going to be rendered. The engine also calculate distance per subchunk (my game uses 6x6). What this means is the ultimate maximum number of calculations needed is (9*36+9) distance checks. (This doesn’t change depending on the number foliage) This sounds like a lot, but it is required by the LOD system anyways. (Lod calculation is done per subchunk, rather than per instance) And that’s it.

In my eyes, since I need to calculate LODS (especially for billboards) having a kd tree wouldn’t achieve anything. There would need to be a search, and then distance checks would still need to be issued for LOD… This time, since there is no grouping system, for each instance. I don’t think there is any way that this would be a faster direction to go.

Assuming your system would calculate the distance per instance, under my absolute worse case scenario (a single instance in every subtile, 324 instances total), my system would use 333 distance checks, and yours would use a kdtree search as well as 324 distance checks. If we then added 8000 trees, then mine would still use 333 distance checks, yours 8000 distance checks. And so on.

And I never said I’m fixing unity. I am saying in my opinion that the foliage system in Unity is very out of date, especially because it doesn’t instance anything. Hence, my foliage system. And others too, on the asset store.

1 Like