PLYExporter: Respect source types by default and double precision optional support

[Danilkat]

This description is deprecated, read the comments for accurate context

Description

Vertices are being multiplied by matrixWorld and then passed to the DataView as float32.
In JavaScript, numbers are float64 by default, so applying matrixWorld to the vertex might produce more precision than a float32 type can handle.

Solution

• Replace output.setFloat32 with output.setFloat64
• Replace float with float64 (double) in header
• Fix the ArrayBuffer allocation size to accommodate the new changes

Alternatives

Doing the same for normals might also be useful

Additional context

Related: #31710

[mrdoob]

Seems like you've isolated what needs to be changed. Would you like to do a PR with it?

[Danilkat]

Yes. But please give opinion on the suggestion in the 'Alternatives' block

[Mugen87]

What is your use case for requiring more precision in context of PLY? I'm asking this question also in regard to your other issues.

I'm just curious to see examples where float32 breaks a valid (not experimental) use case in real-time rendering and more precision is required.

If these use cases are rather uncommon, I vote your create your own custom PLY exporter/importer. Widely using Float64 the amount of memory for most users that don't need this precision.

[Danilkat]

GIS stuff. A mesh in mercator coords, exported with PLYExporter, and imported back into the app with PLYLoader, will have shifted vertices because world coordinates tend to be big.

Sure, you can use any other format that supports a matrix property and store the attribute buffers in local coordinates, but i have a requirement for PLY integration

I vote your create your own custom PLY exporter/importer

You mean create them on my application level or as an additional three.js examples? If its the latter, then there will be a lot of code duplication, so i think its better to add a flag exportDoublePrecision to the options

[Mugen87]

Regarding the exporter and this particular issue: If it's only about a flag that controls the output data type and if the default is float32 , I'm okay with a PR. Even if you want to do this for other attributes like normals.

A PR would also help the see the amount of changes so we understand the related complexity.

[donmccurdy]

Perhaps PLYExporter could choose a property type matching the attribute types in the source BufferGeometry? GLTFExporter does the same now. See #31710 (comment).

I understand this isn't perfect, the source geometry might not need that much precision prior to applying the world matrix, but this does offer more control and no increase in the API surface.

[Danilkat]

GLTFExporter support types up to Float32 attribute type. And it works flawlessly because GLTF also records object transformation matrices.
But PLYExporter premultiplies vertices/normals by object/normal matrices before assigning them to DataView as float32. We can use GLTFExporter-like approach AND always define vertices/normals as float64 type, since they are the only attributes being altered inside exporter.

[donmccurdy]

I don't think we can switch to float64 by default. This will greatly increase file sizes, and most users don't need or benefit from that. But yes, respecting source types by default, and also exposing an option to enable higher-precision vertex positions, would be good. Transformed normals should not need float64 precision.

[Danilkat]

Update:
Ive rewritten this class in my environment, but in TS. I will make a PR when ill port it to JS.