Add Draco compression to mbgrd2gltf

[MBARIMike]

Following up on #1257 it would be great to have the default output of mbgrd2gltf be a compressed mesh. The open source Draco library (https://github.com/google/draco) seems appropriate for providing this new feature.

An experiment with using draco_transcode showed a 60x decrease in file size for the Monterey25 terrain:

➜ draco_transcoder -i Monterey25_e10_lat_rev.glb -o Monterey25_e10_lat_rev_drc.glb
Transcode	Monterey25_e10_lat_rev.glb	7645
➜ ls -lh Monterey25_e10_lat_rev*
-rw-r--r--@ 1 mccann  513   237M Jan 20 12:50 Monterey25_e10_lat_rev.glb
-rw-r--r--@ 1 mccann  513   3.8M Jan 20 12:51 Monterey25_e10_lat_rev_drc.glb

We can convert to Draco compressed gltf following execution of mbgrd2gltf using draco_transcoder but it would be much nicer to have mbgrd2gltf write Draco compressed gltf to begin with as the file size reduction is significant.

[dwcaress]

Mike, Feel free to augment the code and commit it. Draco seems to be available in MacPorts and Ubuntu. Cheers, Dave

…

On Jan 20, 2024, at 1:14 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.] Following up on #1257 <#1257> it would be great to have the default output of mbgrd2gltf be a compressed mesh. The open source Draco library (https://github.com/google/draco) seems appropriate for providing this new feature. An experiment with using draco_transcode showed a 60x decrease in file size for the Monterey25 terrain <stoqs/stoqs#1175 (comment)>: ➜ draco_transcoder -i Monterey25_e10_lat_rev.glb -o Monterey25_e10_lat_rev_drc.glb Transcode Monterey25_e10_lat_rev.glb 7645 ➜ ls -lh Monterey25_e10_lat_rev* -rw-r--r--@ 1 mccann 513 237M Jan 20 12:50 Monterey25_e10_lat_rev.glb -rw-r--r--@ 1 mccann 513 3.8M Jan 20 12:51 Monterey25_e10_lat_rev_drc.glb We can convert to Draco compressed gltf following execution of mbgrd2gltf using draco_transcoder but it would be much nicer to have mbgrd2gltf write Draco compressed gltf to begin with as the file size reduction is significant. — Reply to this email directly, view it on GitHub <#1426>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXDAKOQZMUODX3J3N6LYPQXUJAVCNFSM6AAAAABCDOOGT2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TEMRUGI2DMMI>. 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 ***@***.*** http://www.mbari.org/~caress/ Phone: 831-775-1775

[MBARIMike]

Dave,

Thanks! I'm expecting to have a capstone team work on this Issue. The idea is to have more manageable smaller files so that we can use the output for 3D terrain displays in the Seafloor Mapping Database and STOQS web apps using x3dom.

-Mike

[dwcaress]

Mike, Ok. Currently there is both a new CMake build system and an old Autotools build system. The Autotools is kept around for building on legacy OSs. I’m going to remove the building of mbgrd2gltf from the Autotools because I don’t want to introduce a new library dependency onto legacy OSs. When your team works on this they should only be modifying the CMakeList.txt files, and not touch Makefile.am or configure.ac files, and not using the configure script You should test using only cmake + make to build and install. Dave

…

On Jan 20, 2024, at 3:11 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.] Dave, Thanks! I'm expecting to have a capstone team work on this Issue. The idea is to have more manageable smaller files so that we can use the output for 3D terrain displays in the Seafloor Mapping Database <https://www.mbari.org/data/seafloor-mapping/> and STOQS <https://www.mbari.org/data/stoqs-data/> web apps using x3dom <https://www.x3dom.org/>. -Mike — Reply to this email directly, view it on GitHub <#1426 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXCT6ETTHTW6JXMBSQDYPRFJJAVCNFSM6AAAAABCDOOGT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGM3DANZXGY>. 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 ***@***.*** http://www.mbari.org/~caress/ Phone: 831-775-1775

[varadpoddar]

Good Evening,
I am a CSUMB student and came across this issue through the capstone projects presentation. I was combing over the issue along with the related files. I was wondering if the goal is to simply transcode the resultant gltf using draco/tools/draco_transcoder.cc or to add draco encoding on the mesh data before generating the gltf file ?

[MBARIMike]

Hello @varadpoddar,

It's the latter: add draco encoding on the mesh data before generating the gltf file. I look forward to meeting with your fellow team members to discuss the details of this Issue. We can come back here as needed with specific technical comments.

-Mike

[varadpoddar]

Good Evening @MBARIMike,

While testing the current dev build for draco compression functionality in mbgrd2gltf, I ran into the following error with 2 specific .grd files.

Have you encountered the issue on MacOS before? The Monterey25 and Globe_1M .grd files seem unaffected. Are there any prep steps that can be performed as I want to try to establish compression using samples from the MGDS Map View.
The datasets from MGDS seem to result in the same error.

Thank You.
varadpoddar / MB-System

[MBARIMike]

Hi @varadpoddar,

See the gist referred to in #1456 for suggestions on dealing with different forms of metadata in .grd files.

With respect to using grids from the MGDS site (a nice thing to be able to do!) we need to first get the grids in geographic (longitude/latitude) coordinates.

From my reading of the GMT documentation this command should "unproject" the UTM grids from the MGDS Map View into geographic coordinates that mbgrd2gtlf can operate on:

gmt6 grdproject Topo1m_CCEShallow_20151104_UTM.grd -Ju10/1:1 -I -C -GTopo1m_CCEShallow_20151104.grd

However, the z array in the resulting file contains no valid data:

➜  MontereyCanyon_CCE ncdump -h Topo1m_CCEShallow_20151104.grd
netcdf Topo1m_CCEShallow_20151104 {
dimensions:
	lon = 8414 ;
	lat = 2703 ;
	grid_mapping = 12 ;
variables:
	double lon(lon) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees_east" ;
		lon:standard_name = "longitude" ;
		lon:axis = "X" ;
		lon:actual_range = 238.08891789464, 238.183560559565 ;
	double lat(lat) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees_north" ;
		lat:standard_name = "latitude" ;
		lat:axis = "Y" ;
		lat:actual_range = 36.78284265761, 36.808096455424 ;
	float z(lat, lon) ;
		z:grid_mapping = "grid_mapping" ;
		z:long_name = "Topography (m)" ;
		z:_FillValue = NaNf ;
		z:actual_range = NaN, NaN ;
	char grid_mapping(grid_mapping) ;
		grid_mapping:spatial_ref = "GEOGCS[\"unknown\",\n    DATUM[\"Unknown based on WGS 84 ellipsoid\",\n        SPHEROID[\"WGS 84\",6378137,298.257223563,\n            AUTHORITY[\"EPSG\",\"7030\"]]],\n    PRIMEM[\"Greenwich\",0,\n        AUTHORITY[\"EPSG\",\"8901\"]],\n    UNIT[\"degree\",0.0174532925199433,\n        AUTHORITY[\"EPSG\",\"9122\"]],\n    AXIS[\"Longitude\",EAST],\n    AXIS[\"Latitude\",NORTH]]" ;
		grid_mapping:crs_wkt = "GEOGCS[\"unknown\",\n    DATUM[\"Unknown based on WGS 84 ellipsoid\",\n        SPHEROID[\"WGS 84\",6378137,298.257223563,\n            AUTHORITY[\"EPSG\",\"7030\"]]],\n    PRIMEM[\"Greenwich\",0,\n        AUTHORITY[\"EPSG\",\"8901\"]],\n    UNIT[\"degree\",0.0174532925199433,\n        AUTHORITY[\"EPSG\",\"9122\"]],\n    AXIS[\"Longitude\",EAST],\n    AXIS[\"Latitude\",NORTH]]" ;

// global attributes:
		:Conventions = "CF-1.7" ;
		:title = "Produced by grdproject" ;
		:history = "gmt grdproject Topo1m_CCEShallow_20151104_UTM.grd -Ju10/1:1 -I -C -GTopo1m_CCEShallow_20151104.grd" ;
		:description = "\n\tProjection: UTM10N\n\tGrid created by mbgrid\n\tMB-system Version 5.5.2327\n\tRun by <eve> on <theo.wifi.mbari.org> at <Tue Mar 20 15:10:35 2018>" ;
		:GMT_version = "6.5.0" ;
}

Maybe I'm missing some option in the gmt6 grdproject command?