In (UE4 4.27) UHierarchicalInstancedStaticMesh (HISM) principle analysis, this blog briefly introduces the reconstruction of KD-Tree and the elimination and submission of DrawCall logic of the HISM component from the game thread to the rendering thread, but does not analyze the general data structure and implementation of the rendering layer.
Related data structures of FHierarchicalStaticMeshSceneProxy
It can be seen that FHierarchicalStaticMeshSceneProxy actually stores the Instance array data from FInstancedStaticMeshSceneProxy
FHierarchicalStaticMeshSceneProxy only builds a Kd-Tree with FClusterNode, and stores and manages the Instance index in the form of KD-Tree. For details on how to manage it, you can read the previous introduction to HISM.
FInstancedStaticMeshRenderData
This data structure is the core data class of HISMProxy and ISMProxy, and is responsible for the direct binding of StaticVertexBuffer, InstanceVertexBuffer (Transform of each instance) and VertexFactory (FInstancedStaticMeshVertexFactory).
VertexBuffer
Rendering data from UStaticMesh
InstanceBuffer
FPerInstanceRenderData from ISM component management
FPerInstanceRenderData specifically uses FStaticMeshInstanceBuffer to manage the InstanceVertexBuffer resource of the rendering thread.
FInstancedStaticMeshVertexFactory
Directly inherit FLocalVertexFactory, mainly to rewrite the vertex format, because Instance batch rendering needs to read InstanceData (WorldTranform, etc.) in VertexShader, but Instance batch rendering generally has two implementation methods:
The first is that InstanceData is directly used as part of VertexBuffer, and the vertex can directly obtain the WorldTranform of the Instance where it is located. Refer to DirectX 11 Study Notes-Part2-1 [Instancing]
The second type is that the Instance data is created independently as a Buffer. The vertex data only contains the InstanceId. Each time the InstanceData is retrieved, the InstanceId must be retrieved from the InstanceBuffer. This is more common in the GPU Driven rendering pipeline. GPU Driven Rendering uses a large number of various Buffers. Reading the Buffer directly can better avoid CPU readback. Refer to Unity to implement GPU Cull rendering.
The second method in UE engine rendering is called manual vertex acquisition (MANUAL_VERTEX_FETCH)
Currently, UE5 Mobile (either OpenEs or Vulkan) does not support MANUAL_VERTEX_FETCH. Delayed rendering on the PC side is implemented by GPU Driven Cull Instance, and MANUAL_VERTEX_FETCH is supported by default. (Digression: Mobile-side Instance batch rendering has not yet implemented GPU Driven's DrawInstancedIndirect. Those who are interested can study the GPUScene of UE5 PC-side deferred rendering pipeline, which implements complete Instance GPU Cull and DrawInstancedIndirect. The summary is that UE5 Mobile is completely based on DrawInstance for CPU culling, UE5 PC side is DrawInstancedIndirect based on CPU culling and GPU culling)
InstanceData acquisition of LocalVertexFactory.ush
Code implementation, after compiling MANUAL_VERTEX_FETCH to false, it can be seen that InstanceData is obtained through InstanceVertexBuffer . As shown below:
