1.) The following sections of the CDB 3.0 specification discuss the set of file types and naming conventions used to represent Geo-Specific features in ZIP file archives:

3.1.4.11.1 Geo-Specific Model Representation File Naming Conventions within the zip file

3.1.4.11.2 Examples

5.5.5.1 Archived GSModel Datasets

Conspicuously absent from this discussion are the OpenFlight Texture Attribute (.attr) files which are supported by CDB as notated in Appendix C OpenFlight v16.0 Technical Description - Annotated. It appears that using these files is the only CDB specified method for indicating certain texture attributes such as the u and v wrap methods. This leads to the following questions:

a.) Are texture attribute files supported in Geo-Specific feature ZIP file archives?

b.) If not, what other method of representing those attributes is specified?

c.) If so, what are the naming conventions used for them?

d.) Are they required or optional?

e.) If optional, what default values should be assumed?

Note that the answers to questions c-e appear to be equally under specified for non-zip archived Geo-Typical features.

The naive answer to b.), based on my understanding of typical OpenFlight semantics, would be to store a single texture attribute file named similar to, and contained in the same ZIP archive as the corresponding finest resolution texture pattern. Doing so, however, would destroy client device determinism and database content scalability because the ZIP archive bundling all the finest resolution texture patterns in a particular region would need to be accessed in order to determine the attributes for the coarsest resolution texture pattern needed for display.

2.) Section 5.5.5.1 Archived GSModel Datasets states:

When geospecific 3D models are archived into a single ZIP file, the component

selectors have fixed values of 001 as illustrated in the following table.

The use of the term "When" implies that ZIP file encoding is conditional on something, or that it might be optional sometimes.

a.) When is ZIP archiving of Geo-Specific feature data not required or optional?

Fixing component selector values to 001 implies that many feature types (such as seasonal and skin base textures, as well as all subordinate textures) can not be ZIP archived.

b.) Why was this restriction imposed?

The following statement provides at least a partial justification for why ZIP file archives containing Geo-Specific feature data are used in CDB 3.0 databases:

3.1.4.9 File Naming Convention for "UREF" Directory

To improve disk file access performance, all geo-specific OpenFlight model geometry, model signature, textures and materials within their corresponding tiled directory are zipped into one single file.

The resulting spatially organized data structure that is further bundled by significant size, significant angle, or texel resolution, is critically important to deterministic client device behavior while supporting the near infinite database content spirit of the CDB specification. Given this justification, it makes little logical sense to only provide (require?) this enhancement for certain feature types.

c.) Shouldn't this restriction be removed by specifying the use of individual ZIP archives for each dual component selector combination?

Hi Brian, we're currently reviewing your questions and we will provide the answers soon.

This is a partial answer, but I though it would be useful to provide to you while we're working to gather the rest of the answers.

Partial answer to question 1 about OpenFlight Texture Attribute (.attr) files:

The CDB Specification does not rely on the presence of .attr files to determine the wrap methods, the mapping techniques, or the texture resolution.

The mapping techniques, listed in the Texture Environment field of the .attr file, are specified in section 6.13.10 Texture Mapping.

The Wrap Method is always assumed to be Repeat for both U and V coordinates. The wrap method affects only textures whose UV coordinates exceed the range [0, 1]. Section 6.15.5 Model Textures specifies how to define texture <Coverage> for both U and V coordinates.

The texture resolution, defined by the Real World Size fields of the .attr file, is instead specified in the Model Metadata as defined by the field <Resolution> also defined in section 6.15.5 Model Textures.

This is a partial answer, but I though it would be useful to provide to you while we're working to gather the rest of the answers.

I appreciate all the clarification you can provide, and the work it takes you to do so, even if it is incremental. Thank you.

The Wrap Method is always assumed to be Repeat for both U and V coordinates.

I can not find anywhere in the specification or its appendicies where this is stated. I gather that this may be an implicit historical OpenFlight assumption, but even so I would suggest that specification verbiage be added to make it explicit. If there is a section I missed that specifies this behavior, please point me to it. The section you refer to below is the only additional reference I could find via a global search for repeat and wrap (besides the OpenFlight Texture Attribute File definition discussed in my original post, that is).

Section 6.15.5 Model Textures specifies how to define texture <Coverage> for both U and V coordinates.

I cite the applicable section below for context:

6.15.5 Model Textures

The texture coverage is optional and defines the minimum and maximum values for the U and V texture coordinates. This information indicates if the texture is repeated along one or both axes.

...which would logically tend to indicate that a texture should only be considered to repeat if its application includes a U or V coordinate outside the 0-1 range, not as a default behavior. Note that providing this information is specified as optional, however. Furthermore, there is no specified way to convey the desired repeat behavior of wrap vs mirror via this method.

Also, the CDB specification philosophy is to avoid redundancy of data unless it is generally accepted by the industry as a performance necessity. I wouldn't consider this to be an example of that type of need. In that light, the specification should be amended to remove one set of redundant data, which is most likely the texture attribute files. This could be accomplished by specifying a default clamp behavior when the UV coverage information is not present, and by requiring coverage data with an accompanying wrap mode when wrapping is desired.

I also think extent would be a better term than coverage to describe the UV ranges.

The wrap method affects only textures whose UV coordinates exceed the range [0, 1].

Although this is logically true, texture coordinates outside the 0-1 range can often be accessed by graphics hardware when processing polygonal edge boundaries, even when the original polygon mapping is within the 0-1 range. In these cases, proper texture filtering requires the proper wrap mode (clamp) to prevent edge artifacts. As such, I believe a default of repeat is a poor choice.