TurboForest: Unity fast billboard forest rendering

Hi Aily, im just coming back onto this now its been developed further. It looks really nice but I am still unsure how the trees are placed?

I have a large terrain scene at the moment and it has many many trees that use unity's standard billboarding, the trees are placed using terrain composer and a "splat map" type image.

Can this be used in the same way? I would basically want to simply replace the the current billboard trees with your system, but being able to place the trees in the same way?

If this is the case ill buy the paid version.

Thanks

 

I'll try to make splatmaps (was thinking about it, someone else asked here this feature), but current have not free time to do it (busy on primary projects)

 

So. are you saying the paid for one is no longer supported? or this free one? It sounds like you are just uninterested in developing this at all right now. Would be good to know. Cheers.

 

Paid is supported, current upating it to Unity5 compatibility.

 

cool. thanks

 

Hi to all. I have some news here....
Today i looked close on built-in Unity trees.
They are renders sprites very clever. Clever than i'm do it
Before render scene single tree renders by ortho camera form such angle as main camera is.
direct to sprite texture buffer.
On this step sprite have ready attenuated tree texture (from scene directional light)
Next render scene.
I combined this technique with turboforest scripts, and get this:
DEMO
I think this technique looks better than my TF texture lookups. And need to move TF on this render type.
What do you thinking about it?

 

And so
Default terrain with same trees and billboards only renders 20-30% slower (compared without shadows)
So TF will have features in the end:

1. Distribute above meshes using model tree area (not terrain)
2. Billboards shadows
3. 20-30% faster than default terrain trees.
4. Possible to use any models, without precompile atlases.

 

Is it possible to have both methods (old and new) available in TF, at least for a while?

I bought another asset where the author had a method that worked, and then he came up with another totally different method and said he was going to publish with both old and new methods, but he didn't ... he went with the new one only. And while the new way of doing it has its advantages, it has problems that the other method didn't have (like it won't work on mobile) and it has been a year and people using mobile still can't get his new method to work and the old one is no longer around.

So, while it sounds great to have the ability to use Unity trees ... I'd like to have the old version of TF around for at least a while in addition to the new one so we can see if there are cases in which we'd rather be using the old version.

 

Ok, both methods will be.

I not get it, you say version from asset store not works on mobile?

 

Another asset. Not yours.

 

Glad to hear both old and new methods will be in TF.

I was using the example of what happened with a different asset in the store, where the creator made a big change and didn't keep the old method available. His old method worked on mobile but the new one still does not, and it's a problem for some people who bought his asset.

 

Sorry guys for so long update version from assetstore But your wishes realy not simple to implement. And so TF realy need new attenuation system. Working now at all of this stuff.
Current added feature to render atlases from Editor

 

New attenuation system based on atlas generator normals

 

10k trees covering 768m2







would be nice to set trunks to be "taller" or the foliage to be "higher".

nice system.

here is why it would be nice to have some taller trees



many thanks

it does look nice though used as a ground floor tree system

 

oh, please look here http://forum.unity3d.com/threads/terrain-culling-and-colliders-is-hosed.310594/#post-2061321 for details of a dynamic collision system made by @snacktime and here https://gist.github.com/twobob/f7b34a4b404a9cee44da for an implementation of it with particle trees.



This can easily fit your system (without the particles) and would be good up to about 2000 (to 5000) nearby trees, switching about 30 colliders
A very simple extension of this same technology could easily do a "larger" grid, so as to encompass all your 100,000 trees in units of - say - 20*5000 or 50*2000. A 100'000 tree managing real-time performant collider system is almost as worthwhile as your shader.

It would need reworking a little to be completely Heap Allocation garbage free if you wanted to do such large numbers. Not a major job but hash collection enumeration thoughts are in order.

Just a thought.

 

Yep, it was designe to render forest fast as possible with accepteble look from bird fly height (one of my archviz project has scene with 20x20km area with 70% of forest)

I think you have vsync enabled, FPS must be much more.

 

no. it really is that. There was also 5000 particle trees in that shot.

It's the shadows that kill it close up, there is no getting around that.

It ran 100000k - tiny - trees just fine.

But they were tiny. That is full size trees, I was actually very impressed by the performance, it out-performed what I had been working on all day by about an order of magnitude

I wasn't complaining, I was congratulating you
The scale of 9 and shadows brings it down to that speed. I was going to work on dynamically placed blob shadows at some point. Something cheap

 

any clues how to get more trees that are tall? and less of the brown ones?

like this one:

I am trying to dial back the detail to get the

Used Assets, sorted by uncompressed size:
85.3 mb 58.4% Assets/TurboForest/tfTrees_dot3.png
21.3 mb 14.6% Assets/TurboForest/tfTrees.png

down in size on the builds

So less leaf - more trunk would be great.
It occur to me I haven't said that I will be buying your new U5 ready system, I will assuming it works like it appears to.



great stuff, saved me another job

The reason I ask is when I try to scale down the texture sheets I get large white surrounds



I posted a demo of this here (It just walks on its own, you can see the white borders)
this is crunching the detail down to 1024.

http://kaycare.co.uk/games/Inventory/

I suppose I had better get out my bosses wallet and "motivate" you

 

In TurboForest.cs find 252 line

there have part

float r=Random.value;
if(r>.25f) type=1;
if(r>.5f) type=2;
if(r>.75f) type=3;

so type here is one of 4 trees

if you write:

float r=Random.value;
if(r>.5f) type=1;
if(r>.7f) type=2;
if(r>.9f) type=3;

first tree in texture will apear more often

and so set type=0 - only first tree in texture will drawn

 

Paid version have separate trees atlases and you can control wich trees apears often just in editor.

 

Thanks very much! I shoved up a demo so you can check the FPS and texture edging, built it with debugging for profiler.

Bedtime

 

Cool. I will just grab that mate. I don't begrudge a man his money when he has done the work.

 

It's known bug with texture edges, Unity5 shadow system makes hidden pass to render this holes, i've solved it only when separate shadow meshes from main diffuse meshes, i.e. each TF chunk now have 2 meshes - diffuse and shadow. Just can't fix it only by shader, this "shadow halo" pass is hidden somhere very deep

Anyway, better to buy paid version, it costs almost nothing for commercial project and havee support from me to fix such bugs.

 

Is purchased, was too "early morning" to do it before.

minor adjustments

\Assets\TurboForest\Scripts\TurboForest.cs

Code (csharp):

1. public UnityEngine.Rendering.ShadowCastingMode castShadows;
2. //public bool castShadows = true;
3. //....
4. // (snipped)
5. //....
6. // mr.castShadows = castShadows;
7. mr.shadowCastingMode = castShadows;

to give us





Your gizmo does not account for GameObject offset

so:
Gizmos.DrawWireCube(gameObject.transform.position + center, size);

or
Vector3 __offset = gameObject.transform.position;
Gizmos.DrawWireCube(new Vector3(__offset.x,0,__offset.z) + center, size);

to make




be like:



I will go check the supporting code to see if this needs propagating down.


Finally, I see no option for "Mass Dump Trees in zone without Mesh" so I will be adding one.

 

Thanks for the info

 

This not make sense no more, shadow casters reworked to separate models.

Will check it, forest not supposed to be moved

You can create plane of tree area size and use it as trees distributor. (disable it renderer)

 

also, as not all meshes are authored with a central pivot.

it is better to either a) manually allow the user to fix the pivot offset, and reflect this in the gizmos.
or b) work it out automatically from the Bounds (as you know)

I have gone with a)

Code (csharp):

1. public Vector3 MeshPivotOffset = Vector3.zero;
2. public static Vector3 __MeshPivotOffset;
3.  
4. public void Generate()
5. {
6.  // pass our local stuff to the static, for the helpers.
7.  __MeshPivotOffset = MeshPivotOffset;
8. //...
9. // (snip)
10. //...
11. void OnDrawGizmos()
12. {
13. Vector3 size = Vector3.one;
14. size.x = chunkSize;
15. size.z = size.x;
16.  
17. Vector3 center = Vector3.zero;
18. center.x = chunkSize / 2;
19. center.z = center.x;
20.  
21.  Vector3 __offset = gameObject.transform.position;
22.  Gizmos.DrawWireCube(new Vector3(__offset.x, 0, __offset.z) + center - MeshPivotOffset, size);
23.  
24. // or just
25. //  Gizmos.DrawWireCube(gameObject.transform.position + center - MeshPivotOffset, size);
26.  
27. }
28. //...
29. // (snip)
30. //...
31. public void SetMeshFrom(GameObject gameObject)
32. {
33. //...
34. // (snip)
35. //...
36.  
37. for (int i = 0; i < verts.Length; i++)
38. {
39.  // add in the static offset
40.  verts[i] = gameObject.transform.TransformPoint(verts[i] + __MeshPivotOffset);
41. }
42. }

That should cover most "offset" use-cases. I think.





Hope it helps.

 

Ah thanks So... it should just be removed?​

errr. why? Anyway, now it can be.​

Yes I suppose I could. However making everything use "meshes" is a cool idea and works great but since you already have the data for the gizmo location? why would you want to?

as you can see I have 9 meshes that make a grid. better to just outline with the gizmo and WHAM.

"Fill Gizmo Area" , I'll just add one of those.​

thanks

 

I am very happy with the performance



Excellent job on that

Little niggles about "What is the easiest way to do things" aside; I would certainly recommend this system to anyone.

With the right render path (forward) and a little care for the numbers and sizes you can get incredible results for a billboard system. Very impressed. nice one

works okay at 1024 res now in forward path



That 163 batch count includes hundreds of generated in-world objects, buildings, models, skybox, terrain. really very happy. The shadows seem to be much faster now. 150 fps speeds



Also. about Gizmo Vs Mesh. It seems like generating a simple (double sided maybe) Quad to fit the gizmo space would make everyone happy. Just save the generated quad to a prefab, Happy days

Cheers

 

I think this looks great



I didn't get a great frame rate, and the trees seemed to not draw over the horizon.

But I loved the detail!! and this would be great to render small plants for multi layer forests
where you have a few big trees and 50,000 little plants



Which is more realistic



And makes separating out those 500 big trees much easier for "location tracking" purposes.

Is there any chance of you storing the Vector3's of all the generated trees in a certain forest?
Like in a ScriptableObject?

This would be very helpful to attach dynamic colliders to for the big trees.

 

Yesterday i've added drawing trees manualy just from Editor, very basic - one tree per click. This requires to store all trees in serialized data. So you get your wish about it soon
Now scene have instance of TFroot, which stores in children all sprite chunks and all trees data in self public list.

you will able to acess it simple

foreach(var t in TurboForestRoot.instance.trees)
Debug.Log(t.position);

And both techniques now working well.

I hope today will finish it - make help docks and upload to store.

 

Helpful:






fun!

 

That is excellent.

I would just add that it is very important we can use [] indices and not just foreach.
I would never use foreach for anything, unless it was the only enumerator available.

Zero garbage is most important to me.

many thanks.

 

Yep, it's simple List<>.

I think all this "zero garbage optimizations" loose sense if you have just one animated skinned mesh in scene.

Last year i'm worked on big RTS project, with 5 programmers team. Project so big, where we just can't use [] each time. Just hav'nt time for this, loops are everywhere

More than that almost always we using Linq and constructions like:

....units.where(u=>u!=null && u.side=Side.friend && !u.isDead).Select(u.Damage);

And when game running scripts is a drop in the ocean - almost all speed eats by render, navigation and skinned meshes.

Just want to say that Unity's scripts are very fast and GC work not so crytical.

 

Hi.

My background is .net Compact Framework and tiny devices.

Spoiler

Where Linq and enumerator and even string garbage can make your game freeze.
I have one Windows 8 tablet - brand new - that insists on hanging if you have even a reasonable trickle of garbage.

I recognise that the majority of users don't care about garbage since the details of it are hidden from them by decent garbage collection.

I do not have this luxury. I don't target PC's and when I do they are the slowest - most useless PC's - you have ever seen.

The game I pictured above generates out almost zero garbage - and I mean ZERO - and will run on /any/ platform because I took the time to make sure it would. Months. removing every tiny little scrap of junk.

GC is critical to little platforms. Exactly the type of place your system is needed the most.

As for skinned meshes: http://kaycare.co.uk/games/fin/ <-- 500 running no problem in a webplayer.
We have solved that problem with baked models and then worked with http://u3d.as/content/orbcreation/simple-lod/agW this author to create the absolute tiniest versions of things.

Navigation https://www.assetstore.unity3d.com/en/#!/content/26648 <-- we worked with this author to make this garbage free and incredibly fast/ low resource.

You can see from that stats on that km2 of world that we now generate out huge slices of terrain for a few triangles.

Optimisation is /absolutely/ critical to us, and your other users here, @hopeful for example I would say also understands the importance of zero garbage on tiny platforms.

I could bore you with a huge list of tools like that, that we worked on over the last few months to make the toolset perfect.

but this is that thing running (with 4 skinned meshes in frame)



Very clean. I just want to keep it that way.

Hey, I have booted Windows 95 on a Kindle Touch, there is very little that can't be done with enough effort and care to detail.

You have a great system here, just trying to polish the edges

Most of this won't actually matter - since your system is now "before game-time" and the forest tree list is a List<> as you say

Thanks

 

I have actually managed to get together a working dynamic collision system
using the info on this page http://buchhofer.com/2010/10/unity-toying-with-scriptable-objects/ to make the list
and https://gist.github.com/twobob/c6e6c3f9a6b4f3b7eefb to track it
works relatively nicely. bit slow at the moment to make the original list

Very excited to see what you have come up with for the storage, my way was a bit slow on larger numbers.







I might try authoring some multi perspective foliage...

and my current way is probably very inefficient

but it feels good to have those Dynamic NavMeshObstacles popping in and out

 

TurboForest.cs would need

#if UNITY_EDITOR
using UnityEditor;
#endif

when building for a web target as far as I can tell

 

in editor

Code (CSharp):

1.         GUILayout.BeginVertical();
2.  
3.         if (GUILayout.Button("ClearDown"))
4.         {
5.             tf.Remove();
6.         }
7.  
8.         GUILayout.EndVertical();

in TurboForest

Code (CSharp):

1. public void Remove()
2. {
3. while (GetComponentInChildren<TurboForestChunk>())
4. {
5. TurboForestChunk chunk = GetComponentInChildren<TurboForestChunk>();
6. DestroyImmediate(chunk.gameObject, true);
7. }
8. }

helps to iterate faster over tree designs. Clears down previous chunks for that one forest

Cheers

 

Just a few comments on all of this ...

First, I'd like to say that Aily is doing a great job with TF, making it look good and be ultra efficient, and I have confidence in him.

Naturally, everyone wants low - preferably zero - GC in every part of their game. Well-designed code is careful about garbage. A little garbage here or there won't make any difference, but you try to follow best practices and make sure it's not the kind of thing that would ever add up to steal performance in some scenario.

I think twobob is giving good feedback on TF that reflects his use of it in his game, on a mobile platform, and that's very valuable.

While I was originally drawn to TF for the aerial view use - where the imagery and efficiency are wonderful - it's clear there's enough quality in the tree sprites to use them closer. A few people have posted about that. In my game I would have urban and lightly forested areas that players can see but can't enter into, and TF would be great to use for trees that are nearby but outside the play zone. Like others have done, I'll probably use SpeedTrees or something else for up-close tree models.

I also have Terrain Composer. I haven't used it yet, but since I don't have a completely open world, my plan has been to use TC for the terrain and close-up wilderness, and TF (in the original aerial mode, or mode1) for the far-away woods. With the changes currently underway with TF that may expand its use in the mid-range (tree creator mode, or mode2), it's looking like almost all of my terrain will likely be masked off in TC for use by TF.

 

Thank you guys for you feedback, realy want to work on TF when see that people are realy need this
Some news:
Editing mode aded:
Place single trees, circle area and line\rect area with density.
Cylindrical render mode for billboards added (it prevent billboards from turning by X) - ideal for first person view.
In first person view new attenuation system is realy cool.


Cylindrical mode is:

 

First person with cylindrical mode demo
All tests were maked with 1 Unity unit = 1 meter.
So here character height 1.8 m
Trees height ~15 m
I think it close to real life parameters

 

Aily - Looks awesome.... Just bought TF the other day....

 

Just wait a little, all TF buyers will get this updates for free.
And little surprise, because after update i will increase it cost.

 

There's a little flickering in the foliage in the new demo, and it happens when two trees are close to each other and they "fight" to see which one gets displayed on top of the other as they spin around.

They don't constantly fight, but they will swap the top spot as I pan the camera back and forth.

A simple solution is to know the tree radius and avoid placing any other tree within that radius. (Or, rather, don't let the two trees be close enough to intersect.)

 

Now TF can grab data from terrains (as someone asked here)
You can see infront builtin Unity trees.

 

Super solid 60 fps. very impressive.

and now terrain.terrainData.treeInstances makes a nice addition to the packages parsing power.

Is that shot above without any extra batching?

Top job.

 

Don't realy get what you means. Here's terrain with ~20 000 trees + 20 000 TF trees. It's 2x2km, and TF chunk size set to 1km, i.e 8 TF chunks(draw calls) - 4 for diffuse and 4 for shadows.

TF trees are drawing as usual, just culling it by near clip distance - 500m in shader.
And terrain trees drawing set far clip to 500m.

Looks like TF on that screenshots is like a far LOD for terrain trees.

Yeah, anyone now can make self DayZ with Unity

 

Just as a note ... in my game players will move in 3D - in the air, not just on level ground - so that's part of why I want to keep the good aerial views of models.

 

@hopeful I have put in a top down / First person switcher on my tests just to make testing that easy.
I checked out the z-fighting, and it is as you say - avoidable with correct radius. It existed in the previous implementation
btw

it says 544 draw calls. That is why I asked. thanks