Upload of the second section to the 3D Model addendums

- Anchor Points

- Model Skins

- Geo-typical dataset

3D Model Footprint

A polygon that is tagged as Cultural Footprint can be used by client devices to identify the portion of the terrain that is covered by a model. This is useful to insert a model into the terrain by replacing the geometry generated from the elevation grid.

Must a client device that supports the Cultural Footprint attribute do so by replacing the terrain altimitry, or is it acceptable to project the footprint feature onto the underlying altimitry? It would seem desirable to have the ablity to specify either behavior as mentioned in this post with respect to runway profiles and paint markings respectively.

Adding a new addendum to clarify the 3D Model Node numbering scheme.

3D Model Footprint

A polygon that is tagged as Cultural Footprint can be used by client devices to identify the portion of the terrain that is covered by a model. This is useful to insert a model into the terrain by replacing the geometry generated from the elevation grid.

Must a client device that supports the Cultural Footprint attribute do so by replacing the terrain altimitry, or is it acceptable to project the footprint feature onto the underlying altimitry? It would seem desirable to have the ablity to specify either behavior as mentioned in this post with respect to runway profiles and paint markings respectively.

Ping.

Also, should it be assumed that if the footprint attribute is honored by integrating it into the terrain, that all areal and lineal features that were subordinate to the original terrain have been subsumed by the model?

6.4.3 Cultural Footprint

Client device that do not support footprint can simply discard those polygons.

Since polygons tagged as Cultural Footprint are not really part of the model itself, they are not subjected to the same constraints as other polygons. These polygons can be concave and their vertices are not necessarily coplanar.

It would seem that since these are optional and have different constraints than other CDB OpenFlight model polygons, that they would make the meaning of the class level complexity metrics (NIX, NNL, NTC, NTX, NVT), difficult to specify and interpret in support of client device determinism.

It would be nice, at least in the new Geo-Specified form proposed, if you could specify the skin, configuration, and possibly even the damage state of a Moving Model Location feature in the Shapefile attributes. Currently, it is only possible to statically embed the default appearance (skin, configuration, and zero damage state) of a moving model in the database.

6.4.3 Cultural Footprint

It would seem that since these are optional and have different constraints than other CDB OpenFlight model polygons, that they would make the meaning of the class level complexity metrics (NIX, NNL, NTC, NTX, NVT), difficult to specify and interpret in support of client device determinism.

Brian, the set of attributes that are complexity metrics represent hints for runtime client devices. As such, the presence of cultural footprint polygons is deemed negligeable when compared to the actual polygons representing the model. From a content-creation point of view, the footprint of a model should not be accounted for when computing these metrics. From a runtime point of view, these metrics should be interpreted as an indication of the complexity of the useful geometry in the model. However, the actual complexity of a model will be known only when the model is actually loaded. Why? Because the complexity is affected by the client itself... it depends on implementation details that are known only to the client. Example: DirectX versus OpenGL, the use of shaders, etc.

Hope this helps,

Bernard

From a content-creation point of view, the footprint of a model should not be accounted for when computing these metrics.

In that case, please include a statement in the specification that makes it clear that footprints should be excluded from model complexity metrics. Thank you.

In that case, please include a statement in the specification that makes it clear that footprints should be excluded from model complexity metrics.

Excellent suggestion Brian. We'll do!

3D Model Footprint

Must a client device that supports the Cultural Footprint attribute do so by replacing the terrain altimetry, or is it acceptable to project the footprint feature onto the underlying altimetry? It would seem desirable to have the ability to specify either behavior as mentioned in this post with respect to runway profiles and paint markings respectively.

At this point, the choice (between replacing or projecting) is left to the client device. The CDB does not dictate how to combine the 3D model and its footprint with the surrounding terrain.

The Cultural Footprint is only to be used to identify the portion of the ground that is covered by a 3D model. In certain cases, the client needs this info to remove the underlying ground. When doing so, it is understood that the client will need to stitch the terrain with the model. How this is done is left to the client.

Brian, we are having discussions between ourselves to clarify what a footprint is, why and when it becomes necessary and, finally, how to use it. The result of these discussions will be a clarified addendum.

At this point, the choice (between replacing or projecting) is left to the client device. The CDB does not dictate how to combine the 3D model and its footprint with the surrounding terrain.

I was thinking a hybrid approach might sometimes be useful where the faces marked both terrain and footprint could be discarded, while all other faces marked footprint only would be reprojected like areals.

The Cultural Footprint is only to be used to identify the portion of the ground that is covered by a 3D model. In certain cases, the client needs this info to remove the underlying ground. When doing so, it is understood that the client will need to stitch the terrain with the model. How this is done is left to the client.

To me, the term stitch, would require using the literal footprint elevation. Thus, it would forbid the hybrid reprojection approach outlined above.

Brian, we are having discussions between ourselves to clarify what a footprint is, why and when it becomes necessary and, finally, how to use it. The result of these discussions will be a clarified addendum.

I look forward to seeing the clarification and commenting on it. But as usual, I wish more people could take an active part in those discussions. Although this board is partially useful for that purpose, it is often hard to accurately convey sometimes complex opinions, and it is also difficult to collaboratively iterate ideas.

As I see it, Presagis is trying to allow their customer base to re-use their existing monolithic OpenFlight models (aka "site models") by simply applying appropriate footprint attribution rather than requiring a full "GIS export" (in Creator terms, I believe) to vector data. The KNFG Camp Pendleton airport supplied in the Terra Vista sample CDB project (as well as, I believe, in Presagis's new WWDB product) is an example of such a footprint attributed "site model". Unfortunately, large point feature models like this, that are logically a collection of individual point features, areals, and lineals, are problematic with respect to terrain conforming if the client chooses not to literally stitch in the footprint altimitry. Buildings may be floating or submerged, for instance, since they are rigidly tied together as a single large point feature. Thus, for a reasonable customer appearance, stitching does not seem optional if these types of models are to be supported at all. Using this approach, however, needlessly complicates RTP terrain publishing, makes formerly independent database layers now somewhat dependent, and may be problematic for good terrain LOD representation and load management. This approach also mixes abstract input to procedural content creation (footprints), with explicit content definitions (regular model geometry) all in one OpenFlight model. Furthermore, it has yet to be defined how to richly attribute all of these features within an OpenFlight model for things such as airport lighting controls, contaminants, etc. And, it has yet to be defined how footprints interact with other areal and linear data that they overlap.

On the other hand, while many of these issues are solved by transforming the model to vector form, this process is difficult to automate and lossy (I know as we have developed a tool internally just for this purpose). The terrain elevation profile would be lost since there are no formal definitions for an elevation constraint (not withstanding various ad-hoc FACC usages and the under defined AF_ELEVATION_CONSTRAINT). Also, lineal and areal features will at least loose texture associations and mappings, so their appearance can not be exactly duplicated. And, some footprint features are not yet representable (see a partial list of missing airport features in the CDB 3.1 Addendum - Attributions thread, for instance).

Neither method seems a robust solution for the typical needs of the simulation community. I believe, we need the strengths of both approaches combined in some way. I have recognized these weaknesses since we started developing with CDB 2.1, and although my outlook has shifted somewhat, my notion that these issues need addressing continues to grow. I hope we all can continue to evolve the CDB specification for the benefit of the entire industry.

Picking up where the CDB general discussion thread GTModels vs GSModels left off...

I have re-reviewed the Geotypical Datasets aka Geo-Specified 3D model proposal, and I see that the first set of quoted text I objected to in section 3.1.2 GTModel Datasets Directory has now been reworded appropriately. I also see that 5.3.1.4.1 Referenced by Point Features has been revised to subtly encourage more sensible model type classifications:

Natural vector features (such as trees, bushes etc.) are usually represented by geo-typical OpenFlight models. The majority of man-made features can also be geo-typical in nature. For instance, power pylons, telephone poles, residential houses, etc. can all be represented with generic models that are typical in appearance to the real-world objects they represent. The modeler need only resort to a geo-specific model if the application requires a model with the unique shape, appearance and/or properties of the real-world object.

I do, however, feel that the consequences of an improper choice should be made more explicit by citing an example so that a more than subtle encouragement to make the appropriate model type choice is embodied in the specification. Furthermore, I believe this is an important enough recommendation that at least a cross-reference to the this classification criteria and more explicit cautioning example should be made somewhere in the analogous section 3.1.4 GSModels Datasets Directory, most likely in section 3.1.4.11 GSModel Dataset Files.

I believe it is quite common to create a geo-specific geometry that uses geo-typical textures on parts, if not all, of the model. I believe the 3.1 Geo-Specified proposal should be amended to allow this mixed usage model for similar reasons. The reverse usage pattern is probably rarely useful, however.

The modification enables both the sharing of geometry (GT) across a CDB and the sharing of texture across a CDB - for both GT & GS model.

This reply would seem to indicate that the Geo-Specified proposal does allow for a geo-typical texture to be referenced by a geo-specific model. Alas, I could not find any such allowance.

I assume that whatever was lost by reversing the model type classification criteria with respect to the quote of point 2.) (client device memory optimization hint) can be roughly replaced by the per tile NIS attribute (which incidentally could definitely use a clearer definition in section 5.3.1.2.2 Instance-level ATT Attributes ).

I still strongly disagree with the method recommended to resolve the client specific geo-typical model representation quoted in point 3.), and I recommend that an alternate means to request an explicit representation of a geo-typical model be specified as part of the Geo-Specified proposal. It is unfair to penalize all client devices, as well as database disk usage, by converting geo-typical models to geo-specific ones, simply because a single client specific appearance is undesirable.

I'd also like to make two new comments with respect to the Geo-Specified proposal:

For moving models, I hope that the OpenFlight entry/header file containing the exact significant size LODs with external references to the individual LOD and other component files will remain as more than a temporary 3.0 compatibility bridge since I believe this method of reference is the more common usage pattern.

As for the global texture naming changes from the W44 to L44 form, combined with the loose criteria defined in section 6.13.4 Texture Mipmap (note that this section still needs to be revised with respect to the W->L proposed change) for the minimum file size where the Mip-Map decimation should stop for non-square textures, I still have reservations about the loss of the W term (texel dimensions) in the texture name.

The only way to determine the range of L available for a particular texture pattern now due to these changes is to examine the 6.15.5 Model Textures Mipmap metadata field. This is problematic because the model metadata can only be found using the model name. This even more tightly couples the model geometry and model texture layers at run-time which is a disadvantage for many architectures where geometry and texture do not meet until then (after publish time).

The range is useful to determine the available resolutions when demand paging texture resolutions. Otherwise, either a sequentially decreasing L number file hunt inside zip archives is necessary, or the high resolution pattern must be read from the high resolution zip archive just to determine the pattern size and attributes; neither of which is a scalable solution. Since with only the texture name available the model metadata can not be located, the best solution I've come up with is to encode the Mip-Map limits into the texture name when publishing the model geometry. Thus, this provides the RTP texture publisher with enough information to calculate the available L number mips, the maximum pattern size, and to determine the pattern attributes while loading a low resolution mip for coarse initial coverage.

Please consider this disadvantage to certain client architectures when making the decision to eliminate all use of the W term in texture naming conventions. Please also ask for more problem clarification if necessary, or feel free to suggest alternate methods to satisfy this usage pattern that I might have overlooked.

As usual, thank you for your time, thoughtful responses, understanding, and willingness to evolve the CDB specification toward the common good.

Thank you for the feedback. I think you highlighted some error on our part. We will review during the weekend and most likely provide an update on Monday.

For moving models, I hope that the OpenFlight entry/header file containing the exact significant size LODs with external references to the individual LOD and other component files will remain as more than a temporary 3.0 compatibility bridge since I believe this method of reference is the more common usage pattern.

Please forgive me if I have previously mentioned this, but since I can not seem to locate a reference...

On a related note, I would encourage that the exact significant size of a geo-specified model, along with the significant size of the next finer exchange LOD version of that model, when it exists, be stored in the model metadata information. Doing so would prevent the loss of this exact LOD information (for instance, in the case that the CDB is being used as a source repository, or in the case that a geo-specific model needs to be converted to a 3.0 geo-typical one), and it would make this exact information available to client devices, which together with the next finer exchange LOD significant size, would convey LOD lifetime information (ie. at what significant size could this model next be exchanged for a finer representation).

3D Model Footprint

A polygon that is tagged as Cultural Footprint can be used by client devices to identify the portion of the terrain that is covered by a model. This is useful to insert a model into the terrain by replacing the geometry generated from the elevation grid.

I wanted to point out a significant performance and scalability problem that we have recently realized with respect to implementing this feature. Since a Cultural Footprint may affect the terrain, and since it is stored in a 3D Model, which is in turn referenced by a Vector Point feature in a List-Organized Tile dictated by the 3D Model's center (and Significant Size), then in order to find all Cultural Footprints that might affect a particular Terrain Elevation tile, one must load not only all overlapping 3D Model Vector tiles, but also all adjacent tiles, in order to find any Cultural Footprints that might overlap into the terrain elevation tile of interest. This is a dramatic increase in the number of files that can effect a particular elevation tile.