KhronosGroup / glTF

glTF – Runtime 3D Asset Delivery
Other
7.12k stars 1.13k forks source link

Consider a "global" decode matrix for WEB3D_quantized_attributes? #1201

Open xeolabs opened 6 years ago

xeolabs commented 6 years ago

Just wanted to throw this out there, from the perspective of using glTF for CAD & BIM (feel free to close if this is just a sleep-deprivation brainfart ;).

The WEB3D_quantized_attributes extension specifies that each accessor be accompanied by its own decode matrix, which would mean that each separate geometry is encoded separately within its own Local-space extents, which is great for precision.

However, this also means that each geometry is potentially quantized/decoded with a (albeit slightly) different level of precision, which could be a problem for applications like CAD or BIM viewers that need rectilinear elements to be in perfect alignment with each other.

Perhaps there is a way to quantify all geometry uniformly, using the World-space extents of the entire model, where a global decode matrix would be supplied for the whole model. Not sure what the loss of precision would be, but then everything would line up perfectly once uniformly decoded.

lexaknyazev commented 6 years ago

However, this also means that each geometry is potentially quantized/decoded with a (albeit slightly) different level of precision, which could be a problem for applications like CAD or BIM viewers that need rectilinear elements to be in perfect alignment with each other.

That use case seems to be covered in extension's description here: Choosing a Range for Normalization.

pjcozzi commented 6 years ago

@xeolabs good point.

@mlimper do you have any thoughts on the precision here, e.g., in practice when would this be an issue, e.g., a bolt next to a factory? a bolt next to a city? etc.

mlimper commented 6 years ago

The boxes used for quantization may use the same "global grid" for their reference min/max values in order tor prevent cracks, at the cost of a bit of precision... but I must admit that we never used drastically different bboxes (which has to do with our spatial subdivision strategy), so I am not sure what would happen in that case.

However, it could be that these may end up being two different use cases in practice: if there is a bolt next to a city and they each use their individual quantization boxes, not aligned in any way, that may be just fine, as long as they don't form a single closed surface where cracks could possibly occur. In contrast, if there are different parts of the same big surface which are put in different meshes / boxes, one may want to use boxes of roughly the same size and then align their reference min/max values on a common grid, trading in a bit of precision for crack-free transitions between the different surface patches. FWIW, they desribe that method in the "Mesh geometry compression for mobile graphics" paper we refer to in the proposal, but I just realized the link is broken... here's a working one.