Quaternion Serialisation Changed

[epreston]

Description

Quaternions are now serialised in a way that is indistinguishable from Vector4.

They have changed from being an object to an array in exports. There is no way to know which data type is required / used when loading exported data or inspecting log dumps.

This breaks all of our tooling.

Reproduction steps

1. Attempt to serialise a quaternion
2. Inspect the output.

Code

They used to be serialised by default as:

"rotation": Quaternion {
  "_w": 1,
  "_x": 0,
  "_y": 0,
  "_z": 0,
  "isQuaternion": true,
},

Now they are serialised as

"rotation": [
  0,
  0,
  0,
  1,
],

Live example

Provided above.

Screenshots

No response

Version

r151.3

Device

Desktop, Mobile, Headset

Browser

Chrome, Firefox, Safari, Edge

OS

Windows, MacOS, Linux, Android, iOS

[Mugen87]

"rotation": Quaternion {
  "_w": 1,
  "_x": 0,
  "_y": 0,
  "_z": 0,
  "isQuaternion": true,
},

This output was never intended and just the result of toJSON() not being implemented. It is not the task of toJSON() to serialized type information. fromJSON() methods usually create uninitialized objects and then use a JSON object to restore data. If your app works differently, you have to implement a custom toJSON() method.

[epreston]

I doubt that is the case. There's a very good reason it was not implemented, so that it could be distinguished from a Vector4. It may seem simple to suggest that but in practice, it is not practical.

[Mugen87]

The sole data don't have to be distinguishable. What entity the JSON consumes and it knowledge about it matters. Sorry, the current solution is based on #25424 and #24167 and there is no compelling reason to reconsider the implementation.

[epreston]

@mrdoob What is this ? I'd like you to review a list of thoughtless and abrupt closures like this one. Now my questions are being marked as "abuse".

[donmccurdy]

JavaScript's JSON serialization scrapes internal details from ES6 classes, including private members. I agree with @Mugen87 that serialization of a class that does not implement toJSON should not be relied upon. That the newly-implemented toJSON method does not include a "type" property is a design decision.

@epreston issues are closed when a decision has been made not to work on them. I understand you'd prefer a different decision here, but from repeated experience — it does not seem like you are willing to accept maintainers' decisions, and frankly we do not have the time or obligation to persuade you.

[epreston]

@donmccurdy That's not a fair summary.

I've only asked for things to get some thoughtful consideration when required and time has shown it was for good reason. I've always given time and respect to peoples issues, regardless how much thought was put into them. I don't contribute much any more because I don't get that in return.