I have been trying for hours to get this working, but I am giving up.
My terrain is highly complex and features lots of steep slopes. When utilizing the in-built foliage/tree terrain system, it will spawn the trees/foliage on the destined location, but it will not respect the underlying normal on the terrain, thus the vegetation rotation will always remain static. This looks very unrealistic, as the grass is actually floating.
I did some raycasting (which, for some reason does not work if I raycast from the position of a TreeInstance to Vector3.down) and I could access the rotation, but apparently that’s a float, which leads me to think that there’s only rotation on X axis and other axes are not supported.
Thus, I am asking you, is it even possible to rotate the grass via script, so that it faces upwards, depending on the normal of the terrain in a given location? I even considered creating gameobjects in runtime with the grass’s model and rotate them as I want, but this sounds like an overkill (not to mention that they will not be affected by wind force). There are shaders I have found which work directly on the GPU, but, unfortunately, they rely on 2D textures and you cannot import your very own mesh (aka they have a premade triangulation protocol and despite the texture you’re using, the grass’s shape looks the same).
I have tried both creating a Ray and setting its origin and its destination respectively and a direct RayCastHit by defining the origin and directions vector and a distance within the Physics.Raycast. Honestly, I am not concerned about this, because, even if I access the terrain’s normal, the rotation will only be modifiable on X axis.
To the problem now, is there any way of being given access to any rotational axis? Some people have suggested on other, slightly related, threads to create a different prefab for additional rotations, but I cannot possibly accumulate a set of every possible rotation a normal might have (plus, such a workflow is so sloppy, it irritates me).
Why would the rotation only be modifiable on X axis?
I’m assuming these are GameObjects, which have Transforms, which store rotation as a Quaternion… Quaternions are complex numbers that store rotation as what is essentially an angle-axis.
First off, I should have described it better, I am using Trees but with a grass model. Foliage per se tends to lag my scene, even if it is used in the same quantity as a tree.
On another note, this is quite absurd to be honest. Inability to modify specific values just because they are dictated by real life is a bad excuse. If that is the case, then we shouldn’t be able to modify the gravity value in Physics (Project Settings). I understand the logic, but it’s just not consistent with other options in Unity.
Moving the trees further down will only display a small portion of their actual mesh and it’s a waste. If this is the only physical workaround for this issue, then it’s concerning and I come to advocate those who have been stating that the terraining system in Unity is obsolete. If I am not to do it with the predictable way and had to find a workaround, is there anything you could suggest?
There’s probably an optimization that can be made when making such an assumption.
Calculating a single axis of rotation is much faster than a variable axis of rotation. And as you said… you want to use it to speed things up. Well… why is it faster? Probably because they have restrictive optimizations built into it.
Simplicity (deriving from your previous statement of how trees grow upwards) comes with performance optimization. I absolutely agree with what you are saying, but not having the option to access all axes is just not user-friendly. Anyway, this is definitely not the point of this discussion. If you have another recommendation, other than resorting to manually creating grass gameobjects, I would appreciate it.
P.S. TreeInstances should have quaternions, otherwise this violates the design pattern of Unity Editor. My guess is that we are simply not given access to them. It may be an uneducated guess, given that I am not aware of how they are managed under the hood, but these values must be deriving from something Unity utilizes internally, be it Quaternions or EulerAngles.