Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double-precision transform hierarchy #228

Open
zeux opened this issue Oct 2, 2023 · 0 comments · May be fixed by #229
Open

Double-precision transform hierarchy #228

zeux opened this issue Oct 2, 2023 · 0 comments · May be fixed by #229

Comments

@zeux
Copy link
Contributor

zeux commented Oct 2, 2023

Currently cgltf uses cgltf_float typedef for all floating point numbers that are part of the scene definition, including materials, transforms, and vertex attributes.

Unfortunately, single precision floating-point numbers may not be enough to represent node translation. This is a prominent problem in glTF when used for 3D Tiles, as these files may use geospatial coordinate systems that place the origin in the center of the Earth, and place the object on the surface of the Earth which is Pretty Far Away from the origin.

This can be worked around by carefully placing nodes at locations that happen to be exactly representable as 32-bit floats, but that requires special data preparation that doesn't seem to be commonplace. Meanwhile Web glTF loaders typically handle large transforms without issues as they default to 64-bit floating point math, so you only need to do camera-relative rendering to avoid GPU precision issues.

Ideally it should be possible to configure cgltf to use 64-bit floats for node transforms. Crucially, right now just redefining cgltf_float wouldn't work because among other things it is used to extract accessor data (e.g. cgltf_accessor_unpack_floats), which should keep using 32-bit floats for performance/memory reasons.

It's not clear to me if we need to use double-precision for just node transforms, or for everything that's not a vertex attribute. For example, materials have a handful of floating-point numbers for which precision should be inconsequential - does that matter?

Also unsure if we should invent a new type, like cgltf_real, for this, or keep using cgltf_float and use cgltf_float32 in a couple places where 32-bit floating point numbers are required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant