[x3d-public] Row/column-order in the SFMatrix*, MFMatrix* fields, I think X3DOM reading order contrasts to what spec says

[John Carlson]

There’s also the momentsOfInertia field, but it’s an MFFloat.

John

On Sat, Nov 22, 2025 at 6:40 PM Michalis Kamburelis via x3d-public <
x3d-public at web3d.org> wrote:

> Short version: Let's make sure our X3D browsers honor the order of values
> when reading SFMatrix*, MFMatrix* fields :)
>
>
>    - Classic encoding link:
>    https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f
>
>
>
>    - XML encoding link, saying the same:
>    https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f
>
>
> Longer version:
>
> I recently found a mistake in Castle Game Engine's SFMatrix*,
> MFMatrix* reading/writing code. We were following VRML 1.0 order, while the
> X3D order (according to both classic and XML encodings specs) is different.
> So I fixed it, and now Castle Game Engine and Castle Model Viewer follow
> the proper X3D spec order (when reading/writing X3D).
>
> Namely, X3D classic encoding spec unambiguously says:
>
>     """
>     The first four single-precision floating point numbers represent the
> top row of the matrix.
>     The second four single-precision floating point numbers represent the
> second row of the matrix.
>     """
>
>     Classic encoding link:
> https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f
>
>     XML encoding link, saying the same:
> https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f
>
> So this means that e.g. translation by 1 2 3 is encoded in X3D in a way
> that looks similar to how you would write it in math expressions:
>
> 1 0 0 1
> 0 1 0 2
> 0 0 1 3
> 0 0 0 1
>
> For example, using MatrixTransform node (extension supported by at least
> Castle Game Engine, X3DOM, Instant Reality), to move object by 1 2 3 you
> would write this:
>
> MatrixTransform {
>   matrix
>     1 0 0 1
>     0 1 0 2
>     0 0 1 3
>     0 0 0 1
>   children Shape {
>     appearance Appearance {
>       material Material { diffuseColor 0 1 0 }
>     }
>     geometry Sphere { }
>   }
> }
>
> To complicate testing a bit,
>
>
>    - VRML 1.0 and X3D specifications here say the opposite things. And
>    VRML 2.0 specification doesn't have a matrix field type. So it's probably
>    easy to make the same mistake I did :) See my docs about it on
>    https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format
>     .
>
>
>
>    - Moreover, not many nodes in spec actually use the matrix field
>    types. Again, see
>    https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format where
>    I listed the ones that do. The MatrixTransform, shown above, is only
>    an extension (and I do _not_ propose to make it part of spec; we should
>    encourage authors to use cleaner Transform).
>
>
> I have been testing MatrixTransform in X3DOM, and I think X3DOM has a bug
> (just like CGE did, a month ago!) and it expects matrix in transposed
> order. See testcase on
> https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html --
> only by transposing a matrix I was able to get the correct result.
>
> Regards,
> Michalis
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20251122/fa5fbe03/attachment-0001.html>