Miscelaneous Conflicting 3.0 Specification Statements and Errata
C
Craig
started a topic Thursday, Nov 17, 2016
Original Post by: ccbrianf Mon Sep 14 20:41:39 2009
I plan to use this thread as a vehicle to report a running list of what I believe are intuitively reconcilable conflicting or incorrect CDB 3.0 specification statements and typographical errors. I hope this will result in their correction in future CDB specification versions. If my assumptions about their proper resolutions are incorrect, please comment; otherwise, no formal response is required. Thank you.
Here are a few to get started:
1.) Texture Mip-Map LOD
a.) I presume the following quote should be adjusted to match the philosophy presented by the second?
3.3.2.1.2 GSModelTexture Level-of-Details
1. Mip-Map level down to 1 [del]texture[/del] texel must be generated.
2. Non-square textures are allowed. However every dimension must be a power of 2. Mip-Map level stops when one dimension reaches 1 texel.
6.13.4 Texture Mipmap
In addition to the above rules, the Specification suggests that the dimension of the smallest texture mipmap be 16 texels. The reason for this suggestion is to avoid creating an RGB texture whose 512-byte header is far more important than the actual image in that file.
To illustrate this convention, take the example of an RGB texture whose dimension is 32 by 32 texels; the corresponding power of 2 is 5, the smallest mipmap is 4 by 4 texels, and the texture directory contains four files numbered W02 to W05.
For a rectangular texture of 128 by 32 texels, its largest dimension is 128 (27), and the smallest mipmap measures 8 by 2 for a total of 16 texels. For that texture, there will be five files numbered W03 to W07.
b.) A consistent use of the term mipmap (or Mip-Map as desired) throughout the document would be advisable.
2.) Significant Size
a.) A global search and replace translating significance size to significant size would make the term usage consistent.
2. The LOD [del]significance[/del] significant size of the coarsest representation is always equal to the model height.
6.8.1 LOD Significant Size
Note, that in the case of the coarsest LOD, the Significant Size should be set to the bounding sphere dimension of the model (because the ââ¬Åerrorââ¬Â introduced by the coarsest LOD amounts to the entire model)
b.) The definition for a model's initial significant size should be consistent. The model height might be an acceptable significant size approximation for a feature that uses the roof-line attribute since that eliminates one face from contributing contrast, otherwise the latter definition might be more applicable.
I have an alternate proposal for how to calculate and explain significant size, but I will present that in a different thread.
6.8.1 LOD Significant Size
When assigning a Significant Size to a model LOD, the modeler needs to answer the following question: When I created a new model LOD, I did so to create additional detail in my model. What is the smallest dimension of the new polygonal geometry I have added to my model that justifies the need for a new model LOD? In other words, what is the smallest dimensional difference of a surface between this LOD and the next coarsest LOD? In effect, the value of Significant Size corresponds to the ââ¬Åmodeling differenceââ¬Â between the LOD and the next coarsest LOD.
c.) Shouldn't that say largest dimensional difference?
3.) JPEG/JFIF (*.jpg) model texture support
I believe the supported texture pattern file format table in Section 3 Texture Files of Appendix C OpenFlight v16.0 Technical Description - Annotated is incorrectly annotated to state that JPEG is a CDB supported format for OpenFlight model textures since the comprehensive file format list in section 4.0 CDB File Formats does not include it.
1 Comment
C
Craig
said Thursday, Nov 17, 2016
Original Post by: David.Nadeau Tue Sep 15 17:01:06 2009
Hi Brian, your assumption in regards to resolutions are correct and thank you for your support/contribution in making the CDB Specifcation better. We will work to include these errata/correction into the CDB 3.1 Spec.
Craig
I plan to use this thread as a vehicle to report a running list of what I believe are intuitively reconcilable conflicting or incorrect CDB 3.0 specification statements and typographical errors. I hope this will result in their correction in future CDB specification versions. If my assumptions about their proper resolutions are incorrect, please comment; otherwise, no formal response is required. Thank you.
Here are a few to get started:
1.) Texture Mip-Map LOD
a.) I presume the following quote should be adjusted to match the philosophy presented by the second?
b.) A consistent use of the term mipmap (or Mip-Map as desired) throughout the document would be advisable.
2.) Significant Size
a.) A global search and replace translating significance size to significant size would make the term usage consistent.
b.) The definition for a model's initial significant size should be consistent. The model height might be an acceptable significant size approximation for a feature that uses the roof-line attribute since that eliminates one face from contributing contrast, otherwise the latter definition might be more applicable.
I have an alternate proposal for how to calculate and explain significant size, but I will present that in a different thread.
c.) Shouldn't that say largest dimensional difference?
3.) JPEG/JFIF (*.jpg) model texture support
I believe the supported texture pattern file format table in Section 3 Texture Files of Appendix C OpenFlight v16.0 Technical Description - Annotated is incorrectly annotated to state that JPEG is a CDB supported format for OpenFlight model textures since the comprehensive file format list in section 4.0 CDB File Formats does not include it.