Works from 2019 and some 2018. Made during student projects, personal projects, and my internship at Pajama Llama Games.
It includes rig, skin, animation, and particle systems.
Here’s a breakdown of a growth shader I made for my end-of-studies project. Check the previous post for some backstory, it explains some of the constraints and decisions taken !
I decided that the tree’s trunk was going to grow first, then followed by the branches and finally the foliage. It’s not exactly how trees grow in real-life but as the growth was accelerated and we were distancing ourselves from reality, I took this liberty. Finally, the whole would have to wiggle slightly, faking the plant reaching for sunlight.
Firstly, an opacity mask defines which part is visibly growing. This mask is panning up, simulating the apparition of the trees’ parts. It gives us control on the order of apparition. This can be related to the tree Z axis or a UV map. The first option gives weird effects such as a branch appearing from its tip instead of from its basis. The second one, with a UV map per branch, can also have strange results, such as a branch appearing from its basis before the trunk reaches it.
To solve this, the opacity mask is a UV in itself, defining an order of apparition for the branches. As you can see, on this preview in Blender: the trunk and all elements which can grow first are in white, the lowest branches are in blue, the medium ones in pink and the highest one in yellow. I was planning on adding more levels in the future but it never appeared useful. To improve performance, this can be stored in another texture, as it only requires 4 color squares.
As a plant grows, it’s obviously not cut straight, it forms a tip, which we’ll call the pinch or shrink. Since it cannot be uniform: the thickness of the trunk is too large compared to the thickness of the branches on top, the same value would have resulted in some ugly vertex displacement ; it’s another UV.
This resulted in having 3 UV sets for each tree:
one for the branches' apparition order,
one for their thickness
and the last one for the actual textures.
The second one ended up being useless as I found another way to link the shrink value to the mesh thickness. Jesper Bergman uses the same logic.
Aside from that, the wiggle-y movement done by a plant as it grows and aims for light is a simple vertex offset that only applies above a certain height.
Can always be improved !
The choice of developing the growth through a shader came relevant since it was easy to apply its system to a more classic pipeline. However, it’s not a perfect solution, the shader needs information on the tree to adapt to each shape and have a smooth animation. Until then, the shader can appear as a visual bug and be unpleasant for the player.
For that reason, Houdini comes back into the workflow at this point. Using it allows for quick iteration and to develop tools to extract more data from the meshes. For example having more precise animations with vertex animation maps, setting branches to appear lower and grow high following the trunk, etc.
This basis gives enough room to iterate and improve quickly. The combination of Houdini and Amplify shader allows us to work on the tree meshes separately and avoid having to redo the whole process for each mesh iteration.
Here’s some research I did on procedural plants and plants’ growth for my end-of-studies project. We’re working on an adventure game in which the player is restoring a forest environment.
The basic goal was to have trees growing in real-time in front of the player’s eyes. We also wanted it to maintain our goals regarding the environment, such as a credible forest, with an important vegetal diversity, wind blow, hand-painted textures, etc. Those had to be considered.
At the beginning of the project, we were aiming for a procedurally generated forest, which echoed our intentions (a unique forest for each player and each play, enhancing the player’s actions’ ripple effect). Although this came to a short-end given our production time and capacity, it is an important element which led our technical decisions regarding the plants’ growth.
With that in mind, we explored a lot of paths allowing us to generate trees and plants in accordance to our artistic direction, to iterate easily on them and include a growth animation usable in real-time. Obviously, this included the ability to produce LODs, control UVs, etc. The workflow had to be maintainable through the whole production. The growth goal is to show accelerated growth, and be immediate feedback for the player when they plant a tree.
The first solutions that come to mind are Speedtree, Unity-intern process and Houdini.
We ruled out Speedtree, although it’s a very complete software, the assets extracted from it are heavily locked and we wouldn’t have had enough control in real-time to iterate on the generation and growth.
The Unity-intern process had either not been updated for a while, not a growth included or would need someone full-time on developing it (ex. developing a L-System). MTree, a Unity package, is the best solution in that path, since there’s a very responsive community around it.
Houdini would probably be the best approach, given the flexibility of it and the use of L-System (as showcased by Anastasia Opara). However, it doesn’t allow edition in real-time so everything would have had to be baked and at the time, we wanted something more procedural at the time.
Note that Blender also has a L-System which can be compared to Houdini. In general, using the L-System included a lot of research, it’s a string rewriting system used to model tree morphology in computer graphics (more info here). We didn’t have the luxury to have someone working full-time on it, which was a decisive argument.
With all that in mind, we started working with MTree to quickly generate a lot of trees and plants. And started using Amplify shader to create a shader that would fake the growth. It allowed a lot of control inside Unity and outside, if we needed some pipeline changes at some point (spoilers: we did).
Afterwards, we slowly let go of the procedural trees. We started doing a lot of edits on the MTree assets, at a point which made it easier to do the trees from scratch, using Blender and ZBrush. It gives use more control on the shape and LODs. The choice of developing the growth through a shader came relevant since it was easy to apply its system to a more classic pipeline.
Moreover, using a shader instead of blendshapes (which we tried with Maya) or a classic animation pipeline with rig and skin (which we’re iterating on for the plants), reduces the time spent on working on unique animation and makes it easier to iterate on the trees’ shapes. It gives us total control on its speed and rhythm.
I’ll do another post to breakdown the growth shader itself.
prguitarman
kianamaiart
amandla
pixelskylines
2087
dailybridgerton
blakekathryn