Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Critias Tree System [Asset Store]

Discussion in 'Works In Progress - Archive' started by Assembler-Maze, Oct 21, 2016.

  1. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    CritiasTree.png

    ! UPDATE !

    For those interested in a complete grass/tree, easy to setup system based on this tree and the grass system check out 'Critias Foliage System'.

    A big Unity issue is the lack of a decent tree system. Developing an open world game I had to solve it. Therefore my goal was a tree system that makes SpeedTrees usable.

    ! VIDEO TUTORIAL !
    You can see a step-by-step setup video tutorial here and here.

    ! DEMO + SOURCE !
    Download the demo here. The complete open-source demo project can be found here.

    ! ASSET STORE !
    You can find the asset store version here.

    ! Version 0.9.5 Beta !

    Features:
    - Ability to automatically add 'LODGroups' to batched tree billboards

    Upgrades:

    - Optimized tree matrix copy
    - Optimized cell managing visibility/distance checking

    ! Version 0.9.2 Beta !

    Fixes:
    - Y Terrain Offset Fix
    - Tree shadow popping issue

    Features:
    - Support for 100k+ tress with collisions
    - Painting trees on non-terrains
    - Being able to completely remove the terrain after editing the trees
    - Support for multiple tree types
    - SpeedTree XML files NOT required
    - CullingGroup API for cells
    - Instancing support
    - Tillable terrain support
    - Billboard rotation
    - Tree Y rotation
    - Tree wind
    - LOD System
    - Animated SpeedTree style CrossFade
    - Only SpeedTree supported
    - Uber-fast billboard system with 400+ FPS at 200k+ trees

    Research:

    - Grid subdivisions for faster 'distance' & 'AABB testing
    - Billboard wind animation
    - Billboard color variation
    - Adding support for non SpeedTree objects
    - Uneven terrain sizes like 3600x3900
    - Store/restore the trees from the managed terrains

    Implementation details:

    Tree mesh data counts for 3 LOD levels: 8000/6000/3000 8000/6000/3000 tris with uv/uv2/uv3/uv4/colors, just like SpeedTree.
    Tree count: 300000 - Again, like the grass, it doesn't matter. Only the trees around the player do
    Terrain size: 10km x 10km
    Big cell size: 2000 meters, 5 cells in length, 25 total cells

    Before going into the system I will explain, in general, how it works. First we know that we can have a tree in two states. One is the 3D state and the other is the 2D state, a.k.a a billboard. We want to do 'something' that we can draw hundreds of thousands of billboard trees at hundreds of FPS. We know that Unity's system is slow due to the fact that is batches 2D tree billboards at run-time. We want to get very very far from that approach. Another point that makes Unity slow is that having many trees as 'objects'. So we see that even is you have 100k INVISIBLE trees it still goes slow. That is due to the fact that there is some kind of processing for each extra tree instance. We also want to get very far away from that.

    So, the main ideas are:
    - Build the 2D trees mesh at edit time. They will have each packed in the meshes extra UV channels all the instance data: world position, world rotation, world scale. The shader will also receive some extra billboard data retrieved from the 'BillboardAsset' item. Calculate all the world data in the vertex shader. Vertical billboards are supported with this approach.
    - Invsibile 2D instances in the vertex shader when we get very close to the player so that we don't have to regenerate the mesh data on the CPU

    Some shader code:
    Code (CSharp):
    1.  
    2. float3 campos = _WorldSpaceCameraPos;
    3. float3 pos = IN.texcoord1.xyz;
    4.  
    5. float dist = distance(pos, campos);
    6.  
    7. if (dist >= DISTANCE)
    8. { // Compute world positions }
    9. else
    10. { // Do nothing, so that the billboard is invisible }
    11.  
    All those are generated at edit-time and are uber-fast at run-time. 100k billboard trees are rendered at 300+ FPS when all of them are billboards. And horizontal billboards are also supported.

    - Store all tree instance data so that when a tree is visible render it properly
    - Hold per-instance tree data in order to be able to calculate on the CPU the LOD level, when it has to become a billboard etc... Was required in order not to loose ANY of the SpeedTree's transition quality
    - Have the transitions animated
    - Extract the billboard data from the SpeedTree xml. For more details on that, I have received an special 'exe' from the SpeedTree guys so that when a model is saved also an 'xml' representation of the billboard's UV's and data is saved so that I can extract it and pass it to the shader (this part can be skipped, if we don't have the XML)

    Now that the main ideas are sorted out, let's get started!

    Take one terrain and divide it into large cells, creating a grid:
    TreeOverviewGrids.png
    (10x10km terrain divided into cells)

    See all the instances that are in the grid and build the offline-mesh that I have talked about. After that grab the structured cells that contain the trees it and store it for runtime use.
    At runtime we:
    - See in what cell we are and grab the surrounding cells (refer to the grass system)
    - Iterate the cells and see if they are within 3D model draw distance
    Code (CSharp):
    1.  
    2. for (int cell = 0; cell < m_Cells.Length; cell++)
    3. {
    4.     StructuredTrees str = m_Cells[cell];
    5.  
    6.       if(Vector3.Distance(pos, str.m_Bounds.center) < cellDist && GeometryUtility.TestPlanesAABB(planes,    str.m_Bounds))
    7.      {
    8.             // Perform with drawing the instances within the cell
    9.      }
    10. {
    11.  
    - If a cell is within distance see if it is completely or only partly in frustum. If it is completely in the frustum we can send all the trees in it to the rendering pipeline, else we need to test each tree's AABB against the frustum. The tree's AABB is generated offline
    Code (CSharp):
    1.  
    2. // If the cell is completely inside the frustum
    3. bool insideFrustum = IsCompletelyInsideFrustum(ref planes, BoundsCorners(ref m_Bounds, ref m_TempCorners));
    4.  
    5. if(insideFrustum) // Send the tree straight to rendering
    6.     if (distToTree <= system.m_Settings.m_MaxTreeDistance)
    7. else // Send the tree to rendering only if it is in the frustum
    8.     if (distToTree <= system.m_Settings.m_MaxTreeDistance && GeometryUtility.TestPlanesAABB(planes, bounds[treeIndex]))
    9.  
    - Not only that we send the tree down to rendering but we will also update it's LOD state for cool transitions
    - Last thing we need to take care of is a smooth animated transition between the 3D tree and the 2D billboard. We do that by having one more intermediary 2D billboard between the 3D model and the 2D offline-batched billboards. When the 3D model is close on becoming a 2D billboard we draw an animated intermediary 2D billboard. During that transition we need to send two models for rendering per tree. After a certain distance that 2D billboard dissapears and the manually batched billboard remains behind it, but without having the user noticing it. Having that makes practically almost absolutely no difference between the SpeedTree trees and our system (except the awesome performance, of course)

    Some other things that needed taking care of were the modification of the SpeedTree stock shader so that we can manually cross-fade between the trees.

    Result:
    Forest2.png
    (60FPS 200k+ trees, four types)

    Bushes.png
    (70FPS, 200k+ trees, going crazy with bush density. But, please, keep in mind, this is not a grass system)

    Trees_V2.png
    (420 FPS 250k trees, with four tree types, all billboards)

    NOTE: This system is not designed for grass. You might wish to check the grass system, designed for millions of instances.
     
    Last edited: Sep 15, 2017
  2. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    ! MAJOR UPDATE !

    With the last of issues fixed I would consider this system ready for some serious beta, maybe even production! Looking forward for the awesome things that you are going to create with it!

    ! UPDATE !

    I've also uploaded the package to the asset store, for faster importing and managing, for people who prefer that method. It can be found here.

    Forest1.png
     
    Last edited: Jan 24, 2017
    kurotatsu and jason-fisher like this.
  3. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    Fantastic. I need to read through your post in detail, but already I'm super interested. I have a SpeedTree license and would love to get improved performance. I am downloading the demo now and will check it out.
     
    Fushion2D likes this.
  4. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    The demo looks very nice. I have a couple of questions about the workflow. Do you place a bunch of trees using the Terrain editor and then some process converts them? Or are these trees placed individually on the terrain as objects? Also, I noticed that the trees didn't have colliders on them so I was able to run right through them. Obviously we don't want colliders on distant billboards, but definitely want them on up close trees. How does your system plan to handle that? Finally, does this have special requirements like DX11 computer shaders or anything like that?

    [EDIT]
    Also, what version of Unity is required for this and also your grass system?
     
    Last edited: Oct 21, 2016
    Fushion2D likes this.
  5. chingwa

    chingwa

    Joined:
    Dec 4, 2009
    Posts:
    3,789
    This looks very promising :)
     
  6. Hikiko66

    Hikiko66

    Joined:
    May 5, 2013
    Posts:
    1,304
    That's some decent performance gain.
    I need this -.-

    I've built a system to manage tree colliders before based on distance to player and it can be very efficient.
    Such a system would not slow this down. Mine wasn't even optimized and it was fast.
     
    jangomoose and Assembler-Maze like this.
  7. larsbertram1

    larsbertram1

    Joined:
    Oct 7, 2008
    Posts:
    6,893
    Assembler-Maze likes this.
  8. tcz8

    tcz8

    Joined:
    Aug 20, 2015
    Posts:
    504
    Tried the demo, looks promising. Good work!
     
  9. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Hey! Thanks for the encouragement.

    For the coliders, I just forgot to enable them when I made the build :)). Nothing to worry about. But at 100k trees they surely eat quite a lot of CPU, so we need to think at something so that we only enable the colliders for the trees around you. For example the system works great at 200k trees but the physics systems goes haywire and you pass through everything. So yea, it is a problem but for this demo I just forgot to enable the colliders :). When I'll make a demo with 500k trees I'll need to think at something very smart with the physics stuff.

    For editing/creating it's very very simple. Just use gaia or paint the trees, press a button and they are automatically gridified, created, that's all. No special editing, no individual trees as game objects (which is impossible for 100k objects anyway), all drawn with 'Grahpics.DrawMesh' (hoping for instancing in the future).

    No special requirements, dx9+, Unity 5.4+ for the trees (I think it should basically be 5+, it doesn't really use anything special at ALL, it's C# with a little bit of easy shader work).

    For the grass it's 5.5 with dx11 since it requires the 'DrawMeshInstanced' stuff. The grass can't live without that at decent performance. I'm sorry, but the grass is a different story and it looks very very very good. If one can live with more modest looking grass, can find some other solution if it targets dx9 but it won't look as good.

    Also keep in mind what you want to do with Unity. If you want to do a desktop title, make it PBR, make it look good and target DX11+ hardware, and stuff in the grass and trees.

    If you target mobile, I doubt my systems would help you much. They were not mobile-oriented, and I don't remember if mobiles can target SM 3.0 on older hardware. Having open-world mobile games with a lot of grass and trees sounds a little weird to me :)
     
    Last edited: Oct 22, 2016
  10. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    No, it's not heavily optimized, sorry :). Thanks for the tip, I really didn't knew what that sqrMag is used for . But it still goes a lot better that Unity's implementation without the smart optimizations and without c++ code :).

    One more thing I'll require help with is the choosing of billboards based on angle, since now is quite wrong. But I'll have to prepare one more post with some source code. Since the issue is quite extended.
     
    jimmikaelkael and AdamGoodrich like this.
  11. marcatore

    marcatore

    Joined:
    May 22, 2015
    Posts:
    160
    My...My...My..God!!! I've tested the demo..and it's fantastic..and very generous by you to release in the future this for everyone...Thanks in advance.
     
    jangomoose and jason-fisher like this.
  12. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    Actually I'm using Wii U which is SM 4.0, but not DX11 although it can convert most of DX11 to what it needs, but not compute shaders or SM 5.0 specific stuff. And I'm on Unity 5.3.6p2, but Unity 5.4 is coming soon for the Wii U. 5.5 will be quite a ways off though if at all.
     
  13. chingwa

    chingwa

    Joined:
    Dec 4, 2009
    Posts:
    3,789
    Unity have really dropped the ball on terrain in general and SpeedTree specifically... they certainly look beautiful but are completely impractical for a real game, so far! Have you tried your system using multiple tree types yet? I imagine you would still get a good performance boost, but I wonder how much this cuts into performance gains. Having support for 3 or 4 different types of trees (per terrain) is going to be mandatory for real-world use I think.

    Looking forward to your development!
     
  14. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Don't worry, the system must work with dozens(even hundreds) of tree types without any performance loss, so no worries there... That's part three of the development, I hope I can cook it next week.

    And for part four there's GPU instancing for trees on same LOD, that will also have a huge positive impact on performance.

    For part two that's the billboard choosing, I'm trying to update the project on github right now.
     
  15. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    No, no don't worry, it's DX9 (SM 3.0). It should work with any unity that is 5.0+.
     
  16. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Please, check out this post, and if anyone can help post here. Keep in mind, this is not for me only, it is for the whole community, so the faster we can fix this, the faster I can move on with making the system for multiple tree types and finally releasing it.
     
  17. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    To get the magnitude of a vector you need to get a square root. Those are computationally more expensive than additions or multiplications. I'm curious how much of a performance gain you can see though, sqrt should be pretty fast these days, too.
     
  18. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    @Assembler-Maze if you have some sort of beta test, I would like to test at earliest possible point. Since I need this for the Wii U it's always a bigger challenge to get something like this working. If this could work and work well on the Wii U then it could be the final piece of the puzzle to get my game back up to target frame rate.
     
    JamesArndt likes this.
  19. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    I will try to release this as soon as possible, in order to get the most of the feedback and to see how this scales in real-world solutions.

    That would be after I fix the support for multiple tree types. I hope that will be before the end of the week.
     
    Knightmore and magique like this.
  20. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    The performance improvement was good, but not enough due to the fact that the subtraction calls a vector's ctor. It is overkill for testing the ton of trees that might be visible. For 110k trees it took something like 20ms with 'Vector.Distance' and 17ms with 'sqrMagnitude'.

    Fastest way is:

    Code (csharp):
    1.  
    2. x = treePos.x - camPos.x;
    3. y = treePos.y - camPos.y;
    4. z = treePos.z - camPos.z;
    5.  
    6. float sqrDistToTree = x * x + y * y + z * z;
    7.  
    1-2MS for 110k trees.

    But there's also granularity improvements, for example we can further subdivide the big cells, into smaller subdivisions and we can test for those cells too, in order to exclude as many trees as possible. See the grass system as a reference.

    For example if we have 5 visible cells that's a staggering 20k trees that we have to test the 'distance' for. And out of those 20k, probably, many were taken into consideration only due to the fact that the big cell's center position is closer than our threshold. But that might as well mean that half of the cell's trees are out of range, and with further cell subdivisions we might quickly exclude those also.

    But we'll see that in practice, after I release the first beta, hopefully this week.
     
    Last edited: Oct 25, 2016
  21. Mark_T

    Mark_T

    Joined:
    Apr 25, 2011
    Posts:
    303
    Impressive tool you have there.
    Do I have to be a coder to be able to use it. I`m asking because my scripting skills are close to 0. :)
    And a second question. Does it works only with Speedtree? Are custom trees alowed. I`m thinking about something like this.
    And the last question. Can it be used for different objects?
    Sorry. One more. Does take into consideration the mesh instancing features coming with Unity 5.5? How will it be affected?
     
    Baldinoboy likes this.
  22. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    No, you don't need to be a coder, but since I will not sell this it will not be AAA support. If you won't use the defaults probs you'll need a coder around, sorry.

    No, custom trees are not allowed, it's made for SpeedTree only. But I guess it can be easily modified for other tree types that have lod/billboards. But I don't plan to do that.

    No, it can't be used with custom objects, that is going to be a 'terrain detail system' (see my game's thread if you're interested of further Unity improvements) and if you need grass check out my grass system.

    For instancing i'll quote myself:
    "Further research:
    - Grid subdivisions for faster 'distance' & 'AABB testing
    - Tree instancing"

    So, yea for optimal performance (now on a GTX970 250k trees,4 types is at around 100FPS+ but it can be better), instancing is mandatory.
     
    Knightmore likes this.
  23. Baldinoboy

    Baldinoboy

    Joined:
    Apr 14, 2012
    Posts:
    1,526
    Sorry, I am not a coder, but why will it be so specific for SpeedTree. The Custom Tree Importer imports the tree to almost the same UV2, UV3,UV4, and vertex colors. Even same billboarding system. Just a custom shader for the billboards. Does this tree system use the .speedtree file or whatever it is called to populate the terrain?
     
  24. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    It extracts the billboard data from the SpeedTree file, along with the LOD data, from the SpeedTree prefab. Mostly because the 'Treeifier' script uses the terrain and extract the data from the tree prefabs, and the shader is the SpeedTree one. I am uploading the project now on github, so you can see exactly how it works after the commit is finishes (will still take 1-2 hours I guess).

    But if AAA games out there managed to use everything SpeedTree from grass to trees, I didn't had from the beginning in mind any intention to make it work with something else. Of course, it can be modified but I will not do that since I don't have time.

    For all kind of objects, that will be for the detail system.
     
  25. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    The full pre-alfa project with source code is available! Check it out now!

    Just paint the trees around with the brush as you would normally do, or generate them however you would like and after that use the 'Treefier' script and push 'Generate Trees'! You have to hit 'Play' to see anything, since the shader data might not be updated until a play session.

    ! WARNING !

    Not intended for artist use :)
     
    chingwa, magique and Knightmore like this.
  26. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    I'm giving this a try right now. Hopefully, it'll work with Wii U and show improvements. I'll let you know.
     
  27. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    I'm getting the following errors on Unity 5.3.6p2:

    Assets/Code/Debug/DrawBillboard.cs(50,11): error CS1061: Type `UnityEngine.Material' does not contain a definition for `SetVectorArray' and no extension method `SetVectorArray' of type `UnityEngine.Material' could be found (are you missing a using directive or an assembly reference?)

    Assets/Standard Assets/Effects/TonemappingColorGrading/Editor/TonemappingColorGradingEditor.cs(247,56): error CS0117: `UnityEditor.TextureImporterType' does not contain a definition for `Default'

    [EDIT]
    Hold on. I had it set to Web Player. Going to switch and see if it fixes it.

    [EDIT 2]
    Nope. Same errors.

    [EDIT 3]
    Looks like SetVectorArray is in Unity 5.4, but not in 5.3. Standard Assets were probably from 5.4 as well.
     
    Last edited: Oct 25, 2016
  28. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    That's a bit of a surprise, but makes sense if unity actually returns a new vector for every substraction.
     
  29. brettj

    brettj

    Joined:
    Feb 9, 2015
    Posts:
    43
    Have you looked into CullingGroups? I'd be curious if they're faster.
     
  30. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    That seems to be a 5.4 feature only so I hope he doesn't use that or at least makes it optional and version dependent. I really need a good SpeedTree system for 5.3 and don't think I can afford to move to 5.4 even when it's available for Wii U.
     
  31. brettj

    brettj

    Joined:
    Feb 9, 2015
    Posts:
    43
    This is showing CullingGroups have been in since at least 5.2. And I implemented them in 5.3 so you should be fine.
     
  32. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    Oh, nevermind then. I didn't realize. Cool.
     
  33. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Hey, yes I've thought at culling groups but I've implemented the system like the docs from SpeedTree. I don't think CullingGroups would help too much, the current cell culling system is uber-fast. The whole script takes 1-2MS for determining everything related to trees, and the performance will be improved even further with grid subdivisions.

    But it already works at 420FPS with a quarter million trees when they're all billboards. How faster do you wish it to work, at 1000FPS? And when trees are visible it's at about 100FPS, depending on the count of trees.

    But of course, in a real game I expect people to place the trees a little more smarter than the stock unity random generator.
     
  34. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Hey,

    I'll take all the points one by one.

    1. I've submitted the project with unity 5.5.b9
    2. You can safely delete the standard assets, you don't need those. Use whatever you have in your game.
    3. Instead of 'SetVectorArray' you can manually unwrap the array and set it with 'SetVector' element by element
    4. The system is still dependent on either Unity 5.5 (where I can get the billboard UV's from the BillboardAsset) or it is dependent on the custom 'XML' that speedtree generates with the custom executable i've been talking about, where it extracts the billboard UV's from for pre-unity 5.5

    I strongly encourage you to grab unity 5.5b9 (no earlier) and test the system there, for the moment. Do some tests, see how it cales. And I also hope that in the meantime I can attach a 'readme' too.
     
  35. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    I was going to try that myself, but I was hoping you'd just fix it in a future version so it doesn't force 5.4+.

    I didn't think we needed 5.5 because you had said

    "No, no don't worry, it's DX9 (SM 3.0). It should work with any unity that is 5.0+."

    But I see now you are talking about this special exe for generating a SpeedTree xml. Do you mean that we need this special exe ourselves as part of our SpeedTree export process from their tool?
     
  36. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Unfortunately, yes. They gave me that 'exe' in order to be able to generate that billboard data. I'm not sure that they are letting me post it somewhere the internet :). I could ask them though, with this specific problem in mind and I'll let you know their answer.

    And for 5.5+, it seems that some data is missing from those UV's provided by unity so I wouldn't count on those either...
     
  37. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027
    OK, thanks. I still need to try the test with the SetVectorArray fix before I know if I can even use the system. I have to make sure it works on the Wii U. As soon as I can do the test I'll let you know how it goes.
     
  38. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Ok, 10x. I'll also contact Sp guys till then asking the 'exe' problem.
     
  39. marcatore

    marcatore

    Joined:
    May 22, 2015
    Posts:
    160
    First of all thank you for sharing your project.
    I've downloaded it and opened in Unity 5.5.0b9 but I can't understand how it works.
    Looking at your quick tips, I can't find the "Treefier" script and if I paint a tree using the Terrain mesh, how should convert them in billboard?

    Thanks in advance
     
  40. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Yes, sorry. It is a very pre-alpha without any docs. I'm still talking with the SpeedTree guys to solve some problems, and I really hope that I can add a read-me at least.

    But in short the basic is:
    1. Paint all the trees you want on the terrain (make sure they're visible in the terrain settings)
    2. In the 'Treeifier' script, after you have painted all the tree press 'Generate Trees'. That will integrate the tree in the system. I recommend mass placing some trees at the beginning, just to get the hang of it. Should work fine at 50-300k trees
    3. Hit play. You should see the trees that you have painted.

    I'm still updating the stuff, some problems still exist. But it is on hold (again) at the moment due to the fact that now i've implemented instancing and the 'DrawMeshInstanced' function is broken. It does not work with meshes that have multiple sub-meshes, so I guess we're dependent on the Unity guys to fix that (and not only that, it doesn't even work with the standard unity sphere)... There's absolutely nothing I can do.

    I've made the bug report, I really hope they are going to look into it since instancing is completely useless if it is not fixed :)
     
    Acissathar likes this.
  41. jason-fisher

    jason-fisher

    Joined:
    Mar 19, 2014
    Posts:
    133
    I think I would recommend building an octree per terrain 'chunk' that holds the center and box size of each tree? Then you can just AABB and split/dive into the tree based on sphere radius around the player. When you reach the deepest level, you will have a list of nearby trees for more detailed testing.

    https://github.com/BlueRaja/High-Speed-Priority-Queue-for-C-Sharp

    The high-speed priority queue here is very fast and useful for building the list of i.e. nearby tree positions. You could insert the 'close' trees with distance-to-player as you process them and setup a coroutine or thread to basically loop through that queue. If the player leaves the bounds of the parent of the deepest octree node they are in, AABB and split/dive again to build/update the tree collision queue.

    A quadtree could be used instead, but I am hoping to use this with voxels and there may be vegetation on an overhang over other vegetation. :)

    Really cool stuff .. will be playing around with it.
     
  42. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Hey!

    1. Yes, there should be an octree with a limited number of subdivisions for fast retrieval. However, I would not implement this in the tree system, but in the grass system, since that is more likely to be painted on various objects. For the trees the current technique is lighting fast, the cell visibility determination takes .001 MS. But yea, for the building the list of visible trees there can be improvement that speeds up the game. But the gain is quite minor, the bottleneck is the drawing of trees. I ended up using GPU instancing for optimal performance on dense forest patches. (Will be available on a future update)

    2. There is a huge pain building a grass system from scratch, especially with stuff that move around and the grass needs to follow it

    3. We don't have direct access to Unity's culling pipeline. If I would have access to that I'd make the list of 'possibly' visible cells and pass it to unity for static/dynamic culling. Since, now, even if you have a huge building covering a 'cell' of grass/trees it's still going to be sent for rendering, and I don't like that. One possible solution might be the 'manual' occlusion computation (maybe raycasting towards the cell's corners?) or trying to somehow use unity's 'CullingGroup' only for the possibly visible cells. That would make sense by computing the possibly visible cells from a coroutine from time to time in a manner a just a little different from how you described it, with the exception that the cells will not only be tested for visibility using the octree but also for occlusion with the Unity's API

    Practically, I use the unity terrain for editing just because I know that it will have the trees at the correct height. After that I extract the trees and add them to my system. But the tree system does not need to know where the trees come from. All that it needs is a 'Vector3' world position and a 'GameObject' tree prefab pair and to know to which terrain that tree is linked to. That can come from anywhere, from a unity terrain, from a parent 'GameObject' that holds a lot of trees, nothing else. (Will also be available in the next patch).

    But getting your trees in the right position can be a pain sometimes, and that is why I didn't tackled the 'octree' problem. But if you can manually place your trees in the correct position with your own tehnique, then the next update will be great for you! And don't worry, these are trees, not grass, so if you don't need a million overhanging trees it should be quite fine without voxels.

    Update with instancing:
    BushesNoInstancing.png
    (Thousands of bushes no instancing: 4-5FPS)
    BushesInstancing.png
    (Thousands of bushes with instancing: 70-100FPS. No light probes though)

    As a note, the project is halted at the moment because:

    1. The speed tree guys don't want to share the billboard UV extraction method for everyone at the moment. I'm still discussing with them, as soon as they respond I'll post here
    2. I don't know how to use the UV's provided by the BillboardAsset. Their layout is different from the one in the speedtree's 'xml' file and I have no idea on how to use them
     
    Last edited: Nov 5, 2016
  43. jason-fisher

    jason-fisher

    Joined:
    Mar 19, 2014
    Posts:
    133
    Sounds great. Yes, I plan on integrating your process with the world voxel octree that I have now. As this is a planet, at the lowest details I will hide billboards and render into a color detail map.

    Is this a similar format? http://nwn2.wikia.com/wiki/Speed_Tree_Format

    They're probably interpreting/generating UVs from the spline data? Maybe that is why they are hesitant to get into details as they would need to share a function?
     
    Last edited: Nov 5, 2016
  44. RizeoftheSummonds

    RizeoftheSummonds

    Joined:
    Nov 5, 2016
    Posts:
    49
    Looks pretty good.
     
  45. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Yes, if it's a planet you will probably need to tweak the grid generation algorithm, since now it's scaled for terrains.

    The UV's are packed in the '.spt' file that is generated by the SpeedTree modeler Unity edition. There is no need to expose anything in order to get to them. You can see the UV's, if you are curious, in the provided github project. There are some files called 'Bush.xml', 'Broadleaf.xml' that contain the billboard UV definitions.

    One more solution is using Unity 5.5+ where you can extract the billboard UV's from the 'BillboardAsset' that is linked to a SpeedTree billboard. The problem is that it really doesn't seem to be the same like the SpeedTree one in the 'xml' and I really don't know how to use them.

    If anyone can enlighten me on that point, this system could be available for Unity 5.5+ without that fancy XML extraction. But, maybe, in the meantime i can submit a bug report telling them the problem, and that the data differs.
     
    RizeoftheSummonds likes this.
  46. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Update:

    Since I did not receive an answer from SpeedTree representatives I will assume that they do not wish to provide the data within the XML, so, being sorry for the guys that need the system pre 5.5 or horizontal billboards, I will still release it with unity 5.5+ support.

    In the meantime I have implemented tree instancing, and decyphred the BillboardAsset data that is provided by unity.

    I hope that the next update will be available this week, for people to test the system on their unity 5.5+ projects.
     
  47. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Major update:

    Unity 5.5+ required.

    Improvements:
    - SpeedTree XML NOT required any more!
    - instancing support
    - tileable terrains support
    - CullingGroup API for tree cells

    Fixes:
    - fixed billboard transitions
    - fixed some billboard issues

    Known Issues:
    - Billboard choosing angle based is still wrong

    The demo has 4 tileable terrains, aprox 300k trees with 4 types now.

    Check out the github now at: https://github.com/AssemblyJohn/Critias-TreeSystem


    ALotOfBushes.png
    (just going crazy with bush instancing...)
     
    Last edited: Dec 2, 2016
  48. Knightmore

    Knightmore

    Joined:
    May 11, 2012
    Posts:
    227
    Damn now I need to try it and compare it next week with another buyable system. :D
    Time to get to work
     
  49. Assembler-Maze

    Assembler-Maze

    Joined:
    Jan 6, 2016
    Posts:
    630
    Which other buyable system? Could you link me the competition? :D
     
  50. magique

    magique

    Joined:
    May 2, 2014
    Posts:
    4,027