
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[10pt, conference, compsocconf]{IEEEtran}
% Add the compsocconf option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
% \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.


%\usepackage[latin1]{inputenc}
\usepackage{mathrsfs} 
\usepackage[pdftex]{graphicx}
\usepackage[brazil,english]{babel}
\usepackage[caption=false,font=footnotesize]{subfig}
\usepackage{url}


\usepackage[table]{xcolor}
\usepackage{multirow}

\usepackage{amsmath}

\usepackage{graphicx,url}


% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Real-Time Label Visualization in Massive CAD Models}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

\author{\IEEEauthorblockN{Renato Deris Prado, Alberto Barbosa Raposo}
\IEEEauthorblockA{Tecgraf Institute\\
Pontifical Catholic University of Rio de Janeiro\\
Rio de Janeiro, Brazil\\
rdprado@tecgraf.puc-rio.br, abraposo@tecgraf.puc-rio.br}
%\and
%\IEEEauthorblockN{Authors Name/s per 2nd Affiliation (Author)}
%\IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\
%line 2: name of organization, acronyms acceptable\\
%line 3: City, Country\\
%line 4: Email: name@xyz.com}
}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3}, 
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
Virtual Labels are used in computer graphics applications to represent textual information arranged on geometric surfaces. Such information consists of names, numbering, or other relevant data that need to be noticed quickly when a user scans the objects in the scene. This paper focuses on the so-called massive models, which have a large number of geometric primitives whose rendering presents a high computational cost and for which conventional texturing techniques can extrapolate the available computational resources. In this work we have developed a way to view, in real time, virtual labels with different information on the surfaces of objects in massive models. The technique is implemented entirely on the GPU, and shows no significant loss of performance and low memory cost. CAD models' objects are the main focus of the work, although the solution can be used in other types of objects once their texture coordinates are adjusted correctly.

\end{abstract}

\begin{IEEEkeywords}
Surface labeling; Real time visualization; Massive CAD Models.

\end{IEEEkeywords}


% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



%==========================================
\section{Introduction}
%
Virtual labels are textual information displayed on the surfaces of virtual objects. Such information consists of names, numbers, and any relevant information that needs to be identified when the user scans the objects in the virtual scenario. Labels could be used in games, maps or any other graphical application which renders 2D or 3D objects and needs to show text on those objects' surfaces. This paper focuses on real-time 3D visualizers of models with a large number of objects, like CAD (Computer Aided Design) models such as an oil refinery.

In industrial plants there are structures that contain labels applied to their surfaces, which display the names of these structures or other information about them, in order to help professionals to easily identify them in fieldwork. The same way that these labels help engineers identify the real structures, virtual labels can help users in identifying objects in visualization software in real time.

The main goal when displaying labels on the surfaces of virtual objects is to help the user to quickly identify relevant information about the objects being displayed on the application, as well as to provide support for guidance in the virtual scenario. In CAD visualization systems, it is usual to have a list showing the names of all the objects present in the scene. Thus, to find the name of an object, the user needs to click on the object and check in the list for the selected name, which is a more laborious process than reading labels directly on the objects. Moreover, large industrial plant models are typically massive, so called when they present great complexity, such as an oil refinery consisting of millions or billions of objects~\cite{Yoon:2008:RTM}.

For this kind of model, there are some challenges for rendering virtual labels; one of them is related to the existence of a large number of objects with distinct names. To illustrate this problem, if a simple texturing method is used, it could be necessary to build a different texture for each object (because each object has a different name). Such an approach implies a large use of memory space that can exceed the capacity of the video card. To solve this problem, it is necessary to develop strategies to keep in video card memory a limited number of textures per frame. It is also possible that all textures could not be stored in main memory at the same time and thus they would need to be reconstructed to form the words of a label in real time, which can affect the performance of the application.

Even in a scenario where one can store a different texture for each object, there is still the need to perform multiple texture context switches per frame, which can become the bottleneck of the graphical application~\cite{NVIDIA:2004}. Another challenge is the positioning of labels on objects with different geometries and sizes, making it necessary that the virtual labels are automatically positioned by the application.

These problems (excessive use of video memory, many texture context switches per frame, and the positioning of labels on different surfaces) encourage the exploration of solutions for the real time display of labels in massive models. Since the visualization of massive models has itself a high computational cost, it is necessary to devise a solution that does not worsen the performance and spends the least possible amount of memory.

This paper presents a technique for displaying virtual labels in massive models implemented entirely in the GPU. This technique does not cause significant performance loss regardless of the number of objects that display labels and consumes little video memory with labels coded and stored in a buffer in the graphics hardware. The technique relies on a two-pass algorithm. The first pass performs the rendering of the scene and stores texture coordinate information in off-screen buffers. The second pass uses the information from these buffers to map the labels on virtual objects, calculating the final color of each pixel of the screen individually by sampling a texture that contains all characters.

This paper is organized as follows. Section 2 presents work related to the rendering of textures with textual information. Section 3 describes the technique developed in this work and Section 4 discusses how to position labels on CAD objects. Section 5 shows the results and Section 6 concludes the paper.



%------------------------------------------------------------------------- 
\section{Related work}
%
There are only a few works that directly address the problem of real time text rendering in massive models. This section briefly discusses some of these works and shows others that address more general problems regarding text rendering (such as label positioning, memory management, and aliasing)  relating them to issues if applied to the case of virtual labels in massive models.

The commercial software Aveva Review~\cite{AVEVA:2010} can display labels on the surfaces of cylinders and boxes from CAD models. Not all of them show their labels at the same time --- there is a strategy to select which objects display their names at each frame; apparently, it prioritizes the ones with a larger size in screen space.

Something that can make an application limit the number of objects that display labels is the number of texture context switches that may be required at each frame, since each object has a different name. To solve the problem of multiple texture context switches, NVIDIA~\cite{NVIDIA:2004} introduced the concept of ``texture atlas", which  groups images into a single texture, and uses texture coordinates to access the relevant sub-rectangle of the atlas. In this paper we use an atlas that stores all the required characters, and the labels need to be built from that atlas.

There are other works that do not directly address massive models, but address issues related to text rendering. Qin, McCool and Kaplan~\cite{Qin:2006:RTV} present a way to perform text rendering on three-dimensional objects using a vector graphics image representation of text, so that characters show very little aliasing when magnified. They use a strategy similar to the one in ``Texture Sprites"~\cite{LHN05} to place the words on 3D objects. However, they use a quadtree in the CPU to store a table of characters with different resolutions depending on the complexity of each character and a ``sprites table" to arrange the words. The table is encoded in the graphics hardware as a texture, so that it can be sampled directly in the GPU. As in ``Texture Sprites", the technique is presented for a single object at a time. 

Cipriano and Gleicher~\cite{Cipriano:2008:TSE} focus on text positioning on surfaces with sharp curvatures and even with holes. For this, they create meshes, called scaffolds, to store the letters and then place them so that they float over objects. A single atlas is used to store all the characters and the texture coordinates of the scaffolds are configured in order to obtain the relevant characters. One difficulty in using this solution is the introduction of new geometries in the scene, which may be undesirable in massive models rendering, especially when all objects need to display some text. Another work that focuses on label positioning was presented by Ropinski et al. \cite{Ropinski07internallabels}, but it is target at medical illustrations and does not explore large models.

Cmolik and Bittner \cite{Cmolik:2010} present a labeling method targeted at interactive illustration of 3D models. Their labels are positioned externally to the objects and the main focus of the work is on the dynamic repositioning of labels. That method does not support models with a large number of labels, since the performance decays linearly with the number of labels. 

The use of virtual textures as an out-of-core solution for textures that occupy a large space and cannot be entirely stored in memory was explained by Barret~\cite{Barret:2008} and Mittring~\cite{Mittring:2008:AVT}. A ``virtual texture" is stored on the hard drive and split into parts of equal size, called pages. Only the necessary pages for the graphics API are transferred to memory and stored in a ``physical texture" as called by Barret. To map the virtual pages into physical pages, a page table is built.

In the case of virtual labels, they would need to be built as textures in pre-processing and arranged in a virtual texture, which could solve the problem of memory. The problem lies in how to organize the virtual texture, because the names of the objects vary in size and it would require that the page size (which is the same for all pages) be sufficient to contain the biggest name. This would imply pages with unused space, which is a waste of memory. Another way to organize the virtual texture would be with a label occupying more than one page, and objects therefore needing more than one page to store their textual content. The solution adopted in the present work took another approach, creating only the necessary labels (those that will appear on the screen) at each frame and spending little memory to save them, as will be shown in the next section.



%==========================================
\section{Applying labels to objects}
%

This section explains the procedure for displaying labels on a large number of objects and the writing of words on geometric surfaces in real-time. To do this, a two-pass algorithm in the GPU was developed. For the implementation of this algorithm we used OpenGL 2.1~\cite{OpenGL:2.1}, OpenGL Shading Language 1.2~\cite{GLSL:1.2} and  a few extensions.

The first pass of the algorithm renders the scene to an off-screen color buffer and also creates a second buffer with texture coordinates per pixel and an identifier of the label which must be displayed on the geometry to which the pixel belongs. This information will be useful for the second pass when the pixels' final colors are calculated and labels are added to the scene.

To calculate the final pixels' colors, it is necessary to know whether they should show part of a label and which textual information that label contains. For this reason, before the rendering takes place, the ASCII codes of all labels must be stored and made available for the GPU. In this work we used a 2D texture for the label's ASCII codes that is referred to as a table, relating the label index with its text. 

The number of texels that a 2D texture can store is hardware dependent, but in general there is enough space for a large quantity of textual information (e.g., 256MB for a GeForce 9600GT and even more for modern graphic cards). Of course, considering that the models to be visualized are massive and their geometries can consume plenty of space in the video memory, it is not be desirable to spend that much with labels. However, if each label has 20 characters and 2,000,000 distinct labels are needed, the memory consumption will be 38MB, what isn't high considering the large amount of information stored.

Also, a texture atlas that contains all the required characters must be available in the GPU, which is treated as a two-dimensional array of characters. The atlas is an image with the graphical representation of the characters arranged in the same order of the ASCII encoding, so that it is possible to find a character's position by its row and column initials.

Using the atlas with all characters and the texture with ASCII codes created by the application, two rendering passes are performed to render the scene with labels applied to the geometries. We are going to explain them in detail in the sub sections below.



%------------------------------------------------------------------------- 
\subsection{First rendering pass}
%
Before the drawing commands of the objects are called, the CPU informs the GPU of the label identifier that must be displayed on each object (index in the texture of ASCII codes) and the number of characters of that label.

The first pass is necessary for the generation of texture coordinates for the objects. We generated the texture coordinates in the vertex shader, as will be explained in section IV. The fragment shader writes information into two off-screen buffers that are textures attached to a Frame Buffer Object (FBO). In the first buffer, the color data of the scene are written, and in the second buffer, texture coordinates interpolated per fragment, the label identifier, and the label's text size are written.

%------------------------------------------------------------------------- 
\subsection{Second rendering pass}
%
In order to obtain the data per fragment generated by the first pass, it was necessary to draw a screen-sized quad, whose texture coordinates range from 0 to 1 in both dimensions. This makes it possible to sample the color buffer and the buffer with texture information.

After setting new information of color and texture to a fragment of the quad, the fragment shader performs calculations to add labels to the scene. If the fragment has no label, it receives, in the first pass, a label identifier equal to zero and texture coordinates equal to zero, so that no calculations for labels are done in the second pass. The calculation for mapping labels on an object is done as follows for each fragment that has a label.

%------------------------------------------------------------------------- 
\subsubsection{Find character index }
%

The algorithm considers that the label will be written parallel to the $s$ axis of the object's texture space. This space can vary from 0 to 1, or to a value greater than 1, to repeat the label along $s$. For each interval of size 1 at the $s$ axis, one must consider that the interval will be divided in a total of columns equal to the number of characters in the label. The purpose of this step is to figure out in which column the current fragment is contained, which indicates the index of the character in the object's label.

\begin{figure}[ht]
\centering
\includegraphics[width=\columnwidth]{Fig1}
%\includegraphics[width=3.5in]{Fig1}
\caption{Fragment with character index = 2.}
\label{fig:1}
\end{figure}


%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

For example, in Fig. \ref{fig:1}, for a label with 4 characters ($n_{chars} = 4$), given a fragment with texture coordinate $s = 1.6$, the expected result is a character index $i_{char} = 2$. For that, we use equation (\ref{eq:1}), where $s_{frac}$ indicates the fractional part of texture coordinate $s$. This fractional part indicates the offset of the fragment within one instance of the label, and is important for dealing with label repetitions.

\begin{equation}
i_{char} = floor(s_{frac} * n_{chars})
\label{eq:1}
\end{equation}

%------------------------------------------------------------------------- 
\subsubsection{Find the ASCII code of the character }
%
As explained before, there is a texture that stores the ASCII codes of the characters of all labels in the scene. The goal of this step is, with the index of the character found in the previous step and the label identifier of the current fragment, to find, within this texture, the ASCII code of the character sought.

Fig. \ref{fig:2} shows an example of how the characters are stored in the texture with textual information that, in this case, uses two texels to store each label ($texelsPerLabel = 2$). Since a texel has four color components, in two texels it is possible to store up to eight characters. The values in green on Fig. \ref{fig:2} are the label identifiers and in red are the indices of each character within its labels (highlighted in the figure, the index found on the previous step $i_{char} = 2$). The values in blue show that the texture in the given example possesses four texels horizontally and four vertically and, at the same time, represent an index for each texel along the $s$ and $t$ axes. As each label in the example occupies 2 texels, it is possible to store 2 labels per row of the texture ($labelsPerRow = 2$).

\begin{figure}[ht]
\center{\includegraphics[width=\columnwidth]{Fig2.png}}
\caption{ASCII codes stored in a 2D texture.}
\label{fig:2}
\end{figure}

To obtain the character's ASCII code, we must find the texel containing the character. In the example of Fig. \ref{fig:2}, as highlighted, for a fragment in which label identifier ($id$) is 6 and $i_{char} = 2$, we will find the texel with horizontal index $i_s=2$ and vertical index $i_t=2$ (values in blue on the figure). These calculations are done according to equations (2-3):

\begin{equation}
\begin{split}
i_s = ((id-1) \text{ mod } labelsPerRow) * texelsPerLabel \\ + floor(i_{char}/4)
\label{eq:2}
\end{split}
\end{equation}

\begin{equation}
\begin{split}
i_t = floor(\frac{id-1}{labelsPerRow})
\label{eq:3}
\end{split}
\end{equation}


Using the indices above, the texture coordinates of the texel must be found so that the 2D texture can be sampled, according to equations (4-5), where w and h are, respectively, the width and height of the texture, in texels.

\begin{equation}
\begin{split}
s_{temp} = \frac{i_s + 0.5}{w}
\label{eq:4}
\end{split}
\end{equation}


\begin{equation}
\begin{split}
t_{temp} = \frac{i_t + 0.5}{h}
\label{eq:5}
\end{split}
\end{equation}

The purpose of equations (4) and (5) is to find the texture coordinates whose values represent the texel's center, and with a nearest neighbor filter, the texel can be correctly retrieved from the texture. The obtained texel contains the correct character in one of its RGBA components. To finally find the ASCII code in the correct component, the calculation shown in equation (6) is done, with $i_{char}$ mod $4$ an index that goes from 0 to 3 due to the RGBA components, and $char$, the ASCII code we are looking for:

\begin{equation}
\begin{split}
char = texel[i_{char} \text{ mod } 4]
\label{eq:6}
\end{split}
\end{equation}

In the example shown in  Fig. \ref{fig:2}, the expected result will be the code of the `X' character.

%------------------------------------------------------------------------- 
\subsubsection{Sample the character atlas}
%
Knowing the character's code, it is then necessary to find its graphical representation in the texture atlas containing all characters. More specifically, the correct texel within the bounds of a character's image in the atlas must be found. For that, the offset of the fragment in the geometry's texture space must be calculated and related to an offset in the atlas, as shown in Fig. \ref{fig:3}.

\begin{figure}[ht]
\center{\includegraphics[width=\columnwidth]{Fig3.png}}
\caption{On top, a fragment and its offsets from the beginning of the character on the object. Below, the related offsets in the atlas.}
\label{fig:3}
\end{figure}

To calculate the offset along the $s$ axis in the geometry texture space ($sOffset_{geom}$), at first, one must calculate the width of the character in a 0 to 1 range. This value ($charWidth_{geom}$) is found simply by dividing 1 by the number of characters in the label. The offset is calculated with equation (7), using once again, the fractional part of the $s$ coordinate of the fragment ($s_{frac}$) and the character index obtained previously ($i_{char}$).


\begin{equation}
\begin{split}
sOffset_{geom} =s_{frac} - (i_{char} * charWidth_{geom})
\label{eq:7}
\end{split}
\end{equation}

The calculation of the offset along the $t$ axis ($tOffset_{geom}$) is simpler, since the height of the character ($charHeight_{geom}$) is always 1, even considering the vertical repetition of text. This way, $tOffset_{geom}$ is simply the fractional part of the $t$ coordinate of the fragment.

To find the related offsets in the atlas's texture space, it is necessary only to multiply the offsets found in the geometry's texture space by the ratio of the character's size in the geometry's texture space to the size of the same in the atlas's texture space, a value known since the creation of the atlas. This way:

\begin{equation}
\begin{split}
sOffset_{atlas} =sOffset_{geom} * \frac{charWidth_{atlas}}{charWidth_{geom}}
\label{eq:8}
\end{split}
\end{equation}

\begin{equation}
\begin{split}
tOffset_{atlas} =sOffset_{geom} * charHeight_{atlas}
\label{eq:9}
\end{split}
\end{equation}

In equation (9), the denominator of the fraction doesn't appear because, as we mentioned earlier, $charHeight_{geom}$ is always 1. The offsets calculated with equations (8-9) must be added to the character's initial position in the atlas, to find the texture coordinate and then to sample the atlas in the correct position to obtain a color for the current fragment. 

With the color obtained from the atlas and the color of the object (which is stored in the color buffer created in the first pass) it is possible to calculate the fragment's final color treating the label as a sticker.

With the presented technique, it is noticeable that, independently of the number of objects loaded by the application, label calculation is needed only for the pixels of the screen, which justifies the use of the technique for massive models. In the second pass, a few texture accesses are needed and the algorithm benefits from hardware resources for texturing, since the fragments next to each other, that are processed in parallel, in most cases, need to access near parts of the textures. The technique for displaying labels did not present any significant performance impact with massive models, as will be shown in Section \ref{sec:results}. The next section discusses the way to position labels in objects of CAD models.


%==========================================
\section{Label Positioning}
%
In this section we explain the procedure to position labels on some surfaces of CAD models, with the goal of providing to the user a good way to visualize text, independently of the angle of vision. With the correct definition of texture coordinates, the algorithm for displaying labels works for objects of different shapes and sizes. %The proposed algorithm considers that the texture coordinates of the geometries must be defined during the first pass. Those coordinates can vary from 0 to 1, or from 0 to any value greater than 1 to repeat text along the geometry.

For all presented primitives, texture coordinates are generated in the vertex shader of the first pass. This can be done because the developed graphics engine uses a primitive instantiation technique, which shapes the different geometries in the vertex program from a grid of vertices built in the CPU. For that, the vertex program must know the dimension, scale, position and orientation of the object and those data need to be informed by the CPU before the drawing of each object. The scale and dimension data are essential to automatic generation of texture coordinates for the geometries with different shapes and sizes, and for having labels with a varying character quantity.

Firstly, the technique was tested in simple geometries, such as quads. Texture coordinates can be defined in several ways, but we concluded that it would be better to centralize the labels vertically on the objects so that the visualization of the 3D models wouldn't be polluted. Horizontally, it would be better to repeat the text as many times as necessary, so that the user can visualize the text or easily knows how to find it from any position.

To centralize the text vertically, only a determined area of the object should have coordinates varying from 0 to 1. Thus, the fragments whose texture coordinates are outside that interval are identified in the fragment shader of the first pass and associated to a label identifier equal to zero --- which makes the second pass to calculate the final color of those fragments without the mapping of labels. The procedure to centralize the text calculates the ideal number of times that a label must be repeated along the surface (considering the object's size). Initially an ideal number of label repetitions must be defined based on a visual observation of a unit quad, and then, those parameters will provide a base for the automatic texture coordinate generation for quads of any size --- for instance, if it was noticed that vertically it was ideal to repeat the text 3 times so that the label wasn't stretched or squeezed, then in a quad of size 5 the text could be repeated 15 times. However, text should be displayed only at the center of the object; therefore, the texture coordinates should be shifted from 0 to 15 to -7 to 8, totaling 15 repetitions, in such a way that the area which goes from 0 to 1 stays exactly in the center of the object.

To repeat the text horizontally it is also necessary to identify how many characters fit in a unit quad to obtain a good visual effect. For instance, if it is identified that a unitary quad fits 6 characters, then a quad of size 5 fits 30 characters. If a label has the text ``Quad 0" of 6 characters, then it is possible to repeat the text 5 times along the s axis. Therefore, knowing a base for unit quads, it is possible to create simple equations for quads of any size.

One thing that has also to be considered for the calculation of the number of repetitions is a relation between the width and height of the objects. If the scale to be applied to the texture coordinates is calculated separately for each dimension, the bigger the geometry, the bigger is the disproportion between the object's size and the label's size. If a quad has dimensions 1 x 1 or 100 x 100 the screen area occupied by the label is the same, but it could be larger in the second case when an equal increase in both dimensions of the text's area is desirable, and no label repetition is needed for either dimension. Repetition of text is only needed when one dimension of the object is bigger than the other. Therefore, the ratio between the object's dimensions must be considered for a better label display. If the width is 100 times bigger than the height, the scale that should be applied to $s$ is around 100 times greater than the one that should be applied to $t$. By taking into consideration the ratio between the object's dimensions, there is no disproportion between the label and the object's size (Fig. \ref{fig:4}).

\begin{figure}[ht]
\center{\includegraphics[width=3.0in]{Fig4.png}}
\caption{Quads of different sizes and automatic positioning of labels.}
\label{fig:4}
\end{figure}

Other primitives that have their texture coordinates adjusted to display labels are boxes, cylinders, spheres and dishes. In the case of boxes, the calculations are about the same as the quads, however, different texture coordinates must be defined for each of the box's faces.

For cylinders, the texture coordinates of the vertices are set so that the s-axis of the texture space is parallel to the y-axis of the object space --- axis along the height of the cylinder --- and the t-axis is parallel to the x-axis. With this, the text is repeated several times along $s$ depending on the height of the object and, around the cylinder, it was agreed that the text should be repeated four times, so it could be easily visualized no matter which side of the cylinder the user is looking at. The calculation for finding scales, which must be applied to the texture coordinates, and depends on the cylinder's size and the number of characters of the labels, is all based on the calculations presented for quads.

In the case of spheres, text is displayed only once over $t$, on the object's center, and it can be repeated several times along $s$ depending on the sphere's diameter. The primitive called dish, as found in CAD models, has the shape of a half-ellipsoid and, with its information of radius and height, it is possible to parameterize its surface. Fig. \ref{fig:5} shows box, cylinder, sphere and dish with labels.

\begin{figure}[ht]
\center{\includegraphics[width=3.0in]{Fig5.png}}
\caption{CAD objects with labels.}
\label{fig:5}
\end{figure}

The positioning of labels on objects like cones and pyramids could be a bit more complex due to the different dimensions of the bases of those objects. With these, the texture coordinates must be calculated in a way to compensate that difference, so that the text won't be stretched proportionally to the size increase of one base in relation to the other. Despite that, the calculation has not been done until the present moment, and, with the technique explained in this work, the positioning of labels is possible with a couple more primitives than in the related works \cite{AVEVA:2010} --- which allow the labels to be displayed on cylinders and boxes only.

%==========================================
\section{Results}
\label{sec:results}
%

The results are going to be presented in two parts. Initially, we are going to show the result of the technique applied to CAD models. Then, we are going to present performance tests to show the effectiveness of the proposed technique.

%------------------------------------------------------------------------- 
\subsection{Labels in CAD Models}
%

For the rendering of CAD models we built an engine that uses a primitive instantiation technique, explained in the previous section. The engine renders all CAD model objects, placing labels on the previously mentioned objects: cylinders, boxes, spheres and dishes.

The models used are based in files containing information for each object to be drawn (position, orientation, scale and parameters specific to each primitive). Those object parameters are sent to the GPU as texture coordinates, since that was the fastest way found, considering the limitations of OpenGL 2.1 and GLSL 1.2. Besides that instantiation technique, the engine uses no other optimizations, but, with the built engine we can render a large number of objects at interactive rates, as will be shown in the next section.

Fig. \ref{fig:6} shows labels on objects of an oil refinery CAD model. It's possible to display labels on a large number of CAD model objects and, also, that most of the geometries that exist in that model are boxes or cylinders.

\begin{figure}[ht]
\center{\includegraphics[width=\columnwidth]{Fig6.png}}
\caption{CAD model of an oil refinery with labels.}
\label{fig:6}
\end{figure}

The character atlas can have several variations to facilitate the reading of labels. For instance, in Fig. \ref{fig:6}, white letters with black borders were used, which can be good to contrast with different background colors. %It is also possible to use an atlas with a black color for the characters, making it simple to modify that color within the fragment shader of the second rendering pass when the texture is sampled. 

%Fig. \ref{fig:7} shows colored labels on a CAD model, from an atlas with black characters with an alpha component, whose color was changed in the GPU.

%\begin{figure}[ht]
%\center{\includegraphics[width=\columnwidth]{Fig7.png}}
%\caption{CAD model with colored labels.}
%\label{fig:7}
%\end{figure}


%------------------------------------------------------------------------- 
\subsection{Performance Tests}
%
The technique presented in this work, for the display of labels on geometric surfaces, uses two rendering passes, and the first adds little complexity to the CAD graphics engine --- in the first pass, calculations are added only to generate the texture coordinates and for the fragment shader to write information on two buffers instead of one. In the second pass several per pixel operations are executed and also some accesses to different textures. Therefore, it's important to evaluate the performance of the proposed technique, especially when the application utilizes higher resolutions. For that, tests were done and are presented below.

For the first tests, a scene with quads with random dimensions and positions was created, so that labels occupy the entire area of the objects and, therefore, calculations related to labeling were done for all the quads' pixels. The object's labels had different characters and sizes. The same scene was used to compare the performance of the versions with and without labels, whereas in the first case the algorithm does just the first pass and doesn't perform any calculation related to labeling, not even the generation of texture coordinates for the geometries. 

%One of the created scenes, with 100,000 objects and resolution of 1920x1200 is shown in Fig. \ref{fig:8}. It is worth mentioning that labels have whitespace characters before and after the text, and that the entire surface of each quad has a label.

%\begin{figure}[ht]
%\center{\includegraphics[width=\columnwidth]{Fig8.png}}
%\caption{Test scene with 100,000 quads. Version with labels (1920x1200).}
%\label{fig:8}
%\end{figure}

For all tests we used a computer with the operational system Windows 7 64 bits, an Intel Core I7 870 processor with 2.93 GHz, 8GB of RAM and a GeForce GTX 580 graphics card.

Table~\ref{tab:1} presents the comparison of rates in frames per second (FPS) obtained for a fixed camera position, for scenes with different number of objects, at a resolution of 1920x1200. One can note that the difference of FPS is small in scenes with fewer objects and virtually nonexistent in scenes with more objects.

\begin{table}[htb]
\caption{Comparative performance tests for a fixed camera position without and with the use of labels (resolution: 1920X1200).}
\label{tab:1}
\centering
\begin{tabular}{| c | c | c |}
\hline
\cellcolor[gray]{0.9} {\bf Number of} &
\cellcolor[gray]{0.9} {\bf FPS} &
\cellcolor[gray]{0.9} {\bf FPS} \\ 
\cellcolor[gray]{0.9} {\bf Objects} &
\cellcolor[gray]{0.9} {\bf (without labels)} &
\cellcolor[gray]{0.9} {\bf (with labels)} \\ \hline  
 10,000 & 	457 	&  439\\
%50,000 & 	106	&  105\\
100,000 & 	54 	&  54\\
200,000 & 	27 	&  27\\
500,000 & 	11	&  11\\
1,000,000 & 	6 	&  6\\ \hline
\end{tabular}
\end{table}

\begin{figure*}[t]
\center{\includegraphics[width=\textwidth]{Fig9.png}}
\caption{Test scene with CAD model.}
\label{fig:9}
\end{figure*}

Table~\ref{tab:2} shows the result of another random scene of quads, but this time we measured the average frame rate in FPS obtained when navigating throughout the scene for 50 seconds. The exact same camera path was used for the scenes with and without labels. Tests were performed in two resolutions: 600x400 and 1920x1200 and it is once again shown that the performance difference tends to be null for a scene with a larger number of objects. In scenes with fewer objects, the difference reaches 5\% but the rates are still very high. There have been some cases with the 600x400 resolution in which the resultant average was slightly higher when using labels. Such a difference is insignificant and can be explained by the interference of events external to the program, like processes of the operating system.

\begin{table}[htb]
\caption{Comparative performance tests for camera trajectory without and with the use of labels.}
\label{tab:2}
\centering
\resizebox{\columnwidth}{!} {
\begin{tabular}{| c | c | c | c |}
\hline
\cellcolor[gray]{0.9} {\bf Number of} &
\cellcolor[gray]{0.9} {\bf Resolution} &
\cellcolor[gray]{0.9} {\bf FPS} &
\cellcolor[gray]{0.9} {\bf FPS} \\ 
\cellcolor[gray]{0.9} {\bf Objects} &
\cellcolor[gray]{0.9} {\bf } &
\cellcolor[gray]{0.9} {\bf (without labels)} &
\cellcolor[gray]{0.9} {\bf (with labels)} \\ \hline 
\multirow{2}{*}{10,000} & 600 x 400 & 511.6 & 485.3 \\
 & 1920 x 1200 & 488.1 & 470.1 \\ \hline 
%\multirow{2}{*}{50,000} & 600 x 400 & 106.7 & 107.9 \\
 %& 1920 x 1200 & 102.0 & 99.9 \\ \hline 
\multirow{2}{*}{500,000} & 600 x 400 & 10.6 & 10.6 \\
 & 1920 x 1200 & 10.6 & 10.5 \\ \hline 
\multirow{2}{*}{1,000,000} & 600 x 400 & 4.5 & 5.3 \\
 & 1920 x 1200 & 5.4 & 5.4 \\ \hline 
\multirow{2}{*}{1,200,000} & 600 x 400 & 4.6 & 4.5 \\
 & 1920 x 1200 & 4.5 & 4.5 \\ \hline 
\end{tabular}
}
\end{table}


The last tests were performed with a CAD model of a real oil refinery, rendering all the existing primitives in the model, except for triangle meshes. Cylinders, boxes, spheres and dishes exhibit labels and the total number of rendered objects was 300,000, mostly boxes and cylinders, as shown in Fig. \ref{fig:9}. The texture coordinates of the objects were defined as explained in section IV, being generated automatically depending on the size of the objects and the number of characters of the labels. For a fixed camera position we obtained 17 FPS for a scene with and without labels. The results of the tests when navigating the scene with the same camera path for a scene with and without labels can be found in Table~\ref{tab:3} , which shows that the performance loss was little or none with the use of labels.



%\begin{figure}[ht]
%\center{\includegraphics[width=\columnwidth]{Fig10.png}}
%\caption{Test scene with CAD model - fixed camera position used.}
%\label{fig:10}
%\end{figure}


\begin{table}[ht]
\caption{Comparative performance tests for camera trajectory without and with the use of labels in a CAD model.}
\label{tab:3}
\centering
\resizebox{\columnwidth}{!} {
\begin{tabular}{| c | c | c | c |}
\hline
\cellcolor[gray]{0.9} {\bf Number of} &
\cellcolor[gray]{0.9} {\bf Resolution} &
\cellcolor[gray]{0.9} {\bf FPS} &
\cellcolor[gray]{0.9} {\bf FPS} \\ 
\cellcolor[gray]{0.9} {\bf Objects} &
\cellcolor[gray]{0.9} {\bf } &
\cellcolor[gray]{0.9} {\bf (without labels)} &
\cellcolor[gray]{0.9} {\bf (with labels)} \\ \hline 
\multirow{2}{*}{300,000} & 600 x 400 & 15.8 & 15.5 \\
 & 1920 x 1200 & 16.1 & 16.1 \\ \hline 
\end{tabular}
}
\end{table}





%==========================================
\section{Conclusion}
%
In this paper we developed an algorithm entirely in the GPU to display, in real time, labels on the surfaces of geometric primitives of massive models, and found that it presents good performance and visual results. One of the challenges identified was that, when dealing with massive models, each of its objects could have a different textual content needing distinct labels. Therefore, if we used a different texture for each label, multiple texture context switches would be needed by frame, which would compromise the performance of the application. Likewise, the use of one texture per object would imply a high memory cost and the development of strategies to maintain, in video memory, a limited number of textures per frame.

With the developed algorithm, only the labels that need to be shown on screen are built per frame, in the GPU, and the label mapping is done for each fragment by sampling an atlas with the graphical representation of the characters and a buffer with the ASCII codes that contain textual information of the labels. Therefore, we don't need to deal with problems related to texture context switches and also the problem of building and storing textures with the images of each label in video memory. We need only to store the atlas and the buffer with ASCII codes. The storage of ASCII codes uses much less memory than storing the images of labels.

The problem of positioning labels on objects of CAD models with different sizes and shapes was solved for cylinders, boxes, dishes and spheres. As a future work we want to add labels to other kinds of objects from CAD models, such as cones and pyramids, and also to improve the visual quality of labels with the use of anti-aliasing techniques. We intend to study the use of dynamic labeling, to display operational data such as temperature and pressure directly on the objects' surfaces. We also want to explore the use of labels in domains other than CAD, once the technique presented here for the generation of virtual labels is not restricted to the CAD domain.



% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.




% use section* for acknowledgement
\section*{Acknowledgment}


Tecgraf is a laboratory mainly supported by Petrobras. Alberto Raposo thanks also CNPq for the support granted to this research (470009/2011-0).


% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\bibliography{Renato}

%\begin{thebibliography}{1}



%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
 % 0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

%\end{thebibliography}




% that's all folks
\end{document}


