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

[John Carlson]

Furthermore, in my JavaScript code, I used the translations in the right
column for multiplication, AFAIK, but I don’t recall matrix order in
multiplication.  Plus, I rarely use SFMatrix4f.

Can both ways work if SFMatrix4f isn’t used?

Note that I haven’t see matrix multiplication in X3DJSAIL or X3DPSAIL.

John



On Sun, Nov 23, 2025 at 7:54 PM John Carlson <yottzumm at gmail.com> wrote:

> Not to ruffle anyone’s feathers, but doesn’t this all depend on which side
> you are multiplying on?  If you multiply with a vector on the left side, if
> I put
>
> 1 0 0 0
> 0 1 0 0
> 0 0 1 0
> 1 2 3 1
>
> On the right side of a multiplication, and multiply by
>
> 1 1 1 1
>
> I get
>
> 2 3 4 1
>
> Which is correct
>
> If I put this vector to the right of the matrix:
>
> 1
> 1
> 1
> 1
>
> I get
>
> 1
> 1
> 1
> 7
>
> When I multiply the matrix and the vector, which is wrong.
>
> But I could make similar arguments for translations in the last column,
> and indeed, that’s how we did it in school.
>
> So the moral is, not only get your matrix cell position right, but also
> get your matrix multiplication right.
>
> I am referring to row times column multiplication of matrices.  If you do
> column times row, god help us.  Do we do left to right or right to left?
>
> Am I wrong?
>
> Isn’t there a common understanding by mathematicians that we should be
> following?
>
> John
>
> On Sun, Nov 23, 2025 at 4:54 AM Michalis Kamburelis via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> An update about this: It seems I was confused. Disregard parts / all of
>> my last email! And what X3DOM is doing is correct.
>>
>> Thanks to Elmar, the reporter of
>> https://github.com/castle-engine/castle-model-viewer/issues/122 , he
>> pointed me to a statement in X3D spec:
>>
>> *    "Since these data types are commonly used for 3D transformation
>> matrices, translation values are stored in the fourth row"*
>>
>> So this contradicts some of my statements in the last mail, sorry for the
>> noise!
>>
>> This means that the right way to specify translation by (1,2,3) in a
>> matrix in X3D is
>>
>> 1 0 0 0
>> 0 1 0 0
>> 0 0 1 0
>> 1 2 3 1
>>
>> This means that
>>
>>    - VRML 1.0 and X3D way of storing matrix in a file is the same.
>>    - X3DOM approach is correct.
>>    - Castle Game Engine / Castle Model Viewer past approach was correct,
>>    and my "fix" last week actually made it invalid... argh, I made a bubu :) I
>>    have now reverted my change.
>>    - _Now_ Castle Game Engine / Castle Model Viewer approach is again
>>    correct, and matching X3DOM.
>>
>>
>> Sorry everyone for the noise :) I'm smarter now, and happy to have people
>> testing Castle Game Engine / Castle Model Viewer and quickly pointing
>> out my mistake! :)
>>
>> I have updated the docs and testcases to be all correct, so maybe at
>> least this helps someone to validate their browsers:
>>
>> -
>> https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format
>> - testcases:
>>     -
>> https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform.x3d
>>     -
>> https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform.x3dv
>>     -
>> https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html
>>
>> Regards,
>> Michalis
>> On Sunday, November 23rd, 2025 at 01:38, Michalis Kamburelis <
>> michalis at castle-engine.io> 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/20251123/90683640/attachment.html>