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

Should tiles always be gzipped? #61

Closed
pjcozzi opened this issue Jan 26, 2016 · 7 comments
Closed

Should tiles always be gzipped? #61

pjcozzi opened this issue Jan 26, 2016 · 7 comments

Comments

@pjcozzi
Copy link
Contributor

pjcozzi commented Jan 26, 2016

Currently, Cesium is storing all of the tile formats gzipped compressed. Should this be part of the core spec, e.g., a .b3dm file is always gzipped compressed?

One concern is if problem-domain specific compression (mesh compression, point cloud compression, etc.) cancels out any benefit of gzip.

Perhaps we want the flexibility that some tile playloads will be gzipped and others will not so we just leave this out of the spec?

@lilleyse
Copy link
Contributor

Along the same lines as you mentioned, I think enforcing gzip compression is too restrictive for the spec.

@mramato
Copy link

mramato commented Jan 26, 2016

Along the same lines as you mentioned, I think enforcing gzip compression is too restrictive for the spec.

@lilleyse the goal here would be to make 3D Tiles tilesets easily interchangeable. The question we need to answer is "Should a 3D Tiles server be able to serve any 3D tileset?" If the answer is yes, then it has to be part of the spec (or somehow have a server-side component that informs the server regarding compression). If the answer is no, then it will be impossible to serve a tileset without knowing additional information not available in the tileset itself.

@jbo023
Copy link
Contributor

jbo023 commented Jan 28, 2016

We would prefer that gzipping or not falls in the responsibilities of the webserver admin.

Our workflow always creates uncompressed data files (b3dm, terrain, quantized mesh).
This makes deploying the files to a default webserver easier. (You don't have to set the gzip header in the apache config).

If gzipping makes sense we activate dynamic gzipping on the webserver or create a static gzipped dataset and set the header in the apache configuration.

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jan 28, 2016

Thanks for the input, @jbo023.

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Feb 25, 2016

A comment from https://groups.google.com/forum/#!topic/cesium-dev/EPjCzYgmIxo

there are multiple issues that i discovered when using my own http server rather than the server.js supplied.

  1. the encoding type for the b3dm and pnt files need to be 'gzip'
    otherwise nothing is displayed and no error..... very very painful.

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Mar 21, 2016

Caught another user: #87 (comment)

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Apr 12, 2016

Given that this has confused several users - including me at times - and that some mesh compression algorithms do not benefit from gzip (for example, see OpenCTM here), we are not going to require tiles be gzipped as part of the spec.

The Cesium sample data will not be served gzipped so it is easy for users to inspect. Users are free to serve gzipped or not in their own server implementations. We can add a comment to the spec that tiles may be served gzipped.

I'm going to make this change soon so please comment ASAP if there are any concerns.

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

No branches or pull requests

4 participants