[SALE] InfiniTREE - Procedural tree generation-growth, Multithreaded batching & Forest management

New chop trees and mesh growth demos are ready !!!!

Both are work in progress.

Enjoy

InfiniTREE - Procedural Tree generation and chop demo
https://dl.dropboxusercontent.com/u/79230236/INFINIDY/TREE/INfiniDY Tree Demo CHOP.html

InfiniTREE - Procedural tree branch generation, using both splines and user input
https://dl.dropboxusercontent.com/u/79230236/INFINIDY/TREE/INfiniDY Tree Demo GROW.html

I am now also working on the grass shader and module demo. InfiniGRASS will be a free update for InfiniTREE users and may also release as standalone later.

Instructions:
- Use the left mouse button to grow trees and right mouse button to chop.
- Grab the cubes in the mesh creation demo and grow the tree to any direction

 

New InfiniGRASS system, WIP. The shader is now working for both opaque and transparent items and is very controllable. The LOD and the whole base system works fine too, so there can be infinite grass in the scene that can also be fully dynamic locally !!!

Wind effects are already integrated and working great.

The art and the system are WIP.

 

I cant seem to get the basics working.

I can get the demo scene working. But trying to put the prefab in my scene gives me a root_tree error.

Any clues?

EDIT: For Future ref. All I did to fix was DISABLE the prefab.

 

Tiny Point.

The Controller Camera has an extra Mouse Look latched to the Y which is redundant and can be removed when the missing script is correctly relinked to Mouse Look InifiniDy script on the Hero object (mine is called Player here)


Correct Script reattached

 

I have a question about "near" optimisation.

I managed to get the trees instantiating in my scene however when I go really close to a tree the draw count goes up by about 500 per tree. I will keep playing around with the settings to see if I can get a better result but I assume it is the individual bits all being shadow casters maybe?
Will dig.



The leaves seem to "miss" the edges of one of the tree types? prefab mangled maybe?
I tried playing with the settings but don't know enough yet to fix it.




"Far" works nicely and seems to only shove a few calls on (I will do some exact tests later)





One more thing: Are there plans in the future to do a more realistic job on the billboarding as I am experiencing strange popping in tree shapes, which I will vid if it is still there in the next release.

will do some accurate garbage metrics at some point soon, however creating a tree has two very large spikes, the first long spike as it tries, and fails, to render so many objects in one frame and then at the end when the Garbage Collection kicks in long enough to freeze a whole frame (pictured)



Will keep looking through the codebase and try to get familiar.

I spotted some places where cache referencing the indexers will get wins, same with a few of the component look-ups, when you release the next update I will have a quick "search and replace" on it, and throw it back.

thanks

 

Tree chop demo causes a tree to be instanced at the location of the chop, thus spawning an extra tree per blow.

 

The problem is that the growth is done on any collider, so it sometimes grabs the other tree or even the axe collider. I will have a check that the collision for growth is done only with the ground in the next demo update.

Thanks for bringing this to my attention.

 

meh it's cool. Please don't limit it to Ground only as I use meshes for my stuff and may wish to spawn plants on anything. And chop them down. Just disable that logic path during right mouse click events.

 

Ok, i will try to partly limit it in that way,

Also i will work on a feature that will align the tree optionally based on the ground normal, so trees dont always stand in a vertical way. This is a rather large subject, since the angle for each case would be different (for example a tree grown in a vertical wall cant be in a flat position, since it would not seem natural)

 

Yeah I have a script that places all those houses and plants based on the impacted normal of a ray at level-start (that level pictured in my posts above is procedural in all it's placement, except the paths and one tree). Trivial stuff (must be, I made it)

Underwater plants pretty much always want to "face straight up" with a small degree of variation (say 5%)


a fully "hit normal" effect is a bit over-the-top in water



Unless the plants are very short. Here you can see long plants favouring UP and short ones favouring the hit normal



A good rule of thumb is to think about the stemmage on plants and how fast the plants put on "skeleton", slow growing plants tend to be windy and will curve towards the sun over time, fast growers tend to bit straighter (natures sprinters lol) and thus may tend to have a bit more crazy divergence on the bell curve. Mainly though I would go for a 50-50 approach, 50% Vector3.up and 50% the hit normal. Then random that up a bit. Then a slider per plant type to control the randomness. genetic divergence withstanding

 

Indeed, the 50-50 with randomizing between seems like the best idea for start. And with a cutoff for extreme angles, so trees dont fall flat or have less than 45 degrees angle to the ground.

I also plan to spice things up even more, by making a script that will grow the tree roots towards the free sides, with physics, using the new mesh growth feature, this would make the effect even more realistic and cool looking.

 

typo(s)

 

I did try adding my own trees, however I keep getting:

Code (csharp):

1.  
2. UnassignedReferenceException: The variable root_tree of INfiniDyForest has not been assigned.
3. You probably need to assign the root_tree variable of the INfiniDyForest script in the inspector.
4. Artngame.INfiniDy.INfiniDyForest.Update () (at Assets/InfiniTREE/Scripts/INfiniDyForest.cs:469)
5.  

Which is of course:

Code (csharp):

1.  
2. [HideInInspector]
3. public GameObject root_tree;
4.  

Will try to scry what that means tomorrow. Bed


I also tried to see where the huge performance hole was.

Looks like shadows is indeed one problem. Shouldn't take that long to calculate shadows...
Even that many. Will take a look maybe.

 

Thanks for the notes on the system.

I will remove the misspelled variables in the next version, since both of these options can be applied when the lists have more than one items automatically.

About the shadows, one idea would be to LOD them directly from the script, with a different LOD distance than the mesh LOD. I will also check out other possible solutions to lowering the shadow needs. Does the spike(s) happen when the trees are opened for dynamic use ?

About the "root tree" issue, i cannot reproduce it, if possible let me know the steps taken to create the new tree and whether this is created in editor or real time. As a tip, i would always test a tree in play mode before growing it in the editor for scene and preview use.

The growth happens at the start function, so if something gets stuck or is not defined when trying to grow in editor, and does not parse the start function, it will create an issue. A solution to this would be to add a check for the proper start() run in the update and run it if the tree has not been properly created, i will have that in the next version.

 

About the dynamic trees, these will be separate items when the tree is in dynamic mode, so the draw calls will locally increase. There are a number of additions that can come in to lower the draw calls and the shadows is something i will be working on to optimize for the dynamic case. The dynamic trees are in groups of two, so the draw calls when opened can be minimized comparing to having 12 opened trees in the bigger static tree groups. The dynamic tree option in the script will automatically place grown trees in a dynamic trees pool (of 2 trees in the demo, but any number is possible, depending on the machine power).

About the billboarding, there is a plan to offer an automation using my other pack, Toon Effects Maker that has a sprite sheet recorder. This could be used to take a snapshot of the tree in full detail and instantiate it in LOD later. I will also add a script to turn the billboard towards the camera so it acts properly.

The goal is to streamline this procedure for everyone that has both packs. And as a big thanks for the first review of the pack i will send over a voucher for Toon Effects Maker, so you can start using it for the billboards right away

I can recreated the leaves problem and is under investigation, it seems to happen at certain growth rates randomly and i will check what is the issue and include a fix in the next update. Seems like either the branches growth ends too early and they dont meet the leaves as they dont get their destined length or leaves scale goes over the proper one.

I will get back with a hotfix soon, before the store version is up.

 

Wow thanks dude. total awesome

 

UPDATE:

Some of the fixes i did and will be released very soon. I will upload a package with the update too and email the link, for everyone insterested to have the changes before it goes up in the store

v1.2 update summary:

- A remark on instant grow leaves, this must be used only when the Grow tree option is off

- Fixed displacement issue with leaves

- Leaves grow to their proper size

- Added option to lower growth change per level

- Removed alternate_leaves and branch_prefab_per_level options, now these are enabled by default when the lists of leaves - branches have more than one member

- Added Leaf_dist_factor option, to control distance between created leaves

- Added first version of grass shader and motion.

- Added chop feature and complete demo scene, with sound, particles etc

I will also look into the shadows, maybe i add a control to disable when in dynamic transition, partially perhaps depending on item type

 

I am almost done with the basic fixes and indeed the leaves had a displacement issue, which is now fixed. Thanks a lot for the input in this.

I will send a link with the update in your email as soon as i have tested it well, to make sure there is no other issues created after these fixes. If there is a need to change some of the prefabs as well, i will upload the whole package, just to be on the safe side.

Also i will create and send the Toon Effects Maker voucher in your email.

 

"About the "root tree" issue, i cannot reproduce it, if possible let me know the steps taken to create the new tree and whether this is created in editor or real time. As a tip, i would always test a tree in play mode before growing it in the editor for scene and preview use."​

Turns out this happens for two reasons. (probably more)
And that error is just a "resulting subsequent error" in the cases I have seen it so far.
It may as well say "You messed up before this point"

REASONS (so far):
a) you are really stupid and forget to put the prefab in a resources folder. <-- I did this.


b) the UT client is being really stupid and refuses to parse anything in a new Resources folder until it is restarted (This happened when I first pulled in the project last night)


I have however got a basic tree working - even if the combiner is still chucking out errors

Meet the universes least thought out tree "The Bamboo Ball" lol



I still get a null Combiner by the time the line:

if(!Combiner.doing_batching & !batching_ended){
Combiner.doing_batching = true;//signal other trees to stop dynamic mode
}

Is reached.
Will keep digging <-- Okay this was caused by misunderstanding what a FOREST HOLDER does. I thought it meant "Spawned Items Parent GameObject", which it does not.

 

Please can we make "Grow In Editor" DELETE the previous Instances growth and REGROW when the radio button is toggled.

When I delete the generated instance Grow In Editor will not grow another Instance?

Clicking the radio button "looks like" it does nothing after the 1st growth is ended/deleted
still trying to figure out the best workflow but this doesn't feel optimal.

Is it broken?

 

Each growth is done only once as it is made. This is because it has to also spread the trees in holders and create the environment for the real time batching and use. I can create a system to erase the created stuff and reset, but this would be rather complicated and would probably be more confusing than keeping a copy of the original item to grow again and again playing with the options.

For now you can duplicate the item before editor growth and delete it if it is not as desired, this way you will always have a not grown copy to grow a new one.

I will definitly consider a more streamlined way of doing that in a later update.

 

okay. err. I will try that. Whatever "works best" is fine by me. It is totally non-obvious though

 

You are right on that, it should be mentioned more clearly to avoid confusion. The system was initially created for real time use and that is why the editor side is a bit early in development and ease of use. The other reason is the rather big complexity of the scheme to achieve the goal of real time forest creation and manipulation with L-trees.

It will take a lot of testing and code checks to offer a full re-grow in the same script in editor, but is definitly possible and will come eventually.

 

Oh sure, no problem. Just trying to carve out a workflow here

Thanks very much!

If you want to throw over the next update before you release it I am happy to add those simple performance enhancements I mentioned. Or in a future release. Whenever.

 

I am preparing the pack and testing it, so should be on the way soon. I will send it before it passes store review, so you can have early access. Any additions will definitly be most welcome as well.

 

Excellent. working my way through that other thing in the meantime.
Thanks

 

Nice, let me know for any questions.

Some tips to help get started with the Sprite Sheet Maker

- Use the menu Window -> Toon Effects Maker interface to setup the system easilly. Select the required item and press the button in sheet maker section to setup the system automatically.
- Play mode must be active for the system to work. The automatic system will set it up to begin on play, but this can be changed and enabled during play mode manually, for full control of timing.
- The item to grab must be disabled preferably (the system will enable it when it gets enabled, usefull so particles dont play out before the grab system is enabled)
- Preferably the item must be in camera view and at the distance required before entering play mode.
- Webplayer platform is not supported, to use must switch platform is webplayer is active.
- The system will try to add the required layer for the sheet make, but if is full will produce a warning and the layer must be manually added.
- GUI items must be disabled, otherwise will be grabbed as well in the frames
- For the billboard set the x-y of the sheet to one
- The play window resolution is the one of each grabbed frame, multiplied by the upscale factor

 

Spoiler

Okay so if I enable branch_prefab_per_level with prefab ID's that don't exist I get:

Code (csharp):

1.  
2. NullReferenceException: Object reference not set to an instance of an object
3. Artngame.INfiniDy.INfiniDyForest.Update () (at Assets/InfiniTREE/Scripts/INfiniDyForest.cs:485)
4.  

Which is the Combiner object complaining about the missing prefab I think

You should check/warn for branchPrefabID's that do not exist. Just make the error checking a bit smarter.
Or messages clearer

It's easy to make a mistake when removing something when the related value is not checked.



(there is no 1 in this example. it will cause the error spoilered above)

Also:

I seem to occasionally manage to get: (In InfiniTree)

Code (csharp):

1.  
2. ArgumentOutOfRangeException: Argument is out of range.
3. Parameter name: index
4. System.Collections.Generic.List`1[UnityEngine.MeshFilter].get_Item (Int32 index) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:633)
5. Artngame.INfiniDy.ControlCombineChildrenINfiniDy.LateUpdate () (at Assets/InfiniTREE/Scripts/ControlCombineChildrenINfiniDy.cs:421)
6.  

Which is to do with

Code (csharp):

1.  
2. //LOD - reenable LOD groups to count in combine
3. if(Destroy_list_MF64.Count>0){
4. for(int i=0;i<Destroy_list_MF64.Count;i++){
5.  
6. if(Destroy_list_MF64[i]!=null){
7. if(Destroy_list_MF[i].gameObject.renderer.sharedMaterial.name.Contains("LOD")){  // <-- this I think
8. Destroy_list_MF64[i].gameObject.SetActive(true);
9. }else{
10. ....
11.  

most likely this is a stupid setting, however preventing such an error being allowed would be preferable.

I am doing nothing special but going through the various settings and seeing what they do.

If I find out how to cause that one reliably I will report.
I have only tweaked setting as far as I know. It was working. Will keep at it.

 

I just found out this myself

It is an oversight of an error, because it did not show in testing a lot.

the Destroy_list_MF is now changed to Destroy_list_MF64 as it should be.

If you change that will work ok.

I have now also automated some checks for the editor side and testing it to make sure it all works out ok.

 

cool. Good catch. I found the other thing to check for - Updated above.

Could you be a bit more specific on the fix please?
Just change that one single reference on that line? or all references to the old list?
Just change the one ref- got it

Many thanks.

 

This code is the one with the wrong reference (Destroy_list_MF)

Code (csharp):

1.  
2.  
3. //LOD - reenable LOD groups to count in combine
4.            if(Destroy_list_MF64.Count>0){
5.              for(int i=0;i<Destroy_list_MF64.Count;i++){
6.  
7.                if(Destroy_list_MF64[i]!=null){
8.                  if(Destroy_list_MF[i].gameObject.renderer.sharedMaterial.name.Contains("LOD")){
9.                    Destroy_list_MF64[i].gameObject.SetActive(false);
10.                  }else{
11.  
12.                  }
13.                }
14.              }
15.            }
16.  

and should be changed to

Code (csharp):

1.  
2. FIXED below
3.  
4. //LOD - reenable LOD groups to count in combine
5.            if(Destroy_list_MF64.Count>0){
6.              for(int i=0;i<Destroy_list_MF64.Count;i++){
7.  
8.                if(Destroy_list_MF64[i]!=null){
9.                  if(Destroy_list_MF64[i].gameObject.renderer.sharedMaterial.name.Contains("LOD")){
10.                    Destroy_list_MF64[i].gameObject.SetActive(false);
11.                  }else{
12.  
13.                  }
14.                }
15.              }
16.            }
17.  

Also you are absolutly right about the ID that may be set to a non existing number, i am adding it to the hotfix list asap (plus any other case that this may happen). I am almost done now with the hard parts and testing extensively, hopefully will have it done and send it over tomorrow. I will add the first version of the shader based grass and the chop demos as well.

I have also added the extra controls for the per level growth chance, which gives better control over the growth detail

 

Thanks man.
Sorry to be a pain.

It's getting cool though.

Next test: Using crystal meshes.... will post results ;P

 

No pain at all, there are things that are hard to catch when making and testing without an actual implementation, so your input is extremely valuable and has just made the pack so much better for everyone

I cant wait to see more pics. Keep in mind that the leaves are now correctly assigned and grown, so you will see a rather big difference and more correct results in the leaf side with the update.

The system can indeed be used for anything. With some simple coding i turned it to the new grass system for example.

It might also work for complex rock formations, with the LOD etc the possibilities are many. The crystals is a superb idea as well

 

Yeah I had a few visions yesterday for decent applications of the technology. There are lots.
Those grab handles working in the editor could totally redefine the workflow to a much more speedtree type interface for basic trees. Really excited to see what the kids think of this one.

My main "showstopper" is how to push such data over the Photon cloud network.
However I will burn that bridge when I come to it

Onward!

(I was idly thinking about using other more chaotic patterns...)


but that will be for the long future I think
but using this with your other shaders for a laugh? right now




free awesome moving squiggles for a draw call? wow. amazing

 

That is really cool , love the geometric play.

Also i have some great news, i was trying to find if there was a memory leak since ram was filling fast with each tree grown and there was just one line of code that used .mesh instead of .sharedmesh and this resulted in every single mesh to be instantiated, than derive from the common one.

Now this is 100% fixed and the system uses only one mesh for each item type and memory is now back to normal. This should give the system an extra big boost.

 

AWESOME news!

I love it when you accidentally win big! And it wasn't an accident

I have utterly sworn off the profiler until the next version

 

Indeed, that was a day and night difference in ram usuage. I used the task manager to spot the problem, i dont own Pro (though i have been given Unity 5 for testing the assets from Unity recently, but i have not used it for this asset yet)

The strange part is that the problem was not caused by an assignment of the mesh, but rather a simple check of one of the properties. Still even reading the .mesh created an instance !!

That is why probably i missed it while developing the tool.

 

yup. in fact the code for reading the mesh basically says "do I have a unique instance that I am reading from, No? Make one.. Read from from that" that is straight from a unity devs mouth (fingers)

I will be profiling this thing to death at some point. however that can wait until it is total awesome.
That said, I did have a cheeky look at the start and runtime is practically nothing. if not nothing.
Hard to improve on that

but creation time needed some love, however that ship is in the distance after the land of Awesome.

see you there

tree of pigs!



tree of flying pigs! or flying tree of pigs?

 

This is so amazing , especially the last pics are lovely and unique.

I will definitly provide the WIP for the mesh and spline, so you can see what can come up with and will be a great way to focus their direction even more too.

The dynamics and performance on all these systems will be a matter of optimization for many updates to come for sure.

 

Perhaps you should put a cap on the maximum vert count for the mesh...

really complicated meshes can do BAD things...



I reported the bug to unity. They should have caught that.

And yes, that model was INSANELY complicated. and HUGE. like colossal. (that was 0.00001 scale)

You shouldn't have a problem with this really. Only a complete idiot would build a tree from a scaled life-size statue of liberty...



EDIT: And in your defense - you may note that it was the 2nd tree that killed it (40M verts)
vive la liberté hehehe

 

Maybe this problem is caused because of the memory leak and Unity 4 limit with 32bit.

Try changing the .mesh to .sharedmesh in the code, so the shared mesh is used and see if it fixes it

In ControlCombineChilrdenInfiniDy.cs script

search for line:

Code (csharp):

1.  
2. if(!Multithreaded | (Multithreaded & ( (filter.mesh.vertexCount <= 32000 & filter.gameObject.name != "Combined mesh64")  | MTmethod2) )){
3.  

and change it to

Code (csharp):

1.  
2. if(!Multithreaded | (Multithreaded & ( (filter.sharedMesh.vertexCount <= 32000 & filter.gameObject.name != "Combined mesh64")  | MTmethod2) )){
3.  

Truth is though that 40M vertices is way too much

 

Having spent a large amount of time trying to get a good "Z to Y" Up conversion path it is clear to me that it would make a lot of sense to have a "MESH IS Y UP" tickbox for each mesh.

Many models of trees and parts are the wrong "UpNess" when provided by artists.

Currently all meshes are presumed to be Y Up, however the actual FBX export process puts the rotation information (-90 or 270 X) into the GAMEOBJECT, not the mesh, this rotation "fix" information is lost (as it never reaches the mesh) and IIRC it just inits with a Quaternion.Identity instead.

Thus stuff ends up rotated wrongly even when "exported correctly".

Thought I should share. Maybe scrape the rotation from the GameObject?
Might be easier than a tickbox

In Scene view - the "Donor" branch object is correctly UP but the -90x is in the GameObject
​

When using the underlying mesh it will strip this data and go Z Up


There is no fixing this "At Export" or "On Import" .
It needs to be worked around by pushing the GameObject rotation into the instantiated object if it going to work for "Most People".
You /could/ limit this and ONLY pass through the data if it is (-90,0,0) or (270,0,0) to cover these exact cases only.

Cheers

 

The way i handle this is by encapsulating to a gameobject and rotating as desired, before the instantiation. This way i can have more than one items for branches/leaves and any orientation for those.

I have not though of this issue for the tree creator, do you think it could be handled in some other way ? The problem is that this would complicate a lot the creation procedure, while the encapsuation method is very clean and allows for changing both pivot and orientation as desired.

 

Well, no, I m saying that that method of encapsulation is the problem in the first place.

I wish unity - at import- would just rotate the mesh AS IT SHOULD BE and stop all this "-90x" rubbish, but that ship has sailed (the thing is already made, or the artist can't change it or you don't have software, max does not apply the mesh rotation automatically on export [even if you beg], Unity does not do it on import)

I am suggesting one way to simplify this entire Unity "import" mess: just read the mesh sideways if the box for MESH IS Z UP is ticked.

Or - even better - provide a FIX MY MESH ROTATION utility to convert Z to Y up meshes. <-- Easiest. ( plus is another great reason to buy your thing)

(Here I used external tools to fix the Mesh rotation)


Being able to easily use things like statues makes for fun tree objects

 

The crystal one is super cool

Did the memory fix work btw ?

 

It did mate.

Much better now. Seems to "slow down" a lot less too, which would be the mesh copy I imagine.

Maybe I am just being stupid with the above comments but it really does seem like the rotation is stripped out of the instantiated prefabs, thus they cant be used to set rotation. Perhaps I am wrong.

 

If there is a certian prefab that excibits the behavior, you could email me and i can check it out.

Though the branches etc should be in a gameobject parent, and defined with the rotation in relation to the untranslated/unrotated parent.

If i understand correct, you mean that you use a prefab without parenting it in a gameobject, in which case indeed the rotation is handled by the system and changed based on the unrotated item.

So, if your prefab is not in the unity axis system unrotated, it has to be parented and rotated in a holder that is not rotated in relation to the unity axes. All the brances in my samples are like that, the unity tree creator mesh is referenced in a child of a holder, so i can be sure for the rotation and pivot.

 

Okay fair enough. I will just go for that then.

I still maintain that a "CONVERT MESH FROM Zup TO Yup" would have value

looking forward to perusing the next interface, trying not to get too wedded to the old one.


anenotree!



First actual genuine trees skeletons I made.

 

Looks very nice

The cartooney trees gave me a great idea also, i may include some cartoon style trees as well

 

Why is it that sometimes the trees refuse to batch and I end up with a few thousand draw calls?
Is there some limit that I am going over? Is it documented?

Cheers mate






Happens here when I add leaves.
Is fine without leaves

Many thanks