Thoughts on 3D Models in CDB

High Level Objective: 3D models should be easy to create, share and maintain

Current CDB is lacking as a transmittal format for models. Why?

The 1.x specification forces models and their associated textures to be segregated.
GS models are separate from their ‘instance points’
Models are separate from their metadata (xml descriptors)
Models are separated from associated light point nodes – lights are migrated out of model into separate vector datasets (airport and environmental)
Model interior geometry is segregated from the visual geometry
GS models are broken into separate files, based on LOD

Therefore, once models are inside a CDB, they become essentially impossible to edit and maintain.

CDB 2.x Possibilities:

Current CDB’s elaborate rules about models, and the resultant pre-processing (from source model to CDB model) attempts to make models friendlier to real-time rendering systems. It might be time to abstract models away from the original 15-year-old ‘rendering performance’ design.
Do away with the notion of GS vs GT models. A model is a model is a model.
Do away with model instances – particularly for single-use GS models. Why can’t the model’s location be a metadata component? The OpenFlight header record can store location. A transform record can store a model’s real-world orientation and any vertical translation. Or, vertices in a model may contain ‘altitude from spheroid’ for z values, rather than offsets from its origin.
Make models completely self-contained. Store various geometry representations like LODs, single-use textures, meta data, interiors, etc. inside a single container. Perhaps a ‘zip file per model object’ approach.
Open up support for formats in addition to OpenFlight – such as GLTF, OBJ, etc. Use metadata descriptors to provide LOD and switch functionality, linked to separate geometry objects (files) in the transmittal container.
A model container concept (zip file?) would make it easy to share, modify, and replace models.
This approach anticipates platform-specific pre-processing. A model 'compilation process' can reduce the transmittal object into fast loading/rendering objects, including optimizing storage (size, disk location, caching) for rapid paging and texture management.
In the absence of (or along side) the platform pre-processing step, a rendered could operate in 'immediate mode' where model containers are inspected 'as is', their metadata absorbed to inform the scene graph, and model geometry components read and converted to renderable objects 'on the fly'.

I agree with some of this. I want to add some comments to think about.

A lot of tools might have separated the model and light points, we didn't really do that with our CDB creation. So I think that is up to the implementation.
LODs were separated because for flight simulation (and I would think other types of visualization would benefit from this too), you don't want to load the entire high resolution model if it is 60 miles away. We (FlightSafety) do partially agree with this, as having a way to identify all the LODs of a GS model and knowing when they turn on/off is very useful.
Interior geometry was separated because not all simulation needs to load all of that geometry. They should be linked together somehow, but I do not agree about combining them. And for ground simulation, what happens if every building in an urban environment has an interior. At some point they need to be turned off.
In CDB, it is quite common to have either models from a library placed many, many times, and textures that are used across many models. I think that was the goal of the GT library, to have a set of models and textures that are reused a bunch.
So most of the critiques here, I am reading as against the GeoSpecific CDB models, and most of them are valid. There is still a place for a library of generic models and textures.

CDB 2.0 Possibilities

I would love to get away from the GT vs GS terminology, since different domains call different things GeoSpecific. Maybe library model vs specific model.
Model instances are hard to get away from for library models. If I have 10 million copies of a tree in a tile, I don't want to parse 10 million versions of the same model geometry just to figure out where to place it. I could see that for specific (GS) models, but worry that finding models to place might require reading in a bunch of model header data.
Putting everything that a (GS) model needs in one place can be good (exterior, interior, textures (visual and multi-spectral), descriptor xml, material textures, etc). As long as the client can ignore the data it doesn't need to load. Say a GeoPackage with a table containing everything that the model needs, but different blobs for the different parts of that model?
Adding too many model formats might tend to fragment the support for CDB. I think the model group is already looking at glTF
To this point, pre-processing has been frowned upon by the mission rehearsal community. Everyone we have talked to with a CDB doesn't want it touched or modified before rendering.
Placing burdens on the renderer by telling it how to do its job should be outside the scope of the standard.

One thing missing here is the distinction between CDB for runtime simulation, and CDB for source repository that was talked about on the miro board. For editing models, keeping them together is really important. For vis/sim, splitting them apart or optimizing the layout to help provide determinism in loading is really important.

Ryan - I agree with your review, almost entirely. Here are a few follow-up comments...

I should have stressed that I see an expansion of current 3D model metadata, so that it can contain a complete inventory of 3D model components - perhaps providing a high level abstraction of levels of detail and switch nodes.
the notion I have in mind for a 'model container' is more a 'file that contains files' (zip?) rather than a relational database with blobs. Think of this as a single location that substitutes for all of the pieces and parts of a model scattered around 1.x CDB datasets and tiles.
first you comment that mission rehearsal frowns on pre-processing -- then describe the pre-processing that is inherent in the current CDB spec, regardless of application. The concept I envision keeps a model's component parts in a single container (zipfile or folder) making maintenance / replacement more viable. (I'd wager that every model in every existing CDB lives in its 'original' state somewhere)
I am not suggesting that the GT model library, or instancing points for GT features be eliminated. Rather than all models have the same nature, in terms of how they are stored, particularly in terms of their LODs. We're missing a simple scheme for instancing frequently used, shared texture maps. Still, it makes sense that single-use geospecific models are 'self-aware' of their location on the earth.
the scope for 'pre-processing' models is flexible. It could be a target-specific compiler, or perhaps light weight, similar to how an RTP inventories component pieces and parts as it traverses CDB folders. An RTP looks into a tile and says "what's here?" The same could be applied to model containers...look for and quickly read metadata that tells you what's available, assuming the metadata contains the full inventory of pieces and parts.
splitting a model into pieces and parts for the sake of determinism is itself a pre-process. Adhering to the current CDB spec's 'complexity bins' (vertex limits) for the sake of determinism is a somewhat arbitrary requirement forced on to the 3D modeler. Abstracting away from these limits would require a means of evaluating a model's suitability for deterministic performance...another pre-process. In the same way that imposing vertex limits into a modeler's psyche is a pre-process. The current spec says the lowest LOD must have less than 128 vertices. What's wrong with 129?

Excellent exchange with already some convergence on ideas. Let me try to recap the high level ideas and suggest a way forward.

Agreement on the High Level Objective: 3D models should be easy to create, share and maintain

Some of the main points at play are:

• Encoding: Can we replace OpenFlight by glTF?

o Concerns expressed by Kevin that many extensions to glTF will be needed. Analysis started by Presagis.

o Do we want to support multiple encoding – some concerns that this would fragment CDB support too much.

• Better support the editing case

o To edit a model or a tile in CDB today, you often need to touch many files in different datasets (geometry changes will impact LODs) that contain other data up to geocel level!

- to keep a “source version” separated from the rendering optimized structure

- to group all LOD of a model together

• Can we optimize rendering performance by grouping data better?

o General agreement that we can by better grouping files.

o Grouping geometry and all textures (diffuse, normal map, lightmap, material etc…) seems to be accepted as long as readers can pick what they want to load.

o Model interior vs exterior can be grouped as long as you can load them separately

o Metadata should be close to model

o LightPoint are interesting… How to rapidly load millions of lighpoint at a distance while preserving link with geometry attached light point (at higher LOD).

o Zip is a possible container – compressed or not. In Geopackage or outside?

o **NOTE:** One reason CDB 1.X was splitting all those data into separate folder and datasets is the rule that one dataset has only one possible encoding (XML has to be in different dataset than open flight models … and in different folders) – as that still beneficial? This was likely to facilitate file lookup and know its encoding without relying on file extensions – with Geopackage as a database, lookups are supported without scanning files. • Do we still want vector to point to models (CDB 1.X way) or we want model geometry with attribution (OWT way)?

o What is the relationship between terrain elevation and models? CDB supports multiple terrain conformal modes in order to keep elevation and feature independent (allow to update one dataset without changing the other e.g. increase elevation resolution)

o Are the benefits worth the complexity for runtime consumption?

o How to identify a given feature at different LOD (for editing)

o CDB today uses points features at different LOD to point to the same geometry (MLOD attribute) providing some optimization (not duplicating models at all CDB tiles if the geometry is the same)

o CDB support different vector pointing to models. PowerNetwork points to power pylon models. Road network points to overpass/bridge models (figure points). This preserve link between network and geometry but means you need to load more vectors. • Tiling

o 3D model tiling will need to be consistent with the rest of CDB 2.0

o CDB 1.X links tiling and LOD. What does it mean to 3D models, SigSize etc…? • Do we need batching/instancing support?

• Full 3D Trees, bushes etc…

• Simulation needs dynamic moving trees with wind… you need articulated models and GPU optimized processing to do this.

• Power pylons with cable attach points

• Animation : Windmill, flags, functional traffic lights

o How do we encode it? At the tile level or at the library level? What is the impact on editing vs rendering performance?

Suggesting a way forward by splitting into 3 investigation areas:

a. Start with the assumption it is possible – Presagis is starting a detailed analysis of gaps – parallel task

a. Start with the assumption that a vector tile will have point features to models (merge GS/GT with some info on what can be referenced)

b. How would we package all 3D models data in a container (mesh/textures/metadata/materials etc…) in a way that facilitates editing?

c. How would we package all LODs in the same container with LOD indexing info?

a. Models with terrain elevation – do we preserve conforming?

b. Models with lightpoints

o Zip is a possible container – compressed or not. In Geopackage or outside?

If a GeoPackage is used, could it not itself be the container, with models nicely organized in a models table? Individual models could be compressed (e.g. Draco extension, or zipped glTF).

@PresagisHermann - Thanks for this excellent summary of the various CDB 2 discussions! This will help frame ongoing discussions.

Follow up:

While we've agreed the 'backwards compatibility' is not a requirement for CDB 2.0 it does make sense to accept so called backwards compatibility for our accumulated assets - existing 3D models and their textures; the investment in tools (like Creator); and decades of human skills, I DO NOT advocate removing OpenFlight from future CDB, rather for carefully deciding on an additional format or two to see what the up-take might be.

I foresee an overhaul of the 3D model metadata file, expanding its contents, and importance:

the enhanced metadata file could contain the model's LOD hierarchy/attributes, switch node - optionally when the model is OpenFlight; and to fill gaps in formats that do not support OpenFlight-like LOD and switch nodes.
the enhanced metadata file might contain the list of all the available parts and pieces belonging to a model.
the enhanced metadata file might contain an optional "lat/lon/alt/heading" tag.
the enhanced metadata file might contain an "MODL" attribute alias tag(s).
the enhanced metadata file could contain information facilitating texture sharing -- resource path, flags, etc.

A run-time may optionally mull over metadata files (during initialization or as an low priority background task), to quickly inventory discovered models, and inform itself of platform optimization opportunities - or not.

I oppose using a geopackage container for 3D models -- nobody makes geopackage 3D modeling software.

I think I will build up a prototype metadata file, and put it, together with a bunch of sample files into a zip file...and post it as a detailed illustration of how I am imagining this concept!

@christianmorrow While I agree with your high level objective, it also has to be carefully balanced against this one: 3D Models (and all CDB data) must be deterministic to retrieve and process with very low latency on both constrained (ex. handheld) and less constrained (ex. PC server) devices. I am confident we can make strides toward your objectives without totally sacrificing some of the design principals that lead to CDB 1.x (admittedly not always optimal) choices. With respect to this somewhat competing objective, I would like to make the following comments on your points:

For many runtime use cases, it makes good sense to have the models and their associated textures (including LODs of both) separated because geometry and texture are often paged independently at different resolutions. That said, it should definitely not be as cumbersome as it is today to view and edit a model.
Metadata is currently separated from models mostly as a side effect of the choice to separate LODs, and due to file format differences (XML vs OpenFlight). The former might still be a need for the objective I've asserted.
I agree light points should generally be integrated into 3D models (your examples of airports are often tiled 2D geometry at best though, and environment lights might not even have associated models), but the coarsest 3D model LOD for visualization is often light point only, so having some mechanism to cover that case is still needed as Ryan comments. It certainly doesn't have to resemble the current un-associated method, although either method can be used in CDB 1.x as Ryan said.
It certainly makes sense for many applications to separate building interiors from an IO bundle perspective. Flight sims can't read all that data just to throw it away in a fast jet application.
I already covered why separation of geometry LOD IO bundles is advantageous for determinism. It seems the consensus is leaning toward forked profiles to handle derived data performance needs for certain use cases, so it may be that my competing objective is relegated entirely there, but it was certainly a driving principal for CDB 1.x. While maintaining a common base with different profiles is still advantageous, we do have to acknowledge that CDB will no longer be plug and play across usage domains on that path.
Your "on the fly" conversion means unacceptably slow for some applications.

CDB 2.X Possibilities comments:

Many of the 15 year old rendering performance intents are still relevant for that use case at least, but they could certainly be better executed. I would contend, however, that without some of those principals, at least for that application domain, CDB would no longer be usable. In many ways, it already barely is today (some of which is due to those "could be better executed" choices though) for fast jet, sensor slew/zoom, and certain radar use cases.
Model instances: Most non-3D applications aren't prepared to access 3D file formats just to depict 2D GIS like information by pulling transforms out of headers. Vertex information in odd geodetic coordinate systems are likewise not easily editable or understandable using standard tool sets. This latter point seems to go somewhat against your original objective of friendly to create, share, and maintain, leaning toward the pre-processing being somewhat negatively discussed. While I sympathize with the desire to include transforms in 3D models, I think whatever we come up with has to remain non-3D use case friendly, and one of CDB 1.X's guiding principals is "don't duplicate data" (unless absolutely necessary for performance).
Self contained models: If everything is inside a single container that can be easily accessed to get only the parts and LODs a particular application needs with the same or fewer IOs than CDB 1.X requires, I'm all for keeping things together. But keep in mind that the current GS LOD separation and tiling is precisely to keep this minimal. You can't fly a fast jet high altitude simulation or world wide visualization and load every LOD and texture of every model in view just to throw away most of it. Again, at least in that use case domain. Please remember, CDB 1.X theoretically supports micron resolution data, not just the practically typical data of today (although I'm sure it can do this much better).
GLTF is certainly a prime candidate for an OpenFlight 3D model alternative format that will be included in CDB 2.x. Because of OpenFlight's rich domain specific attribution (or CDB supplemented XML comments) it may be some time before it is an exclusive replacement (especially if we consider the moving model use cases).
The major advantage of CDB was that there was no platform specific compilation process. It was plug and play among numerous vendors. As previously discussed, it may make sense to have a domain specific optimization process that optimizes the data in a common way for that particular class of use cases such as vis/sim. Otherwise, we are almost right back to stove piped production processes specific to every client application.

Replies to later comments:

GS models are allowed to refer to GT textures in CDB 1.X.
Most RTPs/clients use the Shapefile/GIS attributes to check to see if they can afford to process and render the tile before loading it, and then they use most everything in it. They do not look in it to see "what's here" in CDB 1.X. That is avoided by the current deterministic design, and a similar determinism principal should remain for at least some domain usage "profiles", such as vis/sim.
Agreed that splitting a model is a pre-process. The arbitrary requirements forced on a modeler are that the coarsest LOD has <= 128 vertices (you can always say what's wrong with one more and end up having no limits as a result; you have to choose something), but in some sense that's not very arbitrary if you are doing a whole Earth simulation. The rest enforce determinism, they do not necessarily bound the modeler, but rather the pre-formatting. Nothing says the formatted LODs have to be sequential, or can't have derived intermediaries. The formatter has the choice of how to satisfy the requirements (skip LODs, create LODs, etc.) Good ultra-low poly 3D model LODs are very hard to arithmetically create though, and CDB only requires one :-).
I agree that allowed 3D model formats should be chosen on their merits and modern usage ability, but every effort should be made to minimize the number of formats CDB supports for simplicity. Pre-formatting can always convert to whatever is chosen as the standard, which should in most cases have very few losses if chosen carefully. A backward reformatting can be used to support a particular (possibly legacy) editing tool or skill set (I'm not poking at anything specific).
Switch nodes in CDB 1.X are mostly defined in model metadata currently as CDB model "configurations". The only other use of a CDB 1.X switch node I can think of is for temporal anti-aliasing (spinning rotors/props).
Many of the concepts you are describing for the enhanced model metadata file were once encompassed in an industry CDB 3.1 proposal for a master OpenFlight file header similar to the structure used for GT models today.
No high performance application can "mull over" whole world arbitrary resolution data. CDB needs to remain in some way deterministic for these usage domains.
Who makes modeling software that reads zip files? ;-)

@PresagisHermann I never completely understood the one file format per dataset rule; it seems rather idealistic more than utilitarian. I think it would be fine to combine related data, and if necessary in differing formats.

@jerstlouis The container discussion is more akin to what the blob type is for a GeoPackage table entry, which may or may not be a GLTF variant. Yes, GeoPackage is a superset container.

@ccbrianf 3D Models (and all CDB data) must be deterministic to retrieve and process with very low latency on both constrained (ex. handheld) and less constrained (ex. PC server) devices.

In my opinion, that shouldn't a CDB 2.0 requirement. Nice to have maybe, but I don't think we'll be able to modernize CDB and do what you want simultaneously.

For your use-case, I think you should pre-process the CDB to make it fit your idea of determinism. To me, that's a specialization problem and the optimizations that your IG needs don't necessarily apply to anyone else. There's no reason you can't tile/chop/convert data to fit your needs.

How many IGs are being used that really fly directly off of CDB with nothing in between the visuals and the data? I'm not saying that there are none, but I believe that's a very small percentage of the overall CDB user base.

@kevinbentley You might want to review CDB volume 0 as Carl suggested we all do prior to this effort: https://github.com/opengeospatial/cdb-volume-0/blob/master/clause_6_BackgroundAndInformativeMaterial.adoc

In my opinion, which is really the opinion of the CDB originators (which I was not a part of), as evidenced there (which was primarily an expression of SOCOM interests at the time), it's not CDB without the determinism requirement. Every application benefits from this if it is at all interested in performance or resource constraints, of which most are at some level, short of supercomputers. In the mod/sim arena, CDB might as well be NPSI without it then because all it becomes is standardized source data attribution and metadata arbitrarily wrapped up in a modern OGC container. It will no longer be suitable for the performance use cases for which it was originally intended.

I do however continually conceded (to be reasonable) that if we think this is somehow too restrictive for the data repository (which it is) or other use cases, and we are content to forgo plug and play interoperability (I'm sure @PresagisHermann could provide you with a moderately complete list of CDB runtime capable devices), then we can confine this constraint to applicable usage domains (I actually think it will eventually become most of them). But if we don't have a standardized profile for that we can mostly agree on, or if every application has to reformat the data into its own proprietary optimized structure, then we have completely reverted and might as well go back to proprietary formats with long offline data preparation times because that is what it really becomes (but it will all be called CDB, sic). (Trust me, if I were trying to optimize for my use case or IG, I would be representing a completely different viewpoint that would only vaguely resemble the CAE legacy. I'm only trying to defend the original CDB design principles and user base idealistically while still supporting future growth and adaptability).

I honestly don't see why modernization is opposed to determinism. To me, modernization is about supporting ever increasing content capacity and fidelity, modern/new data formats, and fixing or improving historical design choices, while still maintaining performance and expanding usage domains without excluding existing ones. Can you enumerate how you would define CDB 2.0 that differs from that viewpoint? Back in the SWIG, I stressed that we can't move CDB forward without deciding what CDB is, or needs to become. I'm pretty sure I still haven't heard a clear and concise definition for that, which is partially why it continues to fracture into "profiles" and/or dissensions. Most of the new players have specific desires, but a lot are not at all, or are poorly articulated, IMHO. We all tend to see the end we want rather than the principal we are trying to achieve.

Tiling and regular LOD resolutions are not in any way an IG/simulation specific need, but I grant you that having only that representation available is not well suited for maintenance and some other use cases.

I strongly agree with @ccbrianf on this, and disagree that we can't both modernize and maintain determinism. Determinism is the strength of CDB, and consistent tiling of all types of data goes a long way towards achieving this, and this facilitates handling the data on the entire spectrum of use cases for production, storage, dissemination as well as the constrained edge use cases.

Maybe we should discuss what determinism means. @ccbrianf, when we have talked about GeoPackage, you have raised the concern that you didn't feel that spatially indexed GeoPackage files could be accessed deterministically unless you could guarantee that a single disk IO could give you the features you wanted. So when you talk about determinism, I'm interpreting that as "I always can predict how long it will take to read N features".

If determinism means you have to limit features (whether models or vectors) to a set size/vertex limit, I don't think that is compatible with the modernization we need.

When it comes to consistent tiling, data models, etc. I absolutely agree that we need that. If we're calling that determinism, I think it is a good thing.

One more thing in reference to the CDB volume 0, this is a discussion about CDB 2.0, so I think it's perfectly valid to revisit or ignore past assumptions. We are not looking for backwards compatibility. I believe it's still an open issue whether we should call what we're doing CDB 2.0, or if it should be an entirely new name. The important part is to meet the modern requirements of SOCOM/NGA/etc.

@kevinbentley If we consider multi-resolution tiling, and LOD of vector / models / imagery being selected based on the size that those tiles project to on a rendered image. Beyond a certain amount of detail for that LOD, additional vertices or texture resolution does not contribute to a better rendering.

In my opinion the fixed limit should be set at that point, so that with the argument about 128 vs 129 vertices, at 128 vertices you likely already have way too many vertices, so that the drop that spills with 129 is not an issue as it is simply intended to trigger the detection of severely breaking the determinism rules.

Also implementation-wise, OpenGL ES and WebGL based on it, have fairly low limits e.g. 16-bit indices, so limiting the amount of data somewhere can help organize the rendering engine to cope with those limits.

@kevinbentley Aspects of determinism: an application always knows the following:

Exactly where to find the type and resolution of data for the geographic region it needs without (much) filtering or searching, either on disk or in memory.
A garunteed upper bound on the size (in bytes, or some suitable approximation of that) of that data bundle, preferably tailored to a commonly agreed upon "maximal processing sized" unit so that it can be assured that resources are available to read and process the data. Ideally, the LOD and tiling structure will be chosen such that this limit is rarely a practical concern for typical data.
A good approximation for the amount of time it will take to retrieve (and probably also process) that information, which should be relatively uniform across spatial regions, and to some extent also across LODs, of the same data type. Please explain why modern applications desire non-deterministic data access? I understand why some desire data that is not tiled because they don't want to have to reassemble it, but that is the cost you usually pay for the above assurances Tiling means little more than application inconvenience if it doesn't also provide most of these benefits.

I do not require a single IO to retrieve the features an application wants, but that is certainly the most optimal case. I do want to make sure we consciously decide whenever we significantly increase the number of IOs in CDB 2.0 with respect to what would have been required in CDB 1.x to retrieve the same data because that heavily impacts application performance. We should be sure the value gained for the compromise is significant enough to warrant the penalty.

It is perfectly valid to revisit everything in CDB as long as we generally agree on the impacts of those changes, both with respect to current usage domains, and with respect to how the "core personality" of CDB will differ from its 1.x predecessor. Any changes to the latter though I think should be clearly articulated as fundamental design philosophy changes about what CDB is with general group consensus. I don't think it's ok to just ignore those things without such a discussion, some of which has been had, and some not so much.

What is backwards compatibility? We all agree CDB 2.0 will have new data formats and structures, both on disk and likely with its tiling structure, thus breaking backward compatibility. Do we all agree that we don't have to preserve existing application domains in some form, even if that form is a standardized CDB "profile" deviation for that domain? To me, that is an important part of backward compatibility that I don't think CDB 2.0 should sacrifice or it really should have a new name because it is no longer related to the old thing called CDB. Has SOCOM's needs so radically changed that these domains are no longer of concern for CDB 2.0, or have they only added new domains and use cases to the prior list?

It would be helpful if the SOCOM and NGA requirements were more spelled out rather than just assumed, because it might lead to some surprising conclusions. I'm not sure I understand all the NGA use cases, but if it is primarily data warehousing, quality control, enhancement/temporal currency maintenance, etc. and less online streaming access, I wouldn't necessarily require the determinism aspects of CDB for that use case. But given the shear amount of data being stored and managed, I can certainly see why it might still be worth paying the application complexity cost to access it that way.

@jerstlouis It would be best if we try to avoid discussion of rendering and stick to real world resolution, which is a point of commonality for all usages (and still illustrates your point I believe).

Yes, the vertex limits are already intended to be just as you describe. For 3D model geometry LODs I believe they already are. For GS 3D model tile bundles, I believe CDB is off by approximately 2 quad tree depth levels of tile size subdivision for any given resolution of data. This has been previously extensively discussed as something to address in the next CDB version.

There are many practical applications for well chosen determinism limits in data structures, only one of a near infinite number is discussed here by Jerome.

I have created two new issues: What is CDB 2.0? and "Determinism and CDB 2.0".

Please move your discussion on those topics to the new issues (7 and 8):

https://github.com/sofwerx/cdb2-concept/issues/8 https://github.com/sofwerx/cdb2-concept/issues/7

These are both important discussions and we need consensus. Easier to track the discussion by using these two new issues.

On this statement: The important part is to meet the modern requirements of SOCOM/NGA/etc.

Well, sure, SOCOM and NGA have $$ and requirements. While the focus of the current work is to meet SOF etc requirements, there is also an existing large CDB user community that cannot be ignored. Their requirements and use cases will help us frame CDB 2.0 design objectives and requirements. I suspect many of those use cases/requirements are consistent with SOCOM/NGA requirements but their will also be other requirements or classes of requirements that are mandatories for the current user community and that NGA does not care about.

The 3D modeling sub-group met yesterday with some experimentation results presented by Presagis (Anthony and Herm). There is a document on GitHub (https://github.com/sofwerx/cdb2-concept/blob/3Dmodels_prototype/3Dmodel_Prototype/CDB%20and%20OpenFlight_glTF_analysis.docx) that describes the cross-walk between current functionality for OpenFlight and glTF. There are a number of existing extensions for glTF that mimic some of the features of OpenFlight, but a CDB extension will probably be required. The experimentation performed by Presagis shows a simple OpenFlight model with 3 LODs converted to glTF using the MSFT_LOD extension to encode the LOD nodes. This model was successfully opened in Blender, however Blender cannot interpret the extensions, so the hierarchy is incorrect. This experimentation reveals some potential issues with encoding models and then editing them with standard 3D model editors (Blender, Max, Maya, etc), since the tools are not mature yet. This may pose some challenges when models are edited/changed/updated. Here are some shots from the miro board:

sofwerx / cdb2-concept

Thoughts on 3D Models in CDB #5

CDB 2.0 Possibilities