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

[John Carlson]

Note that, AFAIK, castle-model-converter and Holger’s x3d-tidy are already
ready to reduce the precision of floating point numbers.  It’s an option on
the command-line.

Michalis, great news on you getting to glTF output in Castle.  I hope to
improve Blender X3D import at some point, since I am unaware of people
working on it.  With blixemel, I am having difficulty with the coordinate
system for animation between models, with one bending along the wrong axis.
  Gramps is okay, Lily is not.  I hope to get some clarification from Carol
or Katy, but yeah, I’m not even dealing with X3D in blixemel, so it’s
puzzling!

John

On Mon, Feb 23, 2026 at 5:42 PM Don Brutzman via x3d-public <
x3d-public at web3d.org> wrote:

> 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
>>
> _______________________________________________
> 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/20260223/d9d4a1fd/attachment.html>