When rendering, does Blender calculate and render polygons that are hidden to the camera?
For example, you have some rocks, some in front of others, does the program render those polygons that are in the back? Does that add to the size and length of rendering time, and does that matter whether its cycles or EEVEE engine.
There are various optimization methods in the category of "culling": ignoring faces that are not visible to the camera:
Frustum and backface culling algorithms are trivial*, but occlusion culling is more tricky, because you can't simply compare camera properties with triangle coordinates/normal, you need to investigate objects between them. However, in ray-tracing rendering like in Cycles or some modern video games, a triangle can be visible indirectly in something reflective: making it hard to predict which triangle contributes to the render; I think this might be the reason Blender doesn't put a lot of effort into those algorithms...
Each material has a Backface Culling option, to disable default Blender's behavior to display each face from both sides:
Due to how Eevee works, where each triangle is projected onto the viewing range, it goes without saying it only renders the triangles inside the viewing range. But Cycles renders everything, because everything affects everything else. You can, however, enable frustum culling in render settings:
As for Occlusion culling, to my knowledge it's not implemented (I think it might have been implemented in Blender Game Engine), but I've seen some custom implementations:
If backface culling is off (which it is by default), yes. Backface culling was created specifically to help with this. However, with transparent or reflective materials, it can cause both undesired or intentionally unrealistic and thus cool effects.
Since this hasn't been marked as answered (yet), I'd like to add something on top of the existing great suggestions that I feel is worth mentioning, specifically for Cycles:
does the program render those polygons that are in the back?
From your example, the backside of the rock is loaded into memory for Cycles. But it's not considered for the render unless a Cycles ray hits it.
But the ray intersection tests in Cycles are optimized - Blender doesn't test for every ray if it hits every object. That is what the Bounding Volume Hierarchy (BVH, which you may see in some render settings) optimizes for. That is why per-pixel rendering performance is pretty consistent between complex and simple meshes, as demonstrated by Blender Bob here: https://youtu.be/B79bGW7F8N0
But that improvement in speed comes at a cost in memory. The larger, denser objects in your scene, it'll take up more space in memory for your viewport and render. If your memory usage overloads, your system might resort to doing slow swaps with your hard drive or, worse yet, crash.
Culling and manually hiding objects will help in Cycles because it will reduce memory usage and prevent ray intersections with objects you don't care to be seen, which will improve render times at the cost of quality. But if your memory can take the scene, dense geometry won't be as dramatic a difference in performance than simple geometry as you might think.
And again, Markus von Broady perfectly explained it for Eevee.
