Vulkan为何支持CUBE_ARRAY图像视图却未提供3D数组类型

先附上问题中提到的VkImageViewType枚举定义方便对照：

typedef enum VkImageViewType {
    VK_IMAGE_VIEW_TYPE_1D = 0,
    VK_IMAGE_VIEW_TYPE_2D = 1,
    VK_IMAGE_VIEW_TYPE_3D = 2,
    VK_IMAGE_VIEW_TYPE_CUBE = 3,
    VK_IMAGE_VIEW_TYPE_1D_ARRAY = 4,
    VK_IMAGE_VIEW_TYPE_2D_ARRAY = 5,
    VK_IMAGE_VIEW_TYPE_CUBE_ARRAY = 6,
} VkImageViewType;

为什么不存在3D纹理对应的数组视图类型？ #

根本原因是3D纹理的语义和_ARRAY后缀视图的设计逻辑完全冲突，这个类型没有实际存在的价值。
所有带_ARRAY后缀的视图，核心设计语义是统一的：数组内的每一层是完全独立的资源实例，采样时层与层之间不会做跨层过滤，采样阶段需要显式传入要访问的层索引。
但3D纹理的Z维度本身就是纹理内容的组成部分，是参与三线性过滤、各向异性过滤的连续维度。如果硬要做一个VK_IMAGE_VIEW_TYPE_3D_ARRAY，连最基础的过滤规则都没法定义：到底Z轴是做连续体积插值，还是像数组层一样完全隔离？硬件层面也没有对应的寻址逻辑支持这种矛盾的行为。
如果实际开发中需要存储多个独立的3D纹理，直接用VK_IMAGE_VIEW_TYPE_2D_ARRAY按顺序存储所有3D纹理的切片即可，在着色器里手动计算索引就能实现完全一致的效果，完全不需要API冗余定义一个新视图类型，徒增硬件实现的复杂度。

CUBE_ARRAY的实际适用场景是什么？ #

VK_IMAGE_VIEW_TYPE_CUBE_ARRAY本质就是一捆独立的立方体纹理，每6个连续数组层对应一个完整的cubemap，是工业级渲染管线里非常常用的资源类型，常见落地场景包括：

• 多点光源阴影存储：点光源的阴影需要用cubemap记录6个方向的深度值，常规场景里通常会有十余个甚至更多动态点光源，把所有点光源的阴影cubemap打包进一个CUBE_ARRAY，只需要绑定一次资源，绘制时传入光源索引即可访问对应阴影，能大幅减少描述符切换的开销。
• 反射探针阵列：不管是离线烘焙还是实时生成的全局光照系统，场景内都会布置大量反射探针，每个探针存储一个预滤波的环境cubemap。把所有探针打包为CUBE_ARRAY后，着色器可以根据像素位置直接索引相邻探针采样插值，实现平滑的反射过渡，不需要维护大量独立的cubemap绑定槽。
• VR/多视口渲染：立体渲染需要为左右眼生成独立的环境贴图、阴影贴图，用CUBE_ARRAY存储不同视口对应的cubemap资源，渲染对应视口时直接索引即可，不需要反复切换纹理资源。

注意：创建CUBE_ARRAY视图时，底层图像必须开启VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT创建标志，且总数组层数必须是6的整数倍。

有没有对应的立方体数组采样器？ #

不存在单独的“立方体数组专用采样器”类型。Vulkan的采样器对象本身不绑定视图类型，只要创建图像视图时指定为VK_IMAGE_VIEW_TYPE_CUBE_ARRAY，将其绑定到着色器对应的samplerCubeArray（GLSL）/TextureCubeArray（HLSL）类型描述符上即可正常采样。
采样CUBE_ARRAY时传入的坐标是4维向量：前3个分量是普通cubemap采样需要的方向向量，第4个分量是要访问的立方体在数组中的序号——注意这里传的是立方体的序号不是数组层序号，硬件会自动将序号乘6计算对应起始层，不需要手动换算。

内容的提问来源于stack exchange，提问作者Zebrafish