Why Does an Additional Camera Consume High Rendering Time Even When It Only Renders One Model?
We added an extra Camera to prevent a specific model from being affected by the Near Clip Plane. This Camera is only enabled in certain gameplay scenarios and is responsible only for rendering that model. However, in some close up viewing situations, if the model is too close to the Camera, it may be clipped by the Near Clip Plane, causing parts of the model to disappear. To solve this issue, we introduced a separate Camera with customized clipping settings to render the model independently. According to the GameOptim GOT Online report, the average cost of this Camera during testing is already close to that of the always active UI Camera. Since it only renders a single model, why does it still introduce such a significant performance cost? How should this be optimized? https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/b27e89e8 c8c5 4c2a a5e4 52acab8ab597.png
Adding an additional Camera is a common approach when special rendering requirements need to be satisfied. However, the cost introduced by a Camera is not only determined by how many objects it finally renders. Even if the final output only contains a small amount of content, each additional Camera still needs to independently perform rendering preparation, visibility determination, render queue processing, and command submission. Therefore, the number of rendered objects does not always directly represent the actual cost introduced by the Camera itself. From the Stacks section in the GameOptim GOT Online report, we can observe that there are two Cameras in normal scenarios. After entering the specific gameplay mode, the number increases to three, and during the cutscene stage, it increases to four. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/3e77f0c1 7994 4991 8d82 67409690d5c3.png By tracking changes in the number of Cameras, we can quickly identify in which scenarios the additional Camera is enabled and verify whether the Camera count matches the expected design. Although this additional Camera is only used to display a single model, its average cost has already become close to that of the UI Camera, which is always active. The responsibilities of these two Cameras are different, so we cannot directly conclude that there is a configuration issue simply because their costs are similar. However, for an additional Camera like this, the performance cost should not be ignored. During investigation, you can first check the Camera related timing stacks to determine how much time is spent on Camera pipeline nodes such as Culling . Then, compare three different configurations: Keep the original Camera configuration Adjust the Camera settings, such as the Culling Mask Disable the Camera completely This comparison helps distinguish between the actual model rendering cost and the additional overhead introduced by the Camera pipeline itself. The Camera configuration should also be reviewed item by item. Features such as: Shadow rendering Post processing Occlusion Culling Independent RenderTexture usage should all be checked to confirm whether they are actually required. After enabling a cutscene Camera, you should also verify whether the main scene Camera and other additional Cameras are still rendering. Otherwise, even if the screen is already covered by another Camera, the hidden Cameras may continue executing the complete rendering process and introduce unnecessary cost. During optimization, the first priority should be controlling when the additional Camera is enabled . The Camera should only be activated when the model actually requires independent rendering, and any features unrelated to the current display requirement should be disabled. After simplifying the configuration, if the cost remains high, you can further evaluate solutions based on the rendering pipeline being used in the project. For example, consider whether the model can be integrated into the existing Camera rendering flow, or whether alternatives such as Renderer Feature can replace the additional Camera approach. The analysis above does not mean that additional Cameras should never be used. The key consideration is whether the visual benefit provided by the Camera is worth the performance cost it introduces. When a Camera that is only responsible for displaying a single model already consumes almost the same amount of time as a permanent UI Camera, it should become a priority optimization target. Otherwise, a local rendering requirement may end up maintaining an additional rendering pipeline throughout the project lifecycle.