Add a GeoOrigin option the the mbgrd2gltf tool

[MBARIMike]

A well known problem for visualizing 3D geospatial data via glTF is the limits of the single precision floating point pipeline the the gpu hardware. The mechanism that X3D Geospatial offers to provide high precision rendering for small areas on the globe is GeoOrigin. By setting a local geographic point close to the study area offsets can be used which represent the the original data better with fewer digits than the original ECEF coordinates.

A --geoorigin option needs to be added to the mbgrd2gltf program where that user can specify a geographic point that will be used as the GeoOrigin for X3D Geospatial applications. The format of the value for the GeoOrigin is <longitude>,<latitude>,<elevation>.

[dwcaress]

This is certainly an important option, particularly when one wants to generate multiple gltf objects with the same coordinate system. Also, since mbgrd2gltf is converting a gridded topgraphy model to gltf, the default behavior should be to use the center of the grid as the lateral origin, and the mean or median topography value as the vertical origin.

…

On Feb 11, 2026, at 12:34 PM, Mike McCann ***@***.***> wrote: [POSSIBLE IMPERSONATION: This message is using the name of an MBARI account holder and has originated from outside of the organization. Please review the content and sender information carefully.] MBARIMike created an issue (dwcaress/MB-System#1567) <#1567> A well known problem for visualizing 3D geospatial data via glTF is the limits of the single precision floating point pipeline the the gpu hardware. The mechanism that X3D Geospatial offers to provide high precision rendering for small areas on the globe is GeoOrigin <https://doc.x3dom.org/author/Geospatial/GeoOrigin.html>. By setting a local geographic point close to the study area offsets can be used which represent the the original data better with fewer digits than the original ECEF coordinates. A --geoorigin option needs to be added to the mbgrd2gltf program where that user can specify a geographic point that will be used as the GeoOrigin for X3D Geospatial applications. The format of the value for the GeoOrigin is <longitude>,<latitude>,<elevation>. — Reply to this email directly, view it on GitHub <#1567>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXD3QUSOOWZW5W265CL4LOG7BAVCNFSM6AAAAACUZUAS22VHI2DSMVQWIX3LMV43ASLTON2WKOZTHEZDQNJYGY3TINA>. You are receiving this because you are subscribed to this thread.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 ***@***.*** https://www.mbari.org/person/dave-caress/ https://www.mbari.org/team/seafloor-mapping/ Phone: 831-775-1775

[MBARIMike]

The output of mbgrd2gltf is intended to be used in an X3D scene. In order to "mash up" data from different sources, for example showing the trajectories of underwater vehicles, all the inlined data must share the same cartesian coordinate system. I think the best default is to use original ECEF coordinates, that way other data can be added to a scene using ECEF coordinates. Only if sub-meter precision is required should the --georigin option be used. If other data is added to an X3D scene with terrain that has a GeoOrigin then those data will also need to use that same GeoOrigin.

[dwcaress]

Mike, Ok. However, I’d like to be able to turn on the georigin feature and have the program just use the center of the source grid. That could be —georigin with no arguments or a separate command. Thanks, Dave

…

On Feb 12, 2026, at 10:04 AM, Mike McCann ***@***.***> wrote: [POSSIBLE IMPERSONATION: This message is using the name of an MBARI account holder and has originated from outside of the organization. Please review the content and sender information carefully.] MBARIMike left a comment (dwcaress/MB-System#1567) <#1567 (comment)> The output of mbgrd2gltf is intended to be used in an X3D scene. In order to "mash up" data from different sources, for example showing the trajectories of underwater vehicles, all the inlined data must share the same cartesian coordinate system. I think the best default is to use original ECEF coordinates, that way other data can be added to a scene using ECEF coordinates. Only if sub-meter precision is required should the --georigin option be used. If other data is added to an X3D scene with terrain that has a GeoOrigin then those data will also need to use that same GeoOrigin. — Reply to this email directly, view it on GitHub <#1567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXFJJLW4K2I7YFAYZSD4LS6EHAVCNFSM6AAAAACUZUAS22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOJSGU2DMMBXHE>. You are receiving this because you commented.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 ***@***.*** https://www.mbari.org/person/dave-caress/ https://www.mbari.org/team/seafloor-mapping/ Phone: 831-775-1775

[MBARIMike]

Here is an example execution for an LASS multibeam survey that has 5 cm resolution:

➜  multibeam git:(master) mbgrd2gltf -IZTopo.grd -V -B -D
INFO 2026-02-12 10:21:37.775 main.cpp main():70 Command: mbgrd2gltf -IZTopo.grd -V -B -D
INFO 2026-02-12 10:21:37.775 main.cpp main():82 Starting mbgrd2gltf processing for ZTopo.grd (3.357 MB)
INFO 2026-02-12 10:21:37.775 main.cpp main():84 Binary output: enabled, Draco compression: enabled
DEBUG 2026-02-12 10:21:37.784 bathymetry.cpp Bathymetry():142 Using dimension lengths: [ 1888 , 2017 ]
DEBUG 2026-02-12 10:21:37.784 bathymetry.cpp Bathymetry():147 Matrix allocation: 1888 x 2017 = 3808096 elements ( 14.5267 MB)
DEBUG 2026-02-12 10:21:37.784 bathymetry.cpp Bathymetry():155 Attempting 1D read: 3808096 elements
DEBUG 2026-02-12 10:21:37.784 bathymetry.cpp Bathymetry():163 1D read failed: NetCDF error -57: failed to get float array data for variable 'z'
DEBUG 2026-02-12 10:21:37.784 bathymetry.cpp Bathymetry():164 Attempting 2D read: [ 2017 x 1888 ]
DEBUG 2026-02-12 10:21:37.812 bathymetry.cpp Bathymetry():173 2D read successful
INFO 2026-02-12 10:21:37.812 bathymetry.cpp Bathymetry():189 Loaded bathymetry grid: 1888 x 2017 = 3,808,096 points
INFO 2026-02-12 10:21:37.812 main.cpp main():87 Generating 3D geometry from 2D bathymetric grid data
INFO 2026-02-12 10:21:37.812 main.cpp main():88 Vertical exaggeration: 1
INFO 2026-02-12 10:21:37.812 geometry.cpp Geometry():69 Using original ECEF coordinates (no GeoOrigin offset)
INFO 2026-02-12 10:21:38.020 geometry.cpp Geometry():81 Created 2,154,322 vertices
INFO 2026-02-12 10:21:38.596 model.cpp write_gltf():422 Building 51 tiles for Draco compression
INFO 2026-02-12 10:21:40.942 model.cpp write_gltf():431   Built tile 51 of 51
INFO 2026-02-12 10:21:40.942 model.cpp write_gltf():451 Encoding 51 tiles with Draco compression
INFO 2026-02-12 10:21:52.078 model.cpp write_gltf():516   Encoded tile 51 of 51
INFO 2026-02-12 10:21:52.088 model.cpp validate_gltf_file():52 Validating output file...
INFO 2026-02-12 10:21:52.111 model.cpp validate_gltf_file():71 Validation passed - no errors or warnings
INFO 2026-02-12 10:21:52.276 main.cpp main():121 Successfully wrote glTF file to /Users/mccann/GitHub/MB-System/build/sample_data/OceanImaging2018/20180925d1/multibeam/ZTopo.glb (1.899 MB)

And the .glb file viewed in a web-based glTF viewer showing jitter due to limits of single precision:

no_GeoOrigin_H.264.mp4

[MBARIMike]

Here is execution using a GeoOrigin:

➜  multibeam git:(master) mbgrd2gltf -IZTopo.grd -V -B -D -G-122,36,0
INFO 2026-02-12 10:52:12.915 main.cpp main():70 Command: mbgrd2gltf -IZTopo.grd -V -B -D -G-122,36,0
INFO 2026-02-12 10:52:12.916 main.cpp main():82 Starting mbgrd2gltf processing for ZTopo.grd (3.357 MB)
INFO 2026-02-12 10:52:12.916 main.cpp main():84 Binary output: enabled, Draco compression: enabled
DEBUG 2026-02-12 10:52:12.925 bathymetry.cpp Bathymetry():142 Using dimension lengths: [ 1888 , 2017 ]
DEBUG 2026-02-12 10:52:12.925 bathymetry.cpp Bathymetry():147 Matrix allocation: 1888 x 2017 = 3808096 elements ( 14.5267 MB)
DEBUG 2026-02-12 10:52:12.925 bathymetry.cpp Bathymetry():155 Attempting 1D read: 3808096 elements
DEBUG 2026-02-12 10:52:12.925 bathymetry.cpp Bathymetry():163 1D read failed: NetCDF error -57: failed to get float array data for variable 'z'
DEBUG 2026-02-12 10:52:12.925 bathymetry.cpp Bathymetry():164 Attempting 2D read: [ 2017 x 1888 ]
DEBUG 2026-02-12 10:52:12.953 bathymetry.cpp Bathymetry():173 2D read successful
INFO 2026-02-12 10:52:12.953 bathymetry.cpp Bathymetry():189 Loaded bathymetry grid: 1888 x 2017 = 3,808,096 points
INFO 2026-02-12 10:52:12.954 main.cpp main():87 Generating 3D geometry from 2D bathymetric grid data
INFO 2026-02-12 10:52:12.954 main.cpp main():88 Vertical exaggeration: 1
INFO 2026-02-12 10:52:12.954 geometry.cpp Geometry():55 Using user-specified GeoOrigin: -122 , 36 , 0
INFO 2026-02-12 10:52:12.954 geometry.cpp Geometry():63 GeoOrigin ECEF offset: -2.73756e+06 , -4.38102e+06 , 3.72819e+06
INFO 2026-02-12 10:52:12.972 geometry.cpp get_vertices():139 First vertex [ 859 , 156 ] before offset: x= -2.74669e+06 y= -4.34411e+06 z= 3.76283e+06 lon= -122.304 lat= 36.3924 alt= -839.461
INFO 2026-02-12 10:52:12.972 geometry.cpp get_vertices():152 First vertex [ 859 , 156 ] after offset:  x= -9125.25 y= 36905.5 z= 34640.2
INFO 2026-02-12 10:52:12.972 geometry.cpp get_vertices():162 Sample vertex #1000 [ 850 , 172 ] before offset: x= -2.74669e+06 y= -4.34411e+06 z= 3.76283e+06
INFO 2026-02-12 10:52:12.972 geometry.cpp get_vertices():164 Sample vertex #1000 [ 850 , 172 ] after offset:  x= -9125.25 y= 36906 z= 34641
INFO 2026-02-12 10:52:13.155 geometry.cpp Geometry():81 Created 2,154,322 vertices
INFO 2026-02-12 10:52:13.724 model.cpp write_gltf():422 Building 51 tiles for Draco compression
INFO 2026-02-12 10:52:16.053 model.cpp write_gltf():431   Built tile 51 of 51
INFO 2026-02-12 10:52:16.053 model.cpp write_gltf():451 Encoding 51 tiles with Draco compression
INFO 2026-02-12 10:52:27.172 model.cpp write_gltf():516   Encoded tile 51 of 51
INFO 2026-02-12 10:52:27.183 model.cpp validate_gltf_file():52 Validating output file...
INFO 2026-02-12 10:52:27.206 model.cpp validate_gltf_file():71 Validation passed - no errors or warnings
INFO 2026-02-12 10:52:27.373 main.cpp main():121 Successfully wrote glTF file to /Users/mccann/GitHub/MB-System/build/sample_data/OceanImaging2018/20180925d1/multibeam/ZTopo.glb (1.899 MB)

No jitter seen when viewing:

with_GeoOrigin2.mp4.mov

[MBARIMike]

I understand the use case for using the -G option without a lon,lat,alt argument being that we'd like a glTF file that can be viewed by itself with the maximum resolution possible.