<div style="font-family: Arial, sans-serif; font-size: 14px;">An update about this: It seems I was confused. Disregard parts / all of my last email! And what X3DOM is doing is correct.</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Thanks to <span>Elmar</span>, the reporter of <span><a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/castle-model-viewer/issues/122">https://github.com/castle-engine/castle-model-viewer/issues/122</a></span> , he pointed me to a statement in X3D spec:</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><span><br></span></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><span><i> "Since these data types are commonly used for 3D transformation matrices, translation values are stored in the fourth row"</i></span></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><span><i><br></i></span></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><span>So this contradicts some of my statements in the last mail, sorry for the noise!</span></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty">
<div class="protonmail_signature_block-user protonmail_signature_block-empty">
</div>
<div class="protonmail_signature_block-proton protonmail_signature_block-empty">
</div></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty">This means that the right way to specify translation by (1,2,3) in a matrix in X3D is </div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty"><span>1 0 0 0</span><div><span>0 1 0 0</span></div><div><span>0 0 1 0</span></div><span>1 2 3 1</span></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty"><span><br></span></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty">This means that</div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty"><ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"><li style="list-style-type: "- ";"><span>VRML 1.0 and X3D way of storing matrix in a file is the same.</span></li><li style="list-style-type: "- ";"><span>X3DOM approach is correct.</span></li><li style="list-style-type: "- ";"><span>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. </span></li><li style="list-style-type: "- ";"><span>_Now_ <span>Castle Game Engine / Castle Model Viewer</span> approach is again correct, and matching X3DOM.</span></li></ul><div><br></div><div>Sorry everyone for the noise :) I'm smarter now, and happy to have people testing <span>Castle Game Engine / Castle Model Viewer</span> and quickly pointing out my mistake! :)</div><div><br></div><div>I have updated the docs and testcases to be all correct, so maybe at least this helps someone to validate their browsers:</div><div><br></div><div><span>- <a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format">https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format</a></span><div><span>- testcases:</span></div><div><span> - <a target="_blank" rel="noreferrer nofollow noopener" href="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.x3d</a></span></div><div><span> - <a target="_blank" rel="noreferrer nofollow noopener" href="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.x3dv</a></span></div><span> - <a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html">https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html</a></span></div><div><span><br></span></div><div><span>Regards,</span></div><div><span>Michalis</span></div></div><div class="protonmail_quote">
On Sunday, November 23rd, 2025 at 01:38, Michalis Kamburelis <michalis@castle-engine.io> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<div style="font-family: Arial, sans-serif; font-size: 14px;">Short version: Let's make sure our X3D browsers honor the order of values when reading SFMatrix*, MFMatrix* fields :)</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"><li style="list-style-type: "- ";"><span><span>Classic encoding link: </span><span><a target="_blank" rel="noreferrer nofollow noopener" href="https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f">https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f</a></span><br></span></li></ul></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><div><br></div><div><ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"><li style="list-style-type: "- ";"><span><span>XML encoding link, saying the same:</span><span><a target="_blank" rel="noreferrer nofollow noopener" href="https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f">https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f</a></span><br></span></li></ul></div></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Longer version:</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">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 <span>Castle Game Engine</span> and Castle Model Viewer follow the proper X3D spec order (when reading/writing X3D).</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Namely, X3D classic encoding spec <span>unambiguous</span>ly says:</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><span> """</span><div><span> The first four single-precision floating point numbers represent the top row of the matrix.</span></div><div><span> The second four single-precision floating point numbers represent the second row of the matrix.</span></div><div><span> """</span></div><div><span><br></span></div><div><span> Classic encoding link: </span><span><a target="_blank" rel="noreferrer nofollow noopener" href="https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f">https://www.web3d.org/documents/specifications/19776-2/V3.3/Part02/EncodingOfFields.html#SFMatrix4f</a></span><div><br></div><div><span> XML encoding link, saying the same:</span><span><a target="_blank" rel="noreferrer nofollow noopener" href="https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f">https://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfFields.html#SFMatrix4f</a></span></div><div><span><br></span></div><div>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:</div><div><br></div><div>1 0 0 1</div><div>0 1 0 2</div><div>0 0 1 3</div><div>0 0 0 1</div><div><br></div><div>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:</div><div><br></div><div><span>MatrixTransform {</span><div><span> matrix</span></div><div><span> 1 0 0 1</span></div><div><span> 0 1 0 2</span></div><div><span> 0 0 1 3</span></div><div><span> 0 0 0 1</span></div><div><span> children Shape {</span></div><div><span> appearance Appearance {</span></div><div><span> material Material { diffuseColor 0 1 0 }</span></div><div><span> }</span></div><div><span> geometry Sphere { }</span></div><div><span> }</span></div><div><span>}</span></div><span></span></div><div><br></div><div>To complicate testing a bit, </div><div><br></div><div><ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"><li style="list-style-type: "- ";"><span>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 <span><a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format">https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format</a> .</span><br></span></li></ul></div><div><span><br></span></div><div><ul style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"orderedStyleType":1,"unorderedStyleType":2}"><li style="list-style-type: "- ";"><span><span>Moreover, not many nodes in spec actually use the matrix field types. Again, see <span><a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format">https://github.com/castle-engine/castle-engine/tree/master/tests/data/matrix_vrml_x3d_format</a></span> where I listed the ones that do. The <span>MatrixTransform</span>, 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).</span></span></li></ul></div><div><span><br></span></div><div><span>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 <span><a target="_blank" rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html">https://github.com/castle-engine/demo-models/blob/master/x3d/matrix_transform_x3dom.html</a></span> -- only by transposing a matrix I was able to get the correct result.</span></div><div><span><br></span></div><div>Regards,</div><div>Michalis</div></div></div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty">
<div class="protonmail_signature_block-user protonmail_signature_block-empty"></div>
<div class="protonmail_signature_block-proton protonmail_signature_block-empty">
</div>
</div>
</blockquote><br>
</div>