<div dir="ltr"><div>No criticism or blame intended, Michalis!  This is a (perhaps surprisingly) complex topic, and it took a few weeks effort to get to the point described earlier.  Your choice of defaults have always been reasonable.</div><div><br></div><div>I will be adding a warning to the converter if a UNIT statement is found.  Also thanks for insight that sometimes small differences are used to avoid Z-buffer aliasing.</div><div><br></div><div>This definitely needs to remain an author choice that deserves careful consideration and inspection.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34)"><font face="monospace"><br></font></div><div style="color:rgb(34,34,34)"><font face="monospace">all the best, Don</font></div><div style="color:rgb(34,34,34)"><font face="monospace">-- </font></div><div style="color:rgb(34,34,34)"><font face="monospace">X3D Graphics, Maritime Robotics, Distributed Simulation</font></div><div style="color:rgb(34,34,34)"><font face="monospace">Relative Motion Consulting  <a href="https://RelativeMotion.info" target="_blank">https://RelativeMotion.info</a></font></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Feb 23, 2026 at 1:21 PM Michalis Kamburelis <<a href="mailto:michalis@castle-engine.io">michalis@castle-engine.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Note that I'm aware that our tools (Castle Model Converter, Castle Model Viewer etc.) are ones to blame here. I do plan to fix this (generate floats with less significant digits, by default) on our side. </div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">We will by default output 6 digits after dot, not more (6 matches defaults I observed in various applications, including game engines like Unity when they same scene files).</div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">So give me time, this will be fixed on our side too :)</div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Just to give some context why it took / takes me so long to address this:</div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><ol style="margin-top:0px;margin-bottom:0px"><li style="list-style-type:"1. ""><span>Some X3D authors really rely on preserving small numbers -- yes, differences smaller than 0.001 sometimes matter. <br></span></li></ol></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><div style="font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><ul style="margin-top:0px;margin-bottom:0px"><ul style="margin-top:0px;margin-bottom:0px;list-style-type:circle"><li><span>Numbers in X3D (and 3D in general) undergo scaling (e.g. by Transform.scale), so some people use tiny numbers are rely that later e.g. scaling mesh by 100 makes a reasonable result.</span></li><li><span>People sometimes design tiny tiny worlds.</span></li><li><span>the UNIT clause (introduced in X3D 4 from what I recall) also means that we don't always have meters. We _typically_ have meters, I agree with that statement in Don's mail, but it's not just always the case.</span></li><li><span>Sometimes, people put tiny difference to make sure one thing is on top of another, to avoid visual Z-fighting. E.g. plane at Z = 0.0001 will be on top of plane with Z = 0.0, even if visually the distance between them will seem ~practically nothing.</span></li></ul></ul><div><br></div><div></div><ol start="2" style="margin-top:0px;margin-bottom:0px"><li style="list-style-type:"2. "">That's the reason why I was reluctant to just arbitrarily cut any possibly-useful digits (even if possibility that they are useful, and not noise coming from rounding to decimals, was very small :) ) by default. I needed to first have a way to _precisely_ store 32-bit 
floats to files, to give a solution to people who will need it.</li></ol><div><br></div><ol start="3" style="margin-top:0px;margin-bottom:0px"><ol style="margin-top:0px;margin-bottom:0px;list-style-type:lower-alpha"><li>We now have it, as we started work on "save to glTF", with binary data representing floats, and thus we can save 32-bit floats from memory -> files without any loss of precision and in compact way.</li><li><span>This means that for text output formats, like X3D XML / classic, we are fine cutting digits. If anyone will need arbitrary precision, we can just recommend saving to glTF which will preserve the in-memory 32-bit </span>float perfectly, since the "binary float" is just a direct dump of memory 32-bit float, no text conversion, no rounding.</li></ol></ol><div><br></div><div>Stay tuned for announcements when I finish all I talk above :)</div><div><br></div><div>Regards.</div><div>Michalis</div></div></blockquote></div>