Designing the Desert - Part 1
All the outdoor scenes in the film happen on a barren overheaded desert. I decided to make it mostly a rocky desert and not so much a sand desert. Partly because I did not want it to look too much like Dune. But mostly because then I would not have to worry about footprints and other ground contact interactions. Also I realized that making realistic sand dunes is quite hard.
Eventually, I decided to go for a bit stylized realism. Pretty much like Mad Max: Fury Road did things. So that it would look realistic, but not necessarily photorealistic.
I decided to render the whole film mostly with Eevee, because I did some math and realized that even if I managed to optimize all the scenes so well that I could render one frame in 15 seconds with Cycles (which is totally unrealistic with my hardware anyway) it would still take almost six months to render everything. Not to even mention realising mistakes in renders and correcting and re-rendering them. I also decided to use PolyHaven rock, coastline and cliff assets to build my scenes due to the lack of my own modeling skills and not having to do any photoscanning etc on my own. Also they had realistic textures already.
Unfortunately, my plan backfired right at the start, because after filling the scenes with 4K textured terrain assets, Blender started crashing with Eevee. I did not know much about these things back then, but I figured out it was not because of the poly count, but because of the amount of textures. So I discarded all the ready made textures and replaced them with one single generic tiled PBR rock texture for the whole scene. After that: no more crashes.
But making the scene look realistic with just one material for everything meant that I needed to add variations and details to it. I did not know any other way to make rock look more realistic than adding lots of details to them. And with just one material available, I knew I needed to do that with displacement modifiers. Which meant that the poly count skyrocketed and started causing new crashes. So I needed to divide the shots into different collections: foreground, middle ground, background, etc as needed.
I also realised that the terrain assets did not like subsurf modifier. It got extremely laggy and even crashed with just one subdivision. But with landscapes generated with ANT Landscape and some mountain assets, it was very smooth and could handle a lot more subdivisions without a problem. So I figured maybe it has something to do with the terrain assets being mostly triangulated, but the ANT Landscapes and mountains all quads. So I blocked the scene first with the original assets, then added planes, subdivided them and used face projections to make an all quad copies of all the rocks and terrains. With terrains I did it from up view, but with single rocks I did it by projecting a subdivided plane from the camera view and doing some tweaks on the edge areas. Sometimes when the camera was moving I placed a camera inside the original rock, set the focal length to 5, oriented it to cover most of the rock surface from inside, then used that camera view to make an explosive like projection from inside, so it would look good from more than one angle. All of this was slow, but it made everything so much smoother and efficient that in the end it made my work faster, because I did not need to wait 10 minutes after turning a subsurf modifier visibility on for the viewport to upload it, and fear that it would crash the software at any time.
First I used uv maps for displacement modifiers, but at some point I realised it was more efficient to use empties and object mapping with them, because then I could move, rotate and scale them in real time without needing to go into edit mode to adjust the uv maps. Also it seemed to be a bit faster to render. If the displacents got too much tiling and repetition going on I used vertex groups and weight painting to mix different displacement maps together.
One problem was also the stretching of textures on areas that had very sharp displacements. But I realised that instead of using normal directions for displacement I could use object coordinates, so I set it to local Z and then rotated the object origin to face the camera (or almost camera). So it killed the stretching, because it was happening towards the camera. I could also get more details this way, because I could add pretty extreme displacement strengths without it looking too weird. If I really needen some other direction for the displacement, to prevent texture stretching I sometimes used window projection for the textures for those shots and scaled and adjusted them with mapping nodes.
Don’t give me ideas! 
wink: Because when i was in school we used to read (and watch) such things and i remember untill today. Which seems too cumbersome for learners nowadays. They properly ask some AI… and according to some questions here on BA do not know the answer some weeks later and so re-ask the same or similar thing again 