cell phone). The “soft factor” user experience is important in all of these settings.
2 REQUIREMENTS Considering the factors above as well as our experience fromdeveloping XML3D [16] for the last three years now, we derive following requirements for a 3D transmission format: Structured To reduce network latency, a transmission format needs to be able to transport structured data. Formats that require one request per data buffer (or even multiple requests) are only suitable under very specific conditions (regarding network and data) and are not suitable for general usage. Typed Array compatible Efficient decoding to Typed Arrays [11] is necessary for two reasons: Firstly, many APIs require Typed Arrays as input (WebGL, River Trail) and they…show more content… Generality A transmission format that supports only a predefined set of attributes (e.g. only positions, colors, and normals) is not only out of date and does not reflect recent advances in graphics APIs, it also prevents many usecases and ignores the fact that other 3D related data in scenes, for instance animation data, can make up a large part of the total scene data to be transmitted. Thus a transmission format should be flexible enough to contain generic data fields and not just geometry. Compression The transmission format should allow for compressing some of the data included. However, the compression schemas must not be “baked” into the format. The reason for this is that a predefined set of compression schemas is not suitable for most use-cases. Different use-cases have different requirements on the compression algorithm (e.g. position coordinates vs. texture coordinates vs. normals vs. generic attributes vs. animation data). It would be sufficient to mark a block of data with an identifier that allows the application to identify the compression scheme to be used. This way, the number of compressor can easily be extended and implemented using WebCL,
