Discussion: packBinaryJson() is insufficient for XVIZ encoding about loaders.gl HOT 4 CLOSED

The current automatic packing of typed arrays in the GLB/GLTFBuilders was mainly implemented as a convenience to get us started.

It was not really intended to be the long term approach for a complex client like XVIZ.

While we might be able to add a bit more smarts to the auto-packing feature, I think in the long term, it will be confusing and hard to maintain and explain.

XVIZBuilder would probably benefit from not passing typed arrays to the builder and instead taking control of exactly what gets packed into binary (and how it gets packed) using explicit GLTFBuilder APIs.

We may need a few small changes in the GLTF builder to make sure all the APIs necessary for XVIZ to take full control, but it should be minor (e.g. make sure that addBuffer and addImage are available directly on GLTFBuilder).

I can support with these changes if we want to go this way.

from loaders.gl.

When I hacked the above colors appears to expect 3 values per color, not 4 :(

We deduce the attributes size here: https://github.com/uber-web/loaders.gl/blob/master/modules/draco/src/draco-encoder.js#L189

Maybe put a breakpoint here and check that we are giving the right data to the encoder?

Or maybe we need to do something to auto discover length on the decode?

from loaders.gl.

Some additional thoughts about supporting compressed point clouds:

A good way to start would be to first store uncompressed point clouds as a standard (uncompressed) glTF meshes.

Then the additional step of compressing the clouds would be a smaller increment, as the plumbing would already have been sorted.

Also, if we add the mesh this way, we could also add a "scenegraph" and a "node" entry referencing this glTF "mesh". This should make the XVIZ file loadable in glTF viewers, and it would show a scene containing the embedded pointcloud - (at least if the cloud uses RGB or RBGA colors, and if turns out we can use the standard glTF mesh compression extension instead of our own).

This would provide a significantly stronger link between XVIZ and glTF, which we have been discussing.

from loaders.gl.

I believe XVIZ has taken control of this process now.

from loaders.gl.