Garrett Johnson

It should not - you can see the explanation of geometric error in the spec [here](https://github.com/CesiumGS/3d-tiles/tree/main/specification#geometric-error). I recommend reading through the 3d tiles specification if you'd like to become more...

> I have indeed read this part of the documentation. I’m not sure if I misunderstood, but I feel that the documentation does not clearly specify whether the tile’s geometricError...

Assuming the answer is to align the description with existing 3d tiles implementations and _yes_ the geometric error is supposed to scaled by the transform - it would be great...

In both versions [0.0](https://github.com/CesiumGS/3d-tiles/tree/0.0?tab=readme-ov-file#tile-transform) and [1.0](https://github.com/CesiumGS/3d-tiles/tree/1.0/specification#tile-transforms) the spec specifically states that `transform` should _not_ scale the geometric error: > The transform property does not apply to geometricError—i.e., the scale defined...

Hopefully not 🤞 I just made a comment in your other issue. We'll see what the feedback is.

This was raised in https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/1176 and I see now that both Cesium source and a single line in the spec: > The transform property scales the geometricError by the largest...

> In how far are the root and the internal transforms "independent"? To be clear when I say "root" I'm referring to the root transform in a target client, not...

> I have to take a step back and wait for others to chime in Agreed. I'll clarify a few final points. > > This factor of 10, of course,...

I'm confused - why do we not seem to be considering removing the line from the specification? It hasn't been able to be stated _why_ the addition is beneficial and,...

@javagl > I think it may be even less clear for readers who are more familiar with some concepts. I understand there are concerns about the definition of "geometric error",...