Why Doesn't Render Thread Time Drop After Switching to a Lower LOD, and Why Does MeshSkinning Spike When the Character Comes Back?
When a character switches to a lower LOD after moving farther away, the mesh complexity and shader cost both decrease. However, the Render Thread time remains almost unchanged. Later, when the character moves back into the near range, the Profiler shows a noticeable increase in MeshSkinning time, accompanied by another Render Thread spike. Why does this happen? Is the Render Thread actually overloaded?
An increase in Render Thread time does not necessarily mean that rendering has become more expensive. When developers notice that the Render Thread takes a larger share of the frame time, they often first look at model complexity, shader complexity, or GPU workload. However, in real projects, the Render Thread may simply be waiting for other threads to complete their work , rather than spending more time executing rendering commands. This project is a typical example. When the character moves farther away, it automatically switches to a lower detail LOD model, and the shader complexity is also reduced. Under normal circumstances, you would expect the rendering cost to decrease. However, profiling showed that the Render Thread time did not decrease significantly after the LOD switch. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/f05aeb26 d622 4647 af06 c28daae41364.png After examining the Unity Profiler, it became clear that most of the Render Thread time was spent waiting for Job Worker threads to finish their calculations . The hotspots on the Job threads were concentrated in MeshSkinning related tasks. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/b969731f 926b 4c13 b9a6 8c294f4d39f4.png It is important to note that the increase in MeshSkinning time after the character returns to the Near range is not simply caused by the higher polygon model . Based on the project's gameplay logic, when a character is far away, the game intentionally reduces the update frequency of certain calculations to lower CPU overhead. Once the character re enters the Near range, these calculations are resumed, causing a noticeable spike in Job thread execution time. Further analysis of the gameplay code showed that the Job thread hotspots were primarily related to MeshSkinning , and these calculations were associated with cloth simulation logic, such as the StartClothUpdate workflow. When the character enters the Near range, the related gameplay calculations resume, triggering skinning and deformation jobs. As a result, the Job Worker threads experience a temporary workload spike. Since the Render Thread must wait for these jobs to complete before continuing, the Render Thread time also increases. Therefore, the issue is not that the Render Thread is performing more rendering work. Instead, its execution time increases because it is waiting for tasks running on other threads to finish. For this type of issue, optimization efforts should focus on the associated gameplay calculations and update strategies, rather than attempting to optimize the Render Thread itself.