I'm currently adding support for T2D models to my CDB run time publisher that uses the Presagis CDB API.

As an aside, it would have been way easier for me to implement if T2D models were read using the T3D part of the API rather than the Vect part of the API. If that were the case I could have just re-used 99% of the code I use for reading in T3D models.

But the real problem I'm having is I've noticed there is no way to read the layer relative priority through the Vect interface. This limits the degree of optimization I can apply.

For example, I use texture arrays to minimize the number of draw calls that are required. So textures that have the same dimensions are stacked into the same texture array. This allows all faces that use any of the textures that have the same dimension to get merged into a single draw call. This greatly reduces the number of draw calls required.

The side effect of this is that it can cause the draw order of faces to get reordered. For example, without optimization you might get a few faces at relative priority 0 that use a 256x256 texture, followed by a few faces at relative priority 1  that use a 512x512 texture, followed by a few faces at relative priority 2  that use another 256x256 texture. If that relative priority information is not available then after optimization, all faces that use a 256x256 texture might get rendered before the faces that use a 512x512 texture. This may result in incorrect appearance as in the example the faces with relative priority 2 might have been runway markings that should have been on top of the asphalt texture at relative priority 1. The order reversal will make the runway markings not visible.

If layer relative priorities are available this information can be used by the optimizer to know that it should not reorder across priorities.

My suggestion would be that a new VectFeature attribute be added for T2D models, 

e.g. Priority - Integer attribute giving the relative priority of the feature.

Would this be possible?

Hi Paul,

The attribute exists already but was not properly documented in the CDB API header files. Here is the list of attributes you can access on the T2D interface; which includes the relative priority.

The next release of CDB API will have this documented in the header files but you can use the current CDB API and look for this attribute name today.

Let us know if this does not address the issue.

Regards

///

/// The vector feature contains parts, attributes and textures.

///

/// @remark For T2D models, the following attributes are supported:

/// @remark CDBZoneName - This is the CDB zone name as defined in the feature's associated parent group node.

/// @remark ModelID - String attribute giving the name of the flt node corresponding to the feature.

/// @remark SigSize - Single-precision floating point attribute giving the significant size of the feature.

/// @remark RelativePriority - Relative priority of the group node, valid range [0, *]

/// @remark CMIX - Material index in the model's composite materials table

Hi Hermann,

Thanks for your reply.

If I run the CDB API sample CdbFileDump on, for example, the Camp Pendleton sample N33W118_D310_S001_T001_L00_U0_R0.flt file, the attributes listed are:

ModelID

SigSize

LayerCount

TexName

PointUV

Which matches the documentation. There are no CDBZoneName, RelativePriority or CMIX attributes. Also LayerCount, TexName and LayerUV are not mentioned in your list. Can you account for this discrepancy?

As a sanity check, in my own code I also tried calling

uint32 priorityIndex = vect.getAttributeIndex("RelativePriority")

where vect is a VectFile for the T2D model.

This returns -1 indicating the attribute is not present.

Opening the .flt file in Creator shows that the model contains nine faces, with f1 to f7 being at priority 0 and f8-f9 being at priority 1. So the model definitely contains relative priority values, but they are not being exposed through the attributes.

As an aside, I also believe the layer priorities given to T2D faces in the samples are incorrect. Section 6.2.2 states "the layer number is expressed by the group's relative priorty". Then section 6.2.2.1 mandates that "Layer 0 is always empty", but here in this example we have 6 faces in layer 0. This seems wrong?

On a related note, you mention a CMIX value. I was trying to figure this out a week or so ago. I can't find any mention in the CDB 3.2 spec (or the new OGC version of the spec) that describes how to attribute materials to T2D models. Section 5.8.2 only lists the flt dataset, there is no dataset and component selector combination defined for an associated xml to contain a composite material table. So do the CMIX values map to the 200_VectorMaterial for the geocell? But section 5.7.10 does not list 310_T2DModelGeomtry as one of the datasets that can reference the VCMT.

This looks like an omission from the CDB specification - or am I missing something?

Additionally, the T2D flt models in both the Camp Pendleton and Yemen samples do not contain any comments to attribute materials, so no CMIX values could be determined anyway.

Thanks,

-Paul

Hi,

I apologize for the misguidance. You will need to update to the latest CDB API in order to get access to the RelativePriority attribute. Presagis is in the process to do the final sanity check on the release and hope to make it available shortly.

For the sample T2D in our CDB, the RelativePriority set to 0 are indeed a mistake. We are evaluating the cause and solution.

As for your request on the CMIX value on T2D, the CDB 3.2 spec in section 5.8.2 lists dataset 312 as the CMT for the T2D. However, this is not in the CDB sample we provide. Our intent is rater to use a material texture as we do for all 3D models in our CDB sample.

I hope this answers all your questions. 

Thanks for your response, I look forward to getting the new version of the API when it becomes available.

I'm going to implement a workaround for the layer 0 issue in my code, if any layer 0 polygons are found in a tile I'll just add one to all the layer numbers.

I'm interested that you state section 5.8.2 lists dataset 312 as the CMT for T2D models. I've checked section 5.8.2 in both the 3.2 specification dated 19 March 2014, and the latest OGC version of the specification with publication date 2017-02-23, and both only have dataset 310 listed in section 5.8.2. Do you have access to a newer or different version of the specification that also contains dataset 312?

One more related question. There are several VectPart::Type enumerations. In all the samples I'm looking at it seems that only eRing is generated by the T2D file reader. Can I assume this will always be the case? Additionally, can I assume that each ring forms a convex polygon? This will make my code a lot easier and faster if I can make these assumptions.

Hi Paul,

Our sample database does not exercise all possible option. You should not limit your support to the content we are providing. You have to refer back to the specification to know what is allowed and decide what you want to support. 

But the T2D model is specified as an OpenFlight file. One of the restrictions specified in section 6.3.2 is that all polygons in OpenFlight files should be convex.

It is only the Presagis API that is converting these into pseudo shape files. It appears that the API is converting each polygon into a VectPart. You would have to go out of your way, for example by merging polygons, to generate a non-convex polygon. This would add significant extra processing burden on the reader if it then has to analyze for convex polygons, rings, inner rings, etc. and deconstruct them back into multiple convex polygons. All of which would be pointless code and a waste of processing resources if your converter never generates these anyway. 

It would seem to be a better solution for Presagis to declare what type of geometry your flt->VectFile conversion generates. If it's a one to one mapping of polygon->part then the reader can assume all parts are either convex rings if the source data was a polygon, or triangle strips if the source geometry was a triangle strip mesh.

Also, did you see my prior post (I posted two posts in a row) where I was asking what version of the spec you have that mentions dataset 312?

Hi,

Regarding the referenced CDB SPECversion, I was pointing to CDB 3.2 update 1 - dated Nov 2015. This is no longer downloadable from our WEB site since the redesign of it, but I am working at making this available.

This correction came after the start of OGC 1.0 effort and did not make it in 1.0. However, it is now included in the CDB 1.1 document, soon to be released by OGC. In there, dataset 312 is a CMT in xml format associated to the T2D CMIX polygon attributes.

Appreciate the help Hermann.

BTW, if you'd like some help Beta testing the new version of the API I'd be happy to help out. Just let me know.