Please post your suggestions and recommendations for this addendum.

1.) <b>Runway Contaminant</b>

To make this subordinate texture type useful for training tasks instead of as a simple visual enhancement, a correlated material coded texture must also be available to support braking and other vehicle dynamics as well as proper sensor presentation. Is there any plan to support this correlated subordinate texture type?

2.) <b>Branch of Service</b>

What subordinate texture skin mechanism is used to differentiate the appearance of a vehicle painted for a specific armed service? For instance, how would one depict the color, paint, and marking differences between a US MV and CV 22 aircraft? It would seem that no combination of the defined Uniform, Camouflage, or Airline selector descriptions is appropriate, although Uniform would seem the logical choice if the codes weren't color based.

3.) <b>Detail Texture</b>

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture. As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

2.) <b>Branch of Service</b>

What subordinate texture skin mechanism is used to differentiate the appearance of a vehicle painted for a specific armed service? For instance, how would one depict the color, paint, and marking differences between a US MV and CV 22 aircraft? It would seem that no combination of the defined Uniform, Camouflage, or Airline selector descriptions is appropriate, although Uniform would seem the logical choice if the codes weren't color based.

Upon further study, I see that this could be covered by the DIS classification code, but that would dictate two different copies of the model geometry I believe.

1) <b>Runway Contaminant</b>

To make this subordinate texture type useful for training tasks instead of as a simple visual enhancement, a correlated material coded texture must also be available to support braking and other vehicle dynamics as well as proper sensor presentation. Is there any plan to support this correlated subordinate texture type?

This is a valid suggestion that we will consider for future enhancement to the Spec.

3) <b>Detail Texture</b>

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture.

Correct. We will propose a definition for Detail Texture.

As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

Brian, is the proposed definition of Tangent-Space Normal Map unclear? I am surprised because I think the description (format and usage) is complete.

Regarding point 2) above, DIS classification codes can be found in SISO-REF-010. All variants of the Bell/Boeing V-22 Osprey have a DIS Entity Type of 1-2-225-4-17-0-0. There are specific types for models such as the CV-22A (1-2-225-4-17-1-0) or MV-22B (1-2-225-4-17-12-0).

Yes, variants of a DIS entity are different CDB Models.

Note that DIS handles markings using other attributes. As such, two instances of the same entity (CDB Model) can have different markings (e.g. vehicle number)... but that is not covered by CDB... yet.

FYI... SISO-REF-010 can be found on //www.sisostds.org/ by searching the File Library.

3.) <b>Detail Texture</b>

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture. As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

Brian, is the proposed definition of Tangent-Space Normal Map unclear? I am surprised because I think the description (format and usage) is complete.

No, that is a mis-communication. I was simply making the analogy that Detail Texture is as unclear in the current 3.1 proposal as was Bump Map in CDB 3.0. Since for 3.1 Bump Map was deprecated in favor of the more well defined Tangent-Space Normal Map, I was hoping to avoid the same problem with respect to Detail Texture in 3.1. I hope that makes the intent of my statement more clear.

While trying to apply the 3.1 addendum Material Textures on 3D Models , we have discovered that, especially for geo-typical material textures, having those textures refer to a composite material table contained in the 603 Model Metadata dataset is problematic. Conflict resolution for composite material codes is complex when multiple models share material coded textures. As such, we would recommend that the addendum specify instead a composite material table per texture similar, to the Raster Material dataset, to keep the composite material code namespaces independent and remove the conflict resolution problem.

Very good point Brian, you just pointed out a design issue with the 3D Model Material Texture dataset... the presence of a cyclic dependency between datasets. To promote texture reuse, it is necessary that a texture does not refer to a specific model and its metadata.

Your suggestion is appropriate; a dedicated texture CMT dataset is necessary here to break this dependency... in a way that is similar to the pair of Terrain Raster Material datasets 005 and 006.

Very good point Brian, you just pointed out a design issue with the 3D Model Material Texture dataset... the presence of a cyclic dependency between datasets. To promote texture reuse, it is necessary that a texture does not refer to a specific model and its metadata.

Your suggestion is appropriate; a dedicated texture CMT dataset is necessary here to break this dependency... in a way that is similar to the pair of Terrain Raster Material datasets 005 and 006.

This is a major flaw in the design of model material textures in CDB 3.1. Are there plans to address this in CDB 3.2?

You're right... an addendum is in preparation for 3.2 to address this issue.