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

[Danilkat]

Description

Right now, PLYLoader can only output the geometry, and all the buffers are getting casted to Float32BufferAttribute, which results in (1) loss of precision for double and float64 properties and (2) overuse of precision for properties smaller than float32.

But the data from PLY might be used for something other than just rendering.

Solution

Expose the parseBinary and parseASCII functions without postProcess call, which would return the buffer object created from createBuffer. Map properties to typed arrays instead of regular ones (the part of that is done by setPropertyBinaryReaders for binary but not for ASCII).

Alternatives

Or make another ply loader, which will return those buffers instead of geometry (PLYRawLoader, perhaps?)

Additional context

Related to #23006.
This will allow the users to use make their own postprocesses (for example, normalizing the position buffer to the unit cube and extracting the transformation matrix to atleast preserve the local distances).

[mrdoob]

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

[Danilkat]

Yes. But which one of two options should i do - make the new loader that only outputs buffers, or extend the existing one?

Both seems good to me, except that the latter will require less time to complete

[donmccurdy]

To my understanding (I read the Wikipedia page 😅) the PLY format supports these property types:

char uchar short ushort int uint float double
int8 uint8 int16 uint16 int32 uint32 float32 float64

Is there any reason PLYLoader couldn't create buffer attributes with the matching types by default? GLTFLoader supports a similar list of types and just constructs THREE.BufferAttribute instances with a typed array of the corresponding type.

To parse PLY into raw buffers rather than three.js classes, a library like @loaders.gl/ply might be appropriate.

[Danilkat]

This is a great option, except that you cant (and shouldn't) have a double precision buffer attributes. If we assume your solution as a starting point, then we need to normalize double and float64 properties before passing them to the Float32BufferAttribute, and return the TS (translation and scale) properties along with the geometry.

[donmccurdy]

There's a similar proposal for float64 support in glTF at KhronosGroup/glTF#2397. I don't know if that will be approved, but if it were — my preferred solution in GLTFLoader would be to return BufferAttributes containing Float64Array data (which, yes, we can't render), and require the user to decide how or if to render that. Users might normalize the data, or split the data across two uint32 attributes and reconstruct in the shader, or not render the data at all. To me, that decision feels outside the scope of the file loader.

[Danilkat]

To me, that decision feels outside the scope of the file loader.

I feel the same

to return BufferAttributes containing Float64Array data

... you mean new BufferAttribute(float64arr)? If yes, then im gonna slap myself because of how narrow minded i am of not thinking about this solution in the first place lol. I think it's the best

[donmccurdy]

Yep, that'd sound good to me if it works for you! I'm not opposed to creating a new Float64BufferAttribute class either, but probably easier to get something merged with just new BufferAttribute(float64arr), at least to start.