| // Copyright (c) 2018-2020 NVIDIA Corporation |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_NV_corner_sampled_image.txt[] |
| |
| === Other Extension Metadata |
| |
| *Last Modified Date*:: |
| 2018-08-13 |
| *Contributors*:: |
| - Jeff Bolz, NVIDIA |
| - Pat Brown, NVIDIA |
| - Chris Lentini, NVIDIA |
| |
| === Description |
| |
| This extension adds support for a new image organization, which this |
| extension refers to as "`corner-sampled`" images. |
| A corner-sampled image differs from a conventional image in the following |
| ways: |
| |
| * Texels are centered on integer coordinates. |
| See <<textures-unnormalized-to-integer, Unnormalized Texel Coordinate |
| Operations>> |
| * Normalized coordinates are scaled using [eq]#coord {times} (dim - 1)# |
| rather than [eq]#coord {times} dim#, where dim is the size of one |
| dimension of the image. |
| See <<textures-normalized-to-unnormalized, normalized texel coordinate |
| transform>>. |
| * Partial derivatives are scaled using [eq]#coord {times} (dim - 1)# |
| rather than [eq]#coord {times} dim#. |
| See <<textures-scale-factor,Scale Factor Operation>>. |
| * Calculation of the next higher lod size goes according to |
| [eq]#{lceil}dim / 2{rceil}# rather than [eq]#{lfloor}dim / 2{rfloor}#. |
| See <<resources-image-miplevel-sizing,Image Miplevel Sizing>>. |
| * The minimum level size is 2x2 for 2D images and 2x2x2 for 3D images. |
| See <<resources-image-miplevel-sizing,Image Miplevel Sizing>>. |
| |
| This image organization is designed to facilitate a system like Ptex with |
| separate textures for each face of a subdivision or polygon mesh. |
| Placing sample locations at pixel corners allows applications to maintain |
| continuity between adjacent patches by duplicating values along shared |
| edges. |
| Additionally, using the modified mipmapping logic along with texture |
| dimensions of the form [eq]#2^n^+1# allows continuity across shared edges |
| even if the adjacent patches use different level-of-detail values. |
| |
| include::{generated}/interfaces/VK_NV_corner_sampled_image.txt[] |
| |
| === Issues |
| |
| . What should this extension be named? |
| + |
| -- |
| *DISCUSSION*: While naming this extension, we chose the most distinctive |
| aspect of the image organization and referred to such images as |
| "`corner-sampled images`". |
| As a result, we decided to name the extension NV_corner_sampled_image. |
| -- |
| |
| . Do we need a format feature flag so formats can advertise if they support corner-sampling? |
| + |
| -- |
| *DISCUSSION*: Currently NVIDIA supports this for all 2D and 3D formats, but |
| not for cube maps or depth-stencil formats. |
| A format feature might be useful if other vendors would only support this on |
| some formats. |
| -- |
| |
| . Do integer texel coordinates have a different range for corner-sampled images? |
| + |
| -- |
| *RESOLVED*: No, these are unchanged. |
| -- |
| |
| . Do unnormalized sampler coordinates work with corner-sampled images? Are there any functional differences? |
| + |
| -- |
| *RESOLVED*: Yes. |
| Unnormalized coordinates are treated as already scaled for corner-sample |
| usage. |
| -- |
| |
| . Should we have a diagram in the "`Image Operations`" chapter demonstrating different texel sampling locations? |
| + |
| -- |
| *UNRESOLVED*: Probaby, but later. |
| -- |
| |
| === Version History |
| |
| * Revision 1, 2018-08-14 (Daniel Koch) |
| - Internal revisions |
| * Revision 2, 2018-08-14 (Daniel Koch) |
| - ??? |
