E-LETTER - IEEE Communications Society

More documents

Recommendations

Info

IEEE COMSOC MMTC E-Letterrepresented in a procedural form, such that onlythe ground extent, building height, and somestyle and color parameters have to be stored, anda 3D representation is created from thedescription on the fly. Full realism may not evenbe a desirable target in a navigation system asthey may more distract the user than aid her.Symbolic representations with simple, clear lines,and clear audio instructions may be betterchoices, especially when one is driving a car andneeds to make decisions about where to drivequickly.GamesThe first mobile games had very simplegraphics. Snake was a very popular mobilephone game, where the snake grows in length asone captures more points, and becomes moredifficult to maneuver without the head hitting awall or the snake itself and thus ending the game.With color displays came various sports andrally games, and today games of almost anygenre are available on mobile devices.Before standard mobile 3D APIs games cameeach with their own proprietary softwarerendering engines. Even the launch of OpenGLES 1.0 and 1.1 didn’t change the situation much,as a special engine is always faster than a genericone. As graphics hardware began to appear, thegames began to use standard APIs, and soonproprietary engines will disappear as OpenGLES 2.0, which allows a new level of visualrichness, will be widely available.While native games (written in C or C++) arevery closely tied to a particular device family,and even to an individual model, mobile Javaaims for application portability across differentdevice manufacturers. M3G (JSR-184) wasdefined to be compatible with OpenGL ES sographics hardware developed for OpenGL EScould be leveraged for M3G [11]. In addition tobasic rendering, the API supports features usefulin game engines such as scene graphs,sophisticated animation, and a compact fileformat for 3D content. While fast-pacedgraphics-rich action games tend to be native anduse OpenGL ES, far more games have beenwritten with the more portable M3G [1]. AsOpenGL ES 2.0 allows shaders for nativeapplications, M3G 2.0 (JSR-297) allows use ofshaders from mobile Java applications.Web and browsersMobile web used to, and had to be differentfrom the desktop web experience, as the mobiledata bandwidth and the screen sizes were bothvastly smaller than on a desktop or laptop PC.This is now rapidly changing, and newsmartphones have very complete web browsersproviding a “one-web” experience, where theweb is experienced in essentially the same wayon any device. This is one of the new drivers forgraphics performance on mobile phones.Another recent development is re-birth of theidea of 3D graphics on the web. VRML, andlater X3D attempted to be standard 3Ddescriptions for web content, but they neverreally took off. There were also proprietary 3Dengines running on browsers, (e.g.,Macromedia’s Shockwave), but they didn’tsucceed either. Khronos group has a newworking group for 3D Web, where they arecreating essentially OpenGL ES 2.0 bindings toJavaScript. Most major browsers are representedin the working group, and the new standard mayfinally bring hardware-accelerated 3D graphicsboth to mobile and desktop browsers.Augmented RealityAugmented Reality (AR) enhances oraugments user’s sensations of the real worldaround her, typically by rendering additionalobjects, icons, or text that relate to the realobjects. Whereas traditional AR systems tendedto have wearable displays, data goggles, themobile AR systems capture the video streamfrom the camera on handheld device’s rear side,and post the augmented image on the display,providing a “magic lens”. A use case for an ARsystem could be a tourist guide helping the userto navigate to a destination and labeling objectsof interest, or an educational system pointing tosome device’s controls in a correct sequence,together with operation instructions. AR is aclass of graphics applications that makes muchmore sense in a mobile setting than at one’s deskwith a desktop PC.A key enabler for AR is image recognitioncapability, so the system knows what is visible,and also where in the field of view of the camerathe object is located, so that it can be annotatedor augmented. A secondary tool is efficienttracking, so that the labels, arrows, icons, etc.,remain attached to the correct objects even whenthe user moves the camera around [5, 12].Recent advances in computer vision algorithms,together with increased capabilities of cameraphones equipped with other sensors such as GPShttp://www.comsoc.org/~mmc/ 12/41 Vol.4, No.7, August 2009
IEEE COMSOC MMTC E-Letterand compass, allow simple mobile ARapplications running in real time. There aredemos and startups that provide informationoverlay using only GPS and compass [6, 7], andothers that also use cameras to recognize targets[10]. Some simple AR games only requiresimple motion tracking: in Mosquito Hunt fromSiemens virtual mosquitos drawn over thebackground of a camera image seem to attack theuser, who tries to get them to a cross hair and zapthem first.GPUs and GPGPUThe driving force of desktop graphicsprocessing units (GPU) has been increasingperformance in terms of speed. While speed isimportant also with mobile GPUs, even moreimportant is low power consumption. Theirdesign differs from desktop GPUs, for examplemobile GPUs can’t afford to get performance bysimply adding more parallel processing. The firstgeneration of mobile GPUs was designed for thefixed functionality of OpenGL 1.X, the secondgeneration allows use of vertex and fragmentshaders of OpenGL 2.0.As desktop GPUs got more powerful,programmers wanted to use them also for othercalculations. General purpose processing onGPUs, also known as GPGPU, uses graphicshardware for generalized number crunching.GPGPU is also now becoming attractive onmobile devices. Many image processing andcomputer vision algorithms can be mapped toOpenGL ES 2.0 shaders, benefiting from thespeed and power advantages of GPUs.Unfortunately the second generation of mobileGPUs was only designed for graphics processingand does not support efficient transmission ofdata back to CPU from GPU. Careful schedulingof processing may allow data readback from aprevious image to proceed while the next imageis being processed, reducing the transferoverhead. With the advent of OpenCL (OpenComputing Language) [3], a GPGPU APIsimilar to NVidia’s CUDA except that it isvendor-independent, and can run on CPUs andDSPs in addition to GPUs, the third generationof mobile GPUs will have better support forefficient data transfer. OpenCL will allow betterportability for many image processingalgorithms both on desktop and on mobiledevices.REFERENCES[1] M. Callow, P. Beardow, and D. Brittain,“Big Games, small screens”, ACM Queue,Nov./Dec., pp. 2-12, 2007.[2] T. Capin, K. Pulli, and T. Akenine-Möller,“The State of the Art in Mobile GraphicsResearch”, IEEE Computer Graphics andApplications, vol. 28, no. 4, pp. 74 - 84,2008.[3] Khronos OpenCL Working Group, A.Munshi Ed., “The OpenCL Specification,Version 1.0, Rev. 43”, Khronos Group,USA, May 2009.http://www.khronos.org/opencl/[4] Khronos OpenVG Working Group, D.Rice and R. Simpson Eds., “OpenVGSpecification, Version 1.1”, KhronosGroup, USA, Dec. 2008.http://www.khronos.org/openvg/[5] G. Klein, “PTAM + AR on an iPhone”,http://www.youtube.com/watch?v=pBI5HwitBX4[6] Layar: http://layar.eu/[7] MARA:http://www.technologyreview.com/Biztech/17807/[8] A. Munshi and D. Ginsburg, “OpenGLES 2.0 Programming Guide”, Addison-Wesley Professional, 2008.[9] A. Nurminen, “Mobile 3D City Maps”,IEEE Computer Graphics andApplications, vol. 28, no. 4, pp. 20-31,2008.[10] Point&Find:http://pointandfind.nokia.com[11] K. Pulli, T. Aarnio, V. Miettinen, K.Roimela, and J. Vaarala, “Mobile 3DGraphics with OpenGL ES and M3G”,Morgan Kauffman, 2006.[12] D. Wagner, “High-speed natural featuretracking”, http://studierstube.icg.tugraz.ac.at/handheld_ar/highspeed_nft.phphttp://www.comsoc.org/~mmc/ 13/41 Vol.4, No.7, August 2009
Page 1: IEEE COMSOC MMTC E-LetterIEEE MULTI
Page 4 and 5: IEEE COMSOC MMTC E-Lettera thin str
Page 6 and 7: IEEE COMSOC MMTC E-LetterHow to Sub
Page 8 and 9: IEEE COMSOC MMTC E-LetterAnother im
Page 10 and 11: IEEE COMSOC MMTC E-Letterthe multim
Page 14 and 15: IEEE COMSOC MMTC E-LetterKari Pulli
Page 16 and 17: IEEE COMSOC MMTC E-Letterdescribes
Page 18 and 19: IEEE COMSOC MMTC E-LetterREFERENCES
Page 20 and 21: IEEE COMSOC MMTC E-LetterOne limita
Page 22 and 23: IEEE COMSOC MMTC E-Letter3D Visual
Page 24 and 25: IEEE COMSOC MMTC E-LetterIn 1996 he
Page 26 and 27: IEEE COMSOC MMTC E-Letterstudents d
Page 28 and 29: IEEE COMSOC MMTC E-Letterrepresenta
Page 30 and 31: IEEE COMSOC MMTC E-Letterwireless n
Page 32 and 33: IEEE COMSOC MMTC E-Letter25. D. Mic
Page 34 and 35: IEEE COMSOC MMTC E-LetterEditor’s
Page 36 and 37: IEEE COMSOC MMTC E-Lettercorrespond
Page 38 and 39: IEEE COMSOC MMTC E-Letterchair of t
Page 40 and 41: IEEE COMSOC MMTC E-LetterCall for P

E-LETTER - IEEE Communications Society

Create successful ePaper yourself

Delete template?

Save as template?