Terrain System?

I've not worked much with the terrain system, up until now, and I can say that it's not in the best of states.
Is there a technical reason why scripts cannot be attached to trees painted onto the terrain?
Or interact with raycasts without having to iterate over all the tree instances in the current terrain?
Is there a reason why clearing the terrainData.TreeInstances at runtime causes data to be lost when coming out of playmode?

All I want to do is be able to attach a script to a tree, paint it onto the terrain, and have it work with the usual Awake, Start, Update methods etc.
Why is this such a feat for unity.

I feel that they need to rework the terrain system to better fit what other engines are doing.

 

Yes. Those trees aren't real.

They aren't proper objects, they spawn around camera, and as you move further away they are eventually replaced with sprites. All for performance reasons.

If you want a tree with a script, either place a mesh, or attach the script to an empty.

 

What's the point in placeable trees using a tree tool? Visuals? Nice. Just enough for them to do the demos, then leave us to make our own tools to paint the meshes on the terrain.

Why don't they have an option of some sorts for visuals, while allowing for actual functional scenes with interactable trees?

 

The point is to make landscapes with a lot of vegetation, because handling those with trees being normal objects is very problematic. Those are higher performance trees made especially for this purpose. It is the same reason why you don't have individual grass stalks as gameobjects.

You already have an "option of visuals" while allowing for actual functional scenes. it is normal object. Nobody stops you from mixing landscape trees with mesh trees. Place the special tree normally, not through landscape tool.

 

Hand-placing meshes is not exactly easy with larger terrains. And either way, people make maps with loads of functional trees (that is ones with scripts on them), via external tools such as terrain painters from the asset store, so people are still going to do, it's just harder to achieve.

Unity lacking the functionality of this is a major point of failure in my opinion.

 

You could also argue that if they built this functionality into the core engine, it would be much more optimized than if us as the user would because it would be C++.

 

Why would Unity lacking the builtin ability to add interaction to their specially-optimised trees be considered a major point of failure? C++ would not magically make such an ability more optimised.

Build a tool to place trees on the terrain, it is a fairly easy thing to do. Be careful about performance, there is a reason why builtin trees act the way they do. Look into GPU instancing for information on how to keep your framerates.

 

Yes, I can make a tool for it, but why should I have to for such a simple task? Unity already has the functionality for painting trees, so why can't they just implement it into the engine so we don't have to do it ourselves.

If it's so unoptimised, how can engines like unreal do it, why can't unity?

 

It's just not a super common thing to do. Video-game trees are generally just placed there for visuals and have no interaction. The kind of games where you might want interactions with trees (like survival games) are a relatively new genre and a fairly small use case for terrain trees.

Basically, as a developer, you will have to fill in some blanks in the engine when developing your game. This is true of all game engines, though the provided features may vary between game engines.

Perhaps it might be a good idea for Unity to implement this feature in the future, but it's absence is certainly not a "major failure".

It can, Just not out of the box.

 

Unreal landscape works in exactly the same way as unity landscape. Meaning a landscape tree is a special object.and not an individual thing you see in hierarchy graph.

Actually the tree placement is often procedural, meaning they're akin to particle system.
https://docs.unrealengine.com/en-US/Engine/OpenWorldTools/ProceduralFoliage/QuickStart/index.html

 

You don't understand the implications of what you are asking for. To have every tree be a full game object, you would end up with thousands or tens of thousands game objects in the scene, all before you put anything else there.

Unity's implementation (and Unreal's for that matter) creates the illusion of trees in an efficient way. If you want interactable trees in your scene, then by all means do some programming and put them in the scene around where the player is, and can interact with them.

As a game developer you figure out crafty ways to create the illusion of real world complexity, so the player says, "Gee whiz I can interact with every tree in this forest." Unity is already creating the illusion that makes them say, "Gosh, I can see hundreds of trees, even on that hilltop far away."

 

This gets me thinking does Unity terrain system support a mechanic like chopping down trees DayZ style?
I havent worked alot with terrain details, but the built in navmesh exposes very little info so my guess is vanilla detail system does it too?

 

Take a look at TreeInstance. You can manipulate the position and scale of terrain trees at runtime. And of course you can remove and spawn them using TerrainData.SetTreeInstances.
So when the player chops a tree, you could simply remove it from the Terrain and replace it with a real GameObject to do more complex stuff with it.

 

It does. Most of the landscape/terrain data can be accessed one way or another, and you can get tree position, orientation and tint. And kill it when needed.

Yep. It is just you can't attach script directly to the tree.

 

You understand that people are telling me to make a tool that does this anyway... I will be placing direct meshes into the world anyway, with a tool such as this, so the performance won't be any different.

 

Right, but because you wrote it you'll be able to customise it for your specific needs when you run into those performance issues. Unity can't predict every individual project's specific needs ahead of time. Optimisations that make sense for your project might not work well for others, in exactly the same way that the optimisations they chose to go with happen to not work well for you.

That said, if they were making the terrain system as a new thing today then they probably would cover your case, as it's increasingly common.