Next week's video is going to be completely off the rails lol. I really hope you guys enjoy it. It's already available on Patreon, but it'll be live for free on YT next Monday.
using this method on for instance a waterfall can also create amazing effects and reduces the need of thousands or millions of particles, like when the character walk through a waterfall the stream will deform around the character like irl basically only need 3 or 5 collision shapes (head/shoulders and or feet/legs)
You did a great job explaining how Red Dead gets it right but didn't really say anything about why snow is particularly difficult (like the title suggests). I would very much still be interested in that topic too, maybe with some examples that didn't turn out so great.
The character animation displayed at the end reminds me of the animations used in L4D2 when attacking and killing the Common infected, and the heavily diverse amount of animations used in these instances with the seamless transitions back into chasing you or ragdoll when dead.
I was thinking about this recently, like you said you can resolve from the position you walk on to the uv coordinates of the displacement texture to paint on it. But if you have a huge area or terrain, it means the resolution will not be great (unless you use a ton of big textures which takes a lot of memory). An interesting approach I've seen for that is a texture with some kind of uv offset that repositions itself to where the player stands if the player walks too far away from where the texture is placed. In that way, the texture only covers a range around the character but allows for better resolution for snow displacement. When that is done though, the texture has to be redrawn, taking into account the difference between the old and new offset. Another interesting idea might be to store the main spots and connections where the snow was walked on/crossed into a separate file and when the texture is repositioned, data can be supplemented from looking it up in that file. Or perhaps textures are still good for this too as they are efficient with storing dense information, but the point is that this data doesn't have to be loaded in runtime memory at all times. And something neat when it snows: There could be a compute shader that runs in a constant time interval on that texture that moves the painted color for height displacement back to the default color (e.g. using the red channel for height information and moving the value back to 0 again) so that it seems like the holes in the snow fill up again. Realistically, that is of course not how it works, as the increase in snow height should be move even across the terrain, but it will smooth out the transition from height displaced snow to the default surface of the terrain and if a spot has reached a 0 displacement, that means the data for this can be cleared. If something like a snow track history is saved somewhere but not updated in realtime, maybe a timestamp of the last update can be attached to an area and when that area is read again, the game processes the time difference and applies the texture channel decline accordingly.
I had an idea how worked snow thingy in rdr2, I think, 4 years before the game came out (when I was a schooler). I watched on my teacher's PC game about offroad delivery game, I think it was called the "Spintires". I remember I was amazed by mud deformation, as much as my teacher did, or perhaps even more (I liked to hang out in CS classroom cuz I liked to practice programming there with tasks from various competitions). I brainstormed and ended with idea that it most likely was done with tesselation + displacement map + some surface value that would represent max displacement multiplication (ofc from terminology i knew only the term "tesselation" and other stuff was described with more simple words)
I'm personally very curious how: 1.- Tesselation works 2.- You can dynamically send information from the collision spheres on the feet (or whatever else) to the heightmap in a way that's actually efficient (Inefficiently I can pretty easily imagine it). As that seems to be a crucial step that's sort of overlooked on the how.
This video is one of the big reasons that tessellation is sorely missed in UE5. I assume it's related to incompatibility with Nanite, but would be very useful if it came back.
Still wondering how UE5 does that, since they sadly have deprecated Tessellation. 😪 Just use Nanite and have a billion triangles for the ground to then displace them?
hii....does snow in assassins creed 3 works same as rdr2, if yes then how they managed to perform these complex calculations on previous gen consoles please tell....
I read about it somewhere but don't remember where. It's a technique called gpu animation. Basically you encode all the xyz movements of every vertex into a rgb texture and then in the vertex shader read from that texture and displace vertices accordingly. Then you can just use instanced rendering to draw stuff on the gpu directly and you'll get large crowds. It's a lot more complicated than what I described but this is the basic idea
Huh.... I guess I wanted a bit more details in this video. Just seems to gloss over implementation. I really want to hear about how the tessellation works in unity. I hear unreal 5 also doesnt have tessellation on meshes anymore? Oh well.
As a graphics programmer, this isn't really anything special or difficult...until you factor in the scale of the world / how long you expect that snow deformation to last. Never played RDR so I've no idea where they drew the line.
