Binary Compression Rates for ASCII Formats

Martin Isenburg      Jack Snoeyink

press SHIFT to translate and CTRL to zoom

Geometry compression for VRML has been since 1996 an important item on the wish-list of the Web3D Consortium. It was widely understood that a binary format would be required to allow compressed geometry. This is probably the reason that there is still no geometry compression in VRML. We demonstrate here a compression technique that does not require a binary format and that is able to achieve the bit-rates of a binary benchmark coder. The lion model shown above has just been decompressed on the fly in your browser from a 43 KB file. The compression software can be found here.
Should one day a binary standard for VRML (or X3D) be accepted to co-exist with the ASCII standard our technique will allow complete conformance between the two versions. Translating back and forth between the two versions will not require to envoke compression or decompression. Furthermore the same coding technique can be used to inflate a compressed geometry node, no matter if it was stored in an ASCII VRML file or in a binary VRML file. We do not argue against a binary version of VRML. A binary format will reduce parse time and also allow to store compressed geometry node even more compact. We argue for doing and geometry compression now ... without waiting for the binary specification.


  • [is-bcraf-03.pdf slides] Martin Isenburg, Jack Snoeyink, Binary Compression Rates for ASCII Formats, Proceedings of Web3D Symposium'03, pages 173-178, March 2003.
  • [is-cwa-02.pdf slides] Martin Isenburg, Jack Snoeyink, Coding with ASCII: compact, yet text-based 3D content, Proceedings of the 1st International Symposium on 3D Data Processing, Visualization and Transmission'02 (Invited Paper), pages 609-616, June 2002.
  • [is-cpmca-02.pdf slides] Martin Isenburg, Jack Snoeyink Coding Polygon Meshes as Compressable ASCII, Proceedings of Web3D Symposium'02 (Best Paper), pages 1-10, February 2002
  • downloads:

  • slides: bcraf.ppt
  • demos: demos/
  • models: models/
  • result table:

    models size of gzipped ASCII [KB]
    plain old new
    difference to
    binary benchmark
    442 66 43
    1 : 10 + 1.3 %
    183 29 19
    1 : 10 + 1.8 %
    200 35 22
    1 : 9 + 1.7 %
    123 23 13
    1 : 9 + 2.2 %
    312 35 18
    1 : 17 + 1.8 %
    266 41 21
    1 : 13 + 1.7 %
    267 40 23
    1 : 11 + 1.6 %
    186 35 22
    1 : 8 + 1.7 %

    The above table list for each VRML scene the size of the gzipped file for standard plain VRML, our old coded VRML (from our Web3D'02 paper), and our new compressed VRML (from the submitted paper) in Kilobytes. We also report the corresponding compression ratio of our new compressed over the plain VRML. The average compression ratio is 1 : 11. Furthermore we list the file size difference between the gzipped ASCI and the binary representation of the compressed scene. On average the gzipped ASCII files are only 1.7 percent bigger.

    These results can be verified by following the links to a demonstration of our decoder.

    For both, our old coded and our new compressed VRML format, the quantization of vertex positions was to 12 bits of precision and the quantization of texture coodinates to 10 bits of precision.

    The links bring you to a java implementation of the decoder, that will decode the scene on-the-fly in your browser from the respective VRML file. You can see the difference in file sizes between the standard plain, our old coded and our new compressed VRML by comparing the files in the models/ directory.

    Furthermore you can "look" at the plain, the coded, and the compressed VRML scenes. You can download the source of these scenes in this models/ directory.

    If you read our new compressed VRML files (e.g. the *_compressed.wrl files) in a text editor you will see the following:

    #VRML V2.0 utf8
    Shape {
        appearance Appearance {
            material Material {
                modulateTextureWithDiffuse true
                diffuseColor 1 1 1
            texture ImageTexture {
                url lion.jpg
        geometry CompressedIndexedFaceSet {
            creaseAngle .9
            code "EgAQGZ+HUGypgdSV+FozzeQ+gxbctYJ/G3AETx6cQZxaZ84...IZ02JOCsiIfXt0RRv9sUlH/8STiU2NbOb5/jV0Fq"
            box_tex [ 0.021545 0.028430 0.979910 0.978414 ]
            bits_tex 10
            box [ -4.1757 -8.3377 -10 4.1757 8.3377 10 ]
            bits 12

    This is actually our new compressed VRML scene that contains the lion model (shown above). The code field contains the bits produced by the arithmetic coder represented using BASE64 coding with save ASCII characters. The box_tex field contains the min and max texture coordinates of the model, which represent the bounding box that the texcoords were quantized into. The bits_tex field specifies the precision used for texcoord quantization. Similarly the box field contains the min and max position coordinates of the model, which represent the bounding box that the positions were quantized into. The bits field specifies the precision used for position quantization.

    The author can still modify this ASCII scene. All interesting data (here: material and creaseAngle) are still readable and editable. Only the geometry, the connectivity, the texcoord mapping, and the texcoord values of the polygon mesh cannot be understood anymore. However, an author will usually not edit single positions, texcoords, or polygons of a (large) mesh.

    The java implementation decompresses the compressed VRML scenes on the fly. For each CompressedIndexedFaceSet node it creates a proper instance of an IndexedFaceSet node that can be rendered by Shout3D's pure Java renderer, which we use for visualization. The software used to compress the IndexedFaceSet nodes of the VRML scene can be found here.