Lightweight visualization for high-quality materials on WebGL

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Web3D 2013, June 20 – 22, 2013, San Sebastian, Spain. Copyright © ACM 978-1-4503-2133-4/13/06 $15.00

Lightweight Visualization for High-Quality Materials on WebGL

Gustavo Chavez Francisco Avila Alyn RockwoodKing Abdullah University of Science and Technology (KAUST)

Figure 1: A red leather jacket model rendered using our system with virtual textures and data compression. The first and third image showthe final frame. The second and fourth image show the uv coordinates of the visible tiles.

Abstract

We propose an architecture for lightweight visualization of high-quality 3D objects based on data compression, data streaming, vir-tual texturing and WebGL. Our method retains visual fidelity ofthe original scene, improves loading time and maintains real-timerendering speed. We assume that the user is restricted to low-performance GPUs and slow Internet connections (1 megabit persecond or lower). For geometry compression, we use entropy-encoding techniques that achieve up to 95% storage savings. Tex-tures are stored as sets of tiles which feeds the virtual texturingengine. With use of the Crunch library, tiles are compressed withresults similar to JPEG but with much faster transcoding to DXTon the GPU. The initial 27.7MB dataset takes an average of 5 min-utes to load. Our approach, takes less than 5 seconds on average.A wide range of applications benefit from our architecture such ase-commerce, cultural heritage, virtual worlds, videogames, and sci-entific visualization, among others.

CR Categories: I.3.2 [Computer Graphics]: Graphics Systems—Distributed/network graphic; I.3.3 [Computer Graphics]: Three-Dimensional Graphics and Realism—Display Algorithms

Keywords: webgl, virtual texturing, distributed rendering

1 Introduction

WebGL generates hardware-accelerated 3D graphics on the Webusing JavaScript. It introduces some problems for loading and ren-dering big chunks of data with minimal resources. Various tech-niques have been proposed, which focus on isolated problems suchas geometry compression, texture compression, frustum culling,data streaming, etc. Our architecture combines these techniquesand others to provide fast and high-quality visualization on the Webfor low-performance GPUs and slow Internet connections. The sys-tems uses data compression and virtual textures in order to a) im-prove loading time, and b) maintain the original visual quality of thescene. The main challenge for web 3D graphics is the large amount

of data, i.e. geometry and textures, required by common applica-tions such as videogames, CAD/CAM or scientific calculations. Inthe near future, we will also see immersive 3D graphics for areassuch as e-commerce, advertising and virtual environments. Theseapplications will benefit from our architecture.

Geometry simplification is one of the favorite topics in data com-pression for computer graphics. However, those techniques tend todegrade the perceived visual quality of 3D objects. Texture map-ping enhances the looks of an object, but it also requires stream-ing large files over the network in real-time. Nevertheless, usersexpect to interact instantaneously with Web applications; therefore,we focus on techniques that do not compromise performance for vi-sual fidelity. Consider, the videogame industry. It fosters renderingtechniques that maximize realistic graphics, with fixed resources.The challenge is even greater on the Web since data must often bestreamed over the network instead of being read directly from alocal storage device.

1.1 Contributions

The architecture retains visual fidelity, improves loading time andmaintains real-time rendering speed on high-quality 3D objects inscenarios with low-performance GPUs and slow Internet connec-tions. Our implementation handles highly detailed objects in real-time using state-of-the-art compression techniques, data streaming,and virtual texturing specifically tailored for WebGL-capable hard-ware [Khronos 2013].

• The paper is self-contained and applicable to a wide varietyof 3D models.

• Current approaches focus on loading dense geometry; we fo-cus on quality by using high-resolution textures on a virtualmulti-texturing engine.

• The architecture improves loading speed and maintains real-time rendering for low-performance GPUs and slow Internetconnections, which is the most common scenario on massmarket applications.

1.2 Advantages

Applications designed for real-time rendering of realistic 3D ob-jects benefit from our architecture: it is tailored for lightweightand progressive visualization of high-quality content. We put to-gether efficient techniques into an architecture able to handle ge-ometry and materials with high visual fidelity in a real-time basis

109

for the Web. We also use three.js, an active and well-documentedJavaScript 3D library with a very low level of abstraction, whichreduces both the learning curve and the development time.

1.3 Area of Interest

We assume that the scene is composed by a single static geometry(neither grouped meshes, nor multiple objects) of a few thousandpolygons (less than 200k). Loading larger geometries requires en-hanced techniques beyond entropy encoding compression. Terrainsand world environments require a different approach for compres-sion and streaming for real-time scenarios. Animation and physicalsimulations are out of the scope of the proposed architecture. Thebenchmarks and rational process of selecting the techniques repre-sent a contribution to the state-of-the-art and a partial survey of thebest techniques for fast 3D graphics on the web.

2 Literature Review

There are three predominant scientific applications that make useof 3D graphics frameworks for real-time interaction on the web:cultural heritage, geographical information systems (GIS) and 3Dcities.

Some of the first web-based frameworks used VRML (supersededby X3D) for large-scale terrain visualization [Zhu et al. 2003]; theirmajor contribution were advanced frustum culling techniques onweb platforms. Similarly, [Prieto and Izkara 2012] proposed a mo-bile platform for 3D cities; they introduced a semi-automatic datageneration tool for CityGML, an open data model for exchange andstorage of virtual 3D city models, using X3DOM [Behr et al. 2009]for direct access to CityGML data. They used progressive renderingand levels of detail (LOD), an important contribution to the mobilespace.

As HTML5 started to mature, more sophisticated techniques ap-peared for storage and streaming using WebGL: [Cellier et al. 2012;Gobbetti et al. 2012] suggested methodologies for geometry simpli-fication, compression and streaming. The approach of [Cellier et al.2012] is a reversible compression process for GIS data based onparallel geometry simplification extended from Batched DynamicAdaptive Meshes (BDAM) [Cignoni et al. 2003] and Quadric er-ror metrics (QEM) [Garland and Heckbert 1997]. The approachof [Gobbetti et al. 2012] is based on quad-patch texture atlases foradaptive tessellation on the vertex shader; they focused on closedstatic geometry that approximates the original visual representa-tion. Unlike them, we focus on visual fidelity and high-resolutiontextures.

E-commerce and cultural heritage are particularly challenging dueto the large amount of required data to produce a compelling rep-resentation of the original object, compared to applications suchas terrain or 3D cities where the user tolerates coarser represen-tations of models at certain zoom levels. Also, in contrast to 3Dcities or GIS applications, in e-commerce and cultural heritage ap-plications quality is at least as important as performance. In termsof quality, [Schwartz et al. 2011] suggested a real-time streamingscheme that subdivides and transmits high-quality materials basedon wavelet compression and bidirectional texture functions [Filipand Haindl 2009]. Texture compression is insufficient to displayhigh-resolution textures in real-time. Applications where qualityand responsiveness are important, adaptive techniques such as vir-tual textures provide little overhead on rendering time while main-taining the intended visual quality of the 3D model. Besides, bidi-rectional texture functions, or similar techniques, could be used aspart of an efficient adaptive texture mapping system such as the onedescribed in this paper.

Virtual texturing systems have been extensively used [Chajdas et al.2010; Hollemeersch et al. 2010] for large scenes using gigapixelstextures (i.e. 32,7682px). There have been some recent work onthe web space as well [Hollemeersch et al. 2012], targeting terrainsand large scenes. These large-scale systems allow loading high-resolution textures in a streaming-efficient way, which seems natu-ral for closed objects with large amounts of detail. Thus, we focusour virtual texturing on relatively smaller set of data, using texturesup to 8,1922px.

3 Architecture for High-Quality Materials

The architecture is composed by four components. The first com-ponent is input data; an object is composed by a geometry represen-tation and texture maps. The second component is the compressionstage, it handles the compression of geometry representations andtextures. The third component is streaming, it defines how geom-etry representations and textures are shipped over the network andthen merged at the client. The last component is rendering, it usesWebGL to leverage the work on the client side.

Our application is compatible with Chrome 10+, Firefox 4+, Sa-fari 6 and IE with Chrome tab. On the mobile space, Firefox andChrome for Android support WebGL. However, in order to enablevirtual texturing on mobile, the extensions for floating point tex-tures and standard derivatives must be available.

3.1 Motivation

Applications intended for scientific visualization or specialized au-diences prioritize performance and content over visual quality. We-bGL allows direct integration of 3D graphics as part of the HTMLDocument Object Model (DOM). These graphics could be part ofcurrent or future websites with real-time interaction, where visualquality is a prime factor for end-user satisfaction. High-resolutiontextures enhance the overall visual quality of a scene. Virtual tex-turing is a very suitable technique able to adapt to different hard-ware configurations with lower computational costs than geometryrefining techniques such as adaptive tessellation.

Besides, on applications for the mass market, it is required to pro-vide photo-realistic scenes with the least hardware requirements aspossible. Visual fidelity, even on small details, is important on thiskind of applications. The storage required by textures alone onthese scenarios, which is larger than triangulated meshes, motivatesthe use of image compression and virtual textures.

4 Input Data

The input data are textures and geometry. There is an offline andan online process. The offline process stores the data as geome-try (i.e. OBJ format) and three associated textures: diffuse map,specular map and normal map (i.e. JPEG and PNG formats) andmaterial description (i.e. MTL format). There are many geometryrepresentations formats available; we picked OBJ due the materialdescription provided on MTLs and its widespread use. COLLADAwas another feasible option but it was too complex for the means ofour architecture.

We assume that the geometry is a single non-grouped triangularmesh with a single material storing three 4096x4096 textures. Thetextures are then scaled down to 20482, 10242, 5122, 2562 and1282 pixels. Each mip map is the source of the tile generation tool.So, for the 1282 mip map level, we would have 1 tile; for the 2562

level, would have 4 tiles, and so on. The size of each tile is 1362px:the original 1282px tile plus a padding of 2 pixels per side. Eachtile takes the contiguous rows or columns of its neighbors. If a tile

110

is on the border of a mip map level, the padded pixels are black.The final step is compression via UTF8 or OpenCTM for geometry,and JPEG or Crunch for texture tiles.

On the online process, geometry and tiles repositories are retrievedon-demand. The geometry files are loaded by sequential XHRs(XMLHttpRequests) given that they are sufficiently small aftercompression. For tiles, we consider three options (ordered by im-plementation complexity): The first is to load tiles directly from thehard disk, we use this approach for development and debugging.The second is to use a database to store the route of tiles. The thirdis to use a lightweight image server, which is better suited to scaleup a real application.

5 Mesh Compression

UTF8 [Chun 2011] and OpenCTM [Geelnard 2009] are the twoopen source mesh compression tools tested in our implementation;they are very effective for small geometries, suitable for web appli-cations, and with storage savings by compression of over 85%. Forlarger geometries, parameterization techniques show better overallresults; however, they tend to decrease the perceived image qualitydue mesh degradation. [Gobbetti et al. 2012] shows good resultsusing a texture atlas of quad patches to store the geometry but theirmodels lack high-quality materials.

The UTF8 compression is a lossy technique (see Figure 2) that re-lies on the relationship between normals and positions of triangles.It improves compression by predicting the normal direction fromneighborhood positions of incident triangles [Chun 2011]. The datais encoded using the UTF-8 character set: 16-bit values taking 1-3bytes per character. So, the lower the values, the lesser memory thealgorithm requires for encoding a mesh.

OpenCTM provides a very compact representation of 3D trianglemeshes using entropy-reduction techniques combined with a stateof the art Lempel-Ziv-Markov chain algorithm (LZMA). UnlikeUTF8, OpenCTM is a lossless compression technique. It is alsopossible to use a lossy algorithm in order to improve the compres-sion ratio.

On the server side, we have gzip enabled for UTF8 files in order toimprove its compression ratio. Although this step is transparent forthe user, gzip decompression adds computational overhead to theclient. So, both UTF8 and OpenCTM decompresses the file on thefly before decoding, whereas UTF8 uses a native gzip implemen-tation and OpenCTM uses a LZMA implementation on JavaScript.OpenCTM already uses the same LZMA technique for mesh com-pression, then the use of gzip with OpenCTM would add extra byteson top of the already compressed file.

Figure 2: The image shows two frames of the red leather jacket.On the left, the UTF8 (lossy) version; on the right, the JSON (nocompression) version. On the UTF8 version, the uv compressionshows errors on the texture alignment.

6 Texture Compression

Todays graphics cards allow textures to be stored in compressedformats and to decompress them during rasterization in real-time.Most graphics cards support DXT (also known as S3TC). Texturesare usually pre-generated in DXT to avoid the compression over-head on the fly. DXT textures are designed to be fast to decode inthe GPU, but its compression rate is behind the rate of other com-mon formats on the web, such as JPEG. On web applications, datacompression is critical in order to decrease the amount of data sentover the network.

Crunch [Geldreich 2010] is a lossy compression technique thatquickly transcodes the compressed texture into DXT. AlthoughCrunch and JPEG have a similar bit-rate and image quality, Crunchhas faster transcoding to DXT, which makes it suitable for Web ap-plications: smaller textures sent over the network and faster texturereads. The increasing interest on techniques for fast GPU transcod-ing and low bit compression rates is mainly due the scarce mem-ory and computational resources on mobile devices. Android-basedsystems use ETC1 (4 bits per pixel, or bpp) and iOS-based systemsuse PVRTC (2 bpp). PVRTC suffers of significant quality loss dueits low bit compression rate. Although ETC1 compresses textureswith better quality than PVRTC, its compression rate is 25% morethan JPEGs (which is below 3 bpp) [Strom and Wennersten 2011;van Waveren 2006].

We compare JPEG and Crunch in our implementation. One of thedisadvantages of Crunch is that is not meant to compress textureson the fly. We compress textures offline using an in-house pythonscript. The texture repository is stored on the server, so the user isagnostic of what type of image is being loaded as texture.

7 Load on Demand

Geometry and textures can both take advantage of on-demandstreaming. However, the current work focuses on texture stream-ing. The tile repository consists of three different sets of textures:diffuse maps, specular maps and normal maps.

The steps of our implementation are decomposed into:

1. Tile determination

2. Tile streaming

3. Rendering with a special shader

The scene is rendered in two steps, one for tile determination andthe other for rendering. The first pass stores texture’s uvs and thecorresponding mip map level of the visible geometry into an RGBrender target of 1/8th of the original canvas size. Then, the read-Pixels function copies the render target into a frame buffer on CPUmemory. Next, the set of tiles required for the visible geometryis sent to a Least Recently Used (LRU) cache system in order todetermine how to proceed: load tile, tile already on cache, releasetiles, etc. Changes to the cache require an update of the three phys-ical textures and the indirection table texture on the GPU. At theend, the special shader translates the indirection table texture coor-dinates into the physical texture coordinates in order to sample therequired tile at the right position. Due to a recently increased in-terest on this topic, there are multiple references that describe thisprocess in more detail [Chajdas et al. 2010; Hollemeersch et al.2010; Mayer 2010].

7.1 Virtual Texturing

High-resolution textures can improve the perceived quality of ascene. Quality is usually sacrificed in order to maintain interac-

111

tive download rates on web applications. A virtual texturing systemrelies on a tile cache method that determines the tiles needed at agiven time, and to stream these tiles to the GPU. It combines alltextures of a scene into a single big texture (three in our case).

The layout of a virtual texturing system can vary enormously due tothe diversity of users hardware and bandwidth availability. We as-sume that the user has a slow Internet connection (at most 1 megabitper second), and low or medium-end GPUs. A system that adaptsitself to different hardware and bandwidth configurations could bepossible by using a server-side module that retrieves the requestedtiles as shown in [Hollemeersch et al. 2012]; performance mightbe affected yet a more flexible implementation could forsake thedisadvantages.

We use the following configuration:

• Virtual texture size: 81922 pixels.

• Physical texture size: 20482 pixels.

• Tile size: 1282 pixels.

• Indirection table size: 642 pixels.

We manage three different physical textures of 20482 pixels each:diffuse map, specular map and normal map. Since these three phys-ical textures share the same layout, they use the same indirectiontable texture. The tile size is an important factor for real-time per-formance. Big tiles imply lesser updates to the indirection tableand to the physical texture, but they take more time to load. Smalltiles are the counterparts. Even though, the performance gain stopson 1282px per tile. The loading time of 1282px and 642px tilesis around 20ms for both cases using XMLHttpRequests [Mayer2010].

7.2 Tile Streaming

Virtual textures are the basis of a scalable streaming system thatadapts to different client characteristics, such as GPU processingpower and network bandwidth availability.

Although the server stores three tiles repositories in our implemen-tation, it is possible to use only one (i.e. diffuse maps) or add newtexture types (i.e. bump maps). The first iteration stored all 3Dmodel data in a MongoDB collection. A database is a simple-to-go solution and would work for proof-of-concepts purposes, as de-scribed in [Gobbetti et al. 2012]. However, a file system approach isbetter suited for retrieving tiles as it is a dynamic environment. Ourfuture work involves the implementation of such system, similar to[Hollemeersch et al. 2012].

The server streams data asynchronously during the rendering pro-cess. The client requests the missing tiles according to the list ofvisible tiles created on the tile determination stage. The queue callsthe load function in a first-in first-out (FIFO) basis, and the tilesbecome available as soon as they are transmitted over the network.The loading stage limits the number of the load functions called by10, so the amount of images requested per frame are up to 30. It isimportant to note that the frame is only updated whether the cameramoves or new tiles are available on the GPU.

7.3 Rendering: Virtual Texturing Shader

A texture array stores the three physical textures of 20482 px andan extra texture of 642 px stores the indirection table on the GPU.The first rendering pass computes the mip map level and uvs of thefragment. This information is then read from the CPU in order todetermine the visible tiles on the frame. The new tiles are queued

and loaded asynchronously. Next, physical textures and the indi-rection table texture are updated in the GPU. Finally, the scene isready to draw a new frame on screen. The system adds the scaleduv-coordinate fraction to the tile position in the physical texture.This value is the new uv-coordinate for the texture mapping of thefragment shader. The process is done once for the three physicaltextures. The tiles are stored in the same layout, so the indirec-tion table is valid for all the physical textures. It is possible to addmore physical textures, such as bump maps, and the implementa-tion would remain almost the same. Regarding correctness, we usea 2-pixel padding per side and anisotropic filtering.

Since we work with static objects on a simple scenario, the ren-derer computes a new frame when the camera moves or if new tilesare available. This way, we decrease the amount of work done bythe GPU. Empirically, we have experimented problems with a widerange of WebGL application where browsers consume too manyGPU and RAM resources. This lead to overheat the GPU and to fillthe memory with unused data.

7.4 Challenges

Performance and correctness are the two major challenges of a vir-tual texturing system. The main bottleneck of the system is thetile determination operation, specifically the readPixels function.OpenCL or CUDA kernels [Hollemeersch et al. 2010] have beenwritten to decrease the computation time of the tile determinationoperation, but this is not possible in a web environment yet, as We-bCL has not been officially released. Another option is to use Web-Workers to parallelize the computation using a reduce algorithm onthe CPU. This method will be explored in future work. On correct-ness, the texture tile streaming must be very efficient to decreasethe amount of artifacts when a tile is not available for rendering.The amount of artifacts depends on the ability to predict the nexttiles to be loaded, the tile determination operation and the networkbandwidth available. Also, tiles’ borders are special cases due tosmall discontinuities on the uv-calculation on the GPU (see Figure3).

On the mobile space, Android systems support up to 40962 px tex-tures whereas iOS systems support up to 20482px textures. FirefoxMobile and Chrome Beta supports WebGL on Android; there is noofficial support for iOS yet. Our virtual texturing system is wellsuited for the mobile space; however, both OES texture float andOES standard derivatives WebGL extensions are not widely sup-ported on mobile platforms yet. The indirection table texture andthe mip map level calculation stage use these extensions.

Figure 3: The image shows the uv-discontinuities (yellow) on thered leather jacket. These discontinuities are always on the borderof tiles.

112

Dataset # Faces OBJ UTF8 CTMMilitary J. 16,834 982 kb 120 kb 86 kbBunny 69,451 2,455 kb 434 kb 162 kbLeather J. 142,129 9,664 kb 1,104 kb 614 kbBuddha 1,087,716 41,426 kb 6,639 kb 2,257 kb

Table 1: File size comparison of CTM compression against PLYand OBJ formats of tested models. File size is in kilobytes.

Dataset CTM Saving UTF8+gzip SavingMilitary J. 86 kb 88% 45 kb 95%Bunny 162 kb 82% 146 kb 94%Leather J. 614 kb 89% 547 kb 94%Buddha 2,257 kb 84% 2,203 kb 95%

Table 2: Data compression benchmark utf8+gzip vs ctm. The Filesize is in kilobytes (KB).

8 Implementation and Results

The system uses clothing models as example in order to show itslevel of detail and its performance. Current websites might take ad-vantage of our approach by displaying 3D models as part of theircontent on applications such as e-commerce, ads, galleries, scien-tific visualization, etc.

We provide a couple of standard 3D models for standard academiccomparisons on geometry compression. The architecture is de-signed to handle high-resolution textures to show the real poten-tial of our methodology, though we do not focus on acquiring orcreating this kind of content.

8.1 Mesh Compression Rates

Tables 1 and 2 show compression results using OpenCTM v1.0.3and UTF8 r100 libraries. Both libraries show similar results. UTF8outperforms OpenCTM when gzip is activated. Since UTF8 is alossy technique, it is not well suited for textured objects since thetexture mapping tends to be misplaced due uv-truncation. On smallfiles, a difference of less than 10% on the compression ratio is in-significant. So, for a virtual texturing engine where visual qualityis a must, OpenCTM is a better choice. However, the system isagnostic of the type of compression used.

The military jacket and the red leather jacket store vertices, normalsand texture coordinates; whereas the Stanford bunny and the happyBuddha models just store vertices and index information.

Type Format Size Ratio

diffuse crn 3.2 KB 1.4 bppjpg 5.9 KB 3.0 bpp

normal crn 2.4 KB 1.1 bppjpg 4.7 KB 2.1 bpp

specular crn 2.5 KB 1.1 bppjpg 5.4 KB 2.4 bpp

Table 3: Three tiles’ sets of 1362px for the red leather jacket. Theresults are averaged from 1365 tiles corresponding to multiple mipmap levels. The table compares both JPG and CRN tiles given theiraverage size (kilobytes) and their bits per pixel (bpp).

Stage Time TotalRender to texture 1 ms 3%Copy render target to CPU 20 ms 63%Determine visible tiles 4 ms 13%Update physical textures 5 ms 16%Render frame 2 ms 6%Total 32 ms 100%

Table 4: Average time spent on each stage for the red leather jacket.The readPixels function is the main bottleneck of our virtual textur-ing system.

8.2 Texture Compression Rates

The data set consists of the tiles produced from the original 40962

sets of textures (diffuse, specular and normal). The JPEG tiles wereexported with quality set to 99% since the average size of a tile de-creases in 15% with the lose of only 1% of quality. The CRN coderis configured to output an image of similar JPEG quality. In aver-age, the system makes three requests for each visible tile in orderto download three images of a total size of 8.1 KB for CRN and16 KB for JPEG. The major advantage of CRN against JPEG is thefast DXT transcoding. Our tests show that CRN is up to 8 timesfaster than JPEG on this operation. CRN takes 2-3 ms to transcodeto DXT in our NVIDIA GeForce 330M with 256 MB video mem-ory while JPEG takes 18-24 ms. The results are averaged from thered leather jacket tiles of 1362 pixels (see Table 3).

8.3 Rendering

The tests were performed in a MacBook Pro (mid 2010) with anIntel Core i5 2.53Ghz, 4GB DDR4 1067 MHz, a NVIDIA GeForceGT 330M with 256MB of video memory, and running Mac OS XLion 10.7.5. On future implementations, we would like to test withIntel integrated chips since they are of considerable lower capabili-ties than discrete graphics cards. We use Chrome 24.0.1312.57 anda fixed resolution of 900x600 with continuous camera movementsranging from far views, close views and camera rotation. Table4 shows the average computation time per stage of our renderingpipeline.

The biggest issue in our system is that the CPU-GPU communi-cation is slow for real-time applications. The readPixels functionrepresents more than the 50% of the time spent computing the nextframe. There are some tricks to further decrease the total renderingtime, though we provide a solution that maintains 30 frames persecond on most cases.

8.4 Network Streaming

Since our focus is to replicate real-world conditions with slow In-ternet connections, we restrict the bandwidth to 1Mbit/s and thelatency to 0 ms with ipfw (see Appendix A). Rendering is progres-sive; if the requested tile is not available a tile of lower resolution isrendered instead.

The original red leather jacket consisted of one OBJ file (9.9 MB)and three 40962 JPEG textures at 100% quality, diffuse (7.2 MB),specular (5.5 MB) and normal (5.1 MB) map. The total size ofthis model was 27.7 MB. The textures were exported from PSDsto lossless RGB-PNGs using Gimp, and then exporting it as a non-progressive JPEG using PIL. The geometry is scaled to fit into a1-unit bounding box and then exported as OBJ from Blender. Thenaive loading would take at least 5 minutes with the mentioned re-strictions and occasional browser freezing. With compression and

113

virtual texturing, we achieve a first low-quality render in 3 secondsand similar visual quality in 5 seconds. We consider that it is pos-sible to further improve the overall speed on at least 25-50% withsome optimizations on the implementation.

9 Future Work

There are many possible improvements to the implementation ofthe current architecture that would extend its application domain.

We assume that the loaded geometry is of a few thousand poly-gons (less than 200k). In order to load geometries of a few millionspolygons in a fraction of seconds, WebWorkers should be imple-mented by splitting the geometry into multiple segments. Thesesegments would be loaded independently and rendered as soon asthey become available. Other approaches beyond compression in-clude sparse voxel octrees or geometry parameterization.

Given that we already use a set of three textures, it would be possi-ble to include a specular map into the A channel of the normal map,reducing the number of tiles to fetch from three to two. Also, bystoring the fine-grained detail into a normal map of automatic dec-imated geometry, we could reduce the number of polygons with-out impacting the visual fidelity of the original scene. This pro-cess can be performed offline. A lightweight image server wouldallow a more flexible implementation with adaptable layouts (tilesize, physical texture size, border per tile, etc) according to differ-ent hardware and network availability on the client side. As WebCLbecomes available, new techniques can be introduced by download-ing physical simulations and realistic animation calculations to theGPU.

Regarding compression, techniques such as multisided patch com-pression [Gao and Rockwood 2005] could improve loading speedof very large data sets. Sparse voxel octrees could also be an optionfor large scenes, yet the computational cost could be too high forcurrent hardware on real-time applications.

10 Conclusion

Many recent applications (i.e. cultural heritage, ecommerce, terrainmodeling, engineering tools, 3D cities) need to process 3D dataon the web in real-time. In this paper we specified a general andflexible architecture for lightweight visualization of high-resolutiontextures on 3D models. We implemented the basic design of thearchitecture with real -time results and a flexible platform ready toextend its application domain.

Lightweight visualization is a major challenge for computer graph-ics on the web. The architecture’s components address different re-search areas independently, such as compression, geometry simpli-fication, visual fidelity, frustum culling, streaming, among others.As WebGL becomes widely available on consumer applications,users will face network bandwidth and GPU processing power is-sues, which we try to minimize by reducing the set of data theystream over the network.

A Network Simulation

Bash commands to restrict bandwidth and latency on a system.

# display current rulesipfw show

# create pipe with preferred settingsipfw pipe 1 config delay 0ms bw 1024kbit/sipfw add pipe 1 dst-ip 127.0.0.1 dst-port 8000

# flush all the rulesipfw flush

References

BEHR, J., ESCHLER, P., JUNG, Y., AND ZOLLNER, M. 2009.X3dom: a dom-based html5/x3d integration model. In Proceed-ings of the 14th International Conference on 3D Web Technol-ogy, ACM, New York, NY, USA, Web3D ’09, 127–135.

CELLIER, F., GANDOIN, P.-M., CHAINE, R., BARBIER-ACCARY, A., AND AKKOUCHE, S. 2012. Simplification andstreaming of gis terrain for web clients. In Proceedings of the17th International Conference on 3D Web Technology, ACM,New York, NY, USA, Web3D ’12, 73–81.

CHAJDAS, M., EISENACHER, C., AND LEFEBVRE, S. 2010. Vir-tual Texture Mapping 101. In GPU Pro, W. Engel, Ed. AK Pe-ters, June.

CHUN, W., 2011. Utf8: Webgl loader. http://code.google.com/p/webgl-loader/.

CIGNONI, P., GANOVELLI, F., GOBBETTI, E., MARTON, F.,PONCHIO, F., AND SCOPIGNO, R. 2003. Bdam batched dy-namic adaptive meshes for high performance terrain visualiza-tion. Computer Graphics Forum 22, 505–514.

FILIP, J., AND HAINDL, M. 2009. Bidirectional texture func-tion modeling: A state of the art survey. Pattern Analysis andMachine Intelligence, IEEE Transactions on 31, 11 (nov.), 1921–1940.

GAO, K., AND ROCKWOOD, A. 2005. Multi-sided attribute basedmodeling. In Proceedings of the 11th IMA international confer-ence on Mathematics of Surfaces, Springer-Verlag, 219–232.

GARLAND, M., AND HECKBERT, P. S. 1997. Surface simplifi-cation using quadric error metrics. In Proceedings of the 24thannual conference on Computer graphics and interactive tech-niques, ACM Press/Addison-Wesley Publishing Co., New York,NY, USA, SIGGRAPH ’97, 209–216.

GEELNARD, M., 2009. Openctm. http://openctm.sourceforge.net/.

GELDREICH, R., 2010. Crunch. http://code.google.com/p/crunch/.

GOBBETTI, E., MARTON, F., BALSA RODRIGUEZ, M., GANOV-ELLI, F., AND DI BENEDETTO, M. 2012. Adaptive quadpatches: an adaptive regular structure for web distribution andadaptive rendering of 3d models. In Proc. ACM Web3D Inter-national Symposium, New York, NY, USA, ACM Press, 9–16.(Best Long Paper Award).

HOLLEMEERSCH, C.-F., PIETERS, B., LAMBERT, P., ANDDE WALLE, R. V. 2010. Accelerating virtual texturing usingcuda. In GPU Pro, W. Engel, Ed. A K Peters, 623–642.

HOLLEMEERSCH, C.-F., PIETERS, B., DEMEULEMEESTER, A.,LAMBERT, P., AND VAN DE WALLE, R. 2012. Real-timevisualizations of gigapixel texture data sets using html5. InProceedings of the 18th international conference on Advancesin Multimedia Modeling, Springer-Verlag, Berlin, Heidelberg,MMM’12, 621–623.

KHRONOS, G., 2013. Webgl specification. http://www.khronos.org/webgl/.

114

MAYER, A. J. 2010. Virtual Texturing. Master’s thesis, Institute ofComputer Graphics and Algorithms, Vienna University of Tech-nology, Favoritenstrasse 9-11/186, A-1040 Vienna, Austria.

PRIETO, I. N., AND IZKARA, J. L. 2012. Visualization of 3d citymodels on mobile devices. In Proceedings of the 17th Interna-tional Conference on 3D Web Technology, ACM, New York, NY,USA, Web3D ’12, 101–104.

SCHWARTZ, C., RUITERS, R., WEINMANN, M., AND KLEIN,R. 2011. Webgl-based streaming and presentation frame-work for bidirectional texture functions. In Proceedings of the12th International conference on Virtual Reality, Archaeologyand Cultural Heritage, Eurographics Association, Aire-la-Ville,Switzerland, Switzerland, VAST’11, 113–120.

STROM, J., AND WENNERSTEN, P. 2011. Lossless compressionof already compressed textures. In Proceedings of the ACM SIG-GRAPH Symposium on High Performance Graphics, ACM, NewYork, NY, USA, HPG ’11, 177–182.

VAN WAVEREN, J. M. P., 2006. Real-time dxt compression, May.

ZHU, C., TAN, E. C., KAI, T., AND CHAN, Y. 2003. 3d terrainvisualization for web gis. In Map Asia 2003, Kuala Lumpur.

115

Figure 4: Multiple frames of two 3D models, a red leather jacket and a green military jacket. The second image shows the military jacketwith coarse tiles; fine-grained tiles are being loaded. The last four images show frames of high-resolution tiles after zooming in.

116