[x3d-public] new feature in X3dTidy stylesheet: numeric significant-digits precision using regular expression (regex)

[Don Brutzman]

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.

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.

This definitely needs to remain an author choice that deserves careful
consideration and inspection.

all the best, Don
-- 
X3D Graphics, Maritime Robotics, Distributed Simulation
Relative Motion Consulting  https://RelativeMotion.info


On Mon, Feb 23, 2026 at 1:21 PM Michalis Kamburelis <
michalis at castle-engine.io> wrote:

> 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.
>
> 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).
>
> So give me time, this will be fixed on our side too :)
>
> Just to give some context why it took / takes me so long to address this:
>
>
>    1. Some X3D authors really rely on preserving small numbers -- yes,
>    differences smaller than 0.001 sometimes matter.
>
>
>
>    - 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.
>       - People sometimes design tiny tiny worlds.
>       - 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.
>       - 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.
>
>
>
>    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.
>
>
>
>    1. 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.
>       2. 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 float
>       perfectly, since the "binary float" is just a direct dump of memory 32-bit
>       float, no text conversion, no rounding.
>
>
> Stay tuned for announcements when I finish all I talk above :)
>
> Regards.
> Michalis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20260223/40475c91/attachment.html>