Over the weekend, I took a break from Asset Library refactoring and looked at some more effects, more specifically weather effects.
Doing weather well, comes with some challenges. There are a lot of different aspects which need to be handled. For rain, there are the particle effects, sure. Then there are the splashes and glossiness. For snow, there is additional ground coverage. How does wind play into all of this? What about the weather inside houses? Should they be occluded? And if so, can we do that without rendering the entire scene again from the "Weathers" perspective.
I may be overthinking this a bit. Some aspects of weather are a bit easier than others, and it's not like the first iteration would require all features.
So I researched a couple of aspects: Particles and Wind.
We use the Standard Rendering in Unity (with some modifications). And while the Scriptable Rendering Pipelines has some new toys to play with, we've been left with "Shuriken, " Unity's particle emitter.
"Shuriken" is a perfectly fine particle emitter and is even jobified (I believe) with Unity's job system. So it is pretty fast for CPU driven system. It's not quite the "Visual Effect Graph," though. The Visual Effect Graph is a Visual Scripting Graph for generating Compute Shaders. It is cool.
So my thought was: "I'd love something like that for the Standard Renderer". Mainly for having a fuller Visual Effect solution and the ability to use GPU Particles and Depth Collision. I went googling and came across this: [LINK]
A forked version of the Visual Effect Graph backported to work with the Standard Renderer.
I quickly had a ton of particles on screen using the Visual Effect Graph in all its GPU accelerated glory!
Now I needed to spawn some particles on hit! One of the reasons I wanted to use Depth Collision is because we're using the new Unity Physics rather than the old NVidia Physx. But the particle systems are created with the old system in mind. And second reason of course: is GPU acceleration.
No such out-of-the-box luck, unfortunately.
Looks like it is available only in the High Definition Rendering Pipeline.
Time for some surgery. I forked the fork and started looking into pushing the Depthbuffer into the system through some other paths. The system is quite clean, and after some hours and some googling, I was actually able to get the Depth-Buffer Collision working!
It is far from perfect, as it only respects things on the screen at any point. But it is excellent for just spawning splashes in the case of rain.
So now we might have a robust system for doing the particle parts of weather. I'm also hoping to utilize this in the Emote system. (More on this another time)
Another aspect of the weather is the wind. Now, it tends to affect pretty much everything weather-related. I came across this GDC talk on the subject of Wind and Vegetation:
It is a solid talk and shows some of the techniques and considerations. Some of it is a bit beyond our current scope, but the part about baking pivots into vertex colors to separate branches, etc., is something I've wanted to try for a long time. Therefore I created a tool inside of Taleweaver to take a mesh with some vertex colors, basically a black and white mask of which verts are considered static. (trunk of a tree or base of a leaf).
Then the tool builds a node structure out of the verts, traverse it to find the closest root vert, and records an offset plus a distance.
After some failed attempts (I swear this is a palm tree)
I had a somewhat successful result.
The wind, in this case, is just a direction and some sinus curves (So movement looks a bit funky). But otherwise, it is implemented similar to the GDC talk. One pass for the trunk using the distance to the object's pivot as a mask, then a second pass using the baked pivots to get secondary motion on the leaves.
These are experiments that open up some avenues for doing weather in TaleSpire. A lot is needed to make this a proper feature, however.
It's something to get back to on another weekend.
In my next DevLog, I'll be talking about some of the refactoring done to the Asset Library to pave the way for HeroForge. I'd like to talk about the changes to the structure and how the future expansion of the Library works.
Thanks for checking out this DevLog, I hope it was somewhat interesting.
Till next time! Have a good one.
Disclaimer: This DevLog is from the perspective of one developer. So it doesn’t reflect everything going on with the team