ccbrianf
commented
3 years ago As described, I don't think this is a large enough need to merit CDB taking the effort to define it's own glTF extension for this purpose. I suggest simply pushing this observation upstream to glTF (maybe via Patrick's team?) and waiting for that standards body to decide if it deems internal instancing something that the format should support. If the other use cases were also of concern, my opinion might differ. But at present, this seems like a minor compression/efficiency loss (that I think a web streaming format might be interested in resolving in the future). If you have spare cycles, go for it. But otherwise, I think there are probably more valuable places to invest that effort.
cnreediii
As part of the 3D model analysis activity to encode 3D models in glTF, we face the need to decide how many CDB 1.X concepts needs to be supported in CDB X and if we can deprecate some (and obviously add some). As we define the CDB extension to glTF, we find some concept/constructs that do not exists in glTF and we need to decide if we can do without them in CDB X or need to add them to the extension. Where there are a few concepts to discuss, an important one we want to bring forward first is the ability for a geometry to reference another geometry. In OpenFlight, those are called xRef which has no equivalent in glTF. Do we need those? Let me try to list the cases where xRef are beneficial to CDB.
Use case 1: Split geometry in chunks an allow loader to decide to load or not. Most OpenFlight loaders will load a complete binary to memory. Large models with many LODs in the OpenFlight would need to be completely loaded before selecting the LOD. In CDB 1.X This is not a problem for GS models but can be on GT models and is on Moving Models. The xRef is used on GT Model geometry today to create the root model that has all the LOD nodes. Under each LOD node, an xRef is used to allow the loader to load a simple root model and decided which LOD to fetch after. This usecase is already covered in glTF as each "node" in glTF is a bin file. A loader decided which bin chunks to load. So, no xRef support is required in glTF for usecase 1.
Use case 2: Instancing geometry from geometry - for simulation CDB supports two way to have a geometry call another geometry. The first is with attach point (like a weapon under a wing) where the loader need to "Decide" what model (weapon in this example) to attach based on simulation information. xRef are not used here by CDB as xRef are static and point to a specific model - not leaving simulation the choice. A simple node with "Attach point" information is sufficient. This is an easy thing to do in glTF. So, no xRef support is required in glTF for usecase 2.
Use case 3: Instancing geometry from geometry - for efficiency - The real question..... A general use case for xRef is instancing (multiple copy of) object components. Not to confuse with instancing of objects from vector (trees for example have many point in the vector, all calling the same model) but here the cases is where model reference a "sub-model" of a component. A typical case of this is to add "generic and typical objects on building" such as satellite dish, AC units, repeating balcony objects etc.... Having those objects referenced and positioned by the main object geometry is valuable an logical in my view.
As such, I would recommend that we include xRef concept in our glTF CDB extensions even if it serves less purpose in CDB X. That said, if the extensions exists to support user case 3, it may be used in use case 1 as well.
So, the 3D group is looking for feedback on this first concept - candidate for deprecation - the xRef. I say we keep it.