M Funk

M Rauterberg

PULP Scription: A DSL for Mobile HTML5 Game Applications

As applications and especially games are moving to the web and mobile environments, different tools are needed to design these applications and their behavior. HTML5 in combination with JavaScript is a promising basis for such applications on a wide range of platforms. Content producers and designers often lack the tools for such developments, or the expertise to operate existing, but too complex tools. This paper presents work in progress about a novel domain-specific language (DSL) PULP that aims at closing this gap. The language allows tying content such as images and media files together by modeling the dynamic behavior, movements, and control flow. The DSL helps abstracting from asynchronous JavaScript, state machines, and access to cross-platform media playback, which is generated in a final model-to-text transformation. The DSL and tooling were created and evaluated in close cooperation with content authors.

Introduction

The application domain targeted in this paper is simple educational games for children from 3-7 years. These games aim for instance at improving foreign language skills in a playful way. The games support simple touch gestures and allow for guiding the players with sounds and videos.

Producers of interactive content and applications for mobile devices face a huge diversity of platforms to develop for: from Apple's iOS or Google's Android platforms to Windows Mobile, Symbian, WebOS, Blackberry, and others there is a variety of systems available. This often involves major additions and changes to the user interface and thus leads to huge efforts spent on device specific code and testing. Apart from simply selecting a subset of platforms to target, a recent trend is to target the devices' browsers with HTML5, which is commonly supported on most platforms. HTML5 in connection with CSS3 not only supports transitions, animations, often hardware-accelerated, but also allows for native media playback and local storage of application data. The browser as a platform also requires programming in addition to the content authoring, and although the programming model is relatively light-weight (consisting of HTML5 markup, styling and JavaScript programming), this expertise is often beyond the abilities of content producers.

The central problem statement can be formulated as: how can the authoring of interactive content on the web for next generation platforms and novel input methods be supported by modeling in the form of domain-specific languages as means to enable end-user programming with rapid iterations? Tackling this problem by designing a language should mainly involve the content author and her expertise as a domain expert. What is behind this problem is the assumption that content authors and designers can benefit from domain-specific languages which represent a formal description of the final product, but allow to specify in a way that resonates well with the working habits and prior expertise of the domain experts.

The paper introduces the domain-specific language PULP that allows for scripting all structural and behavioral aspects of an interaction HTML5 application. While images and media files represent the content basis of the application, PULP provides a structural skeleton which is enriched with behavior and styling. In the end, a fully working interactive application is generated.

Related work

Different techniques exist to author dynamic HTML5 content: on the one hand programming techniques based on either front-end scripting or domain-specific languages with code generation, and on the other hand there are light-weight prototyping techniques based on image slices that are annotated with links to support page transitions. Examples for the first techniques which involve modeling are the WebDSL and Mobl languages [START_REF] Groenewegen | Webdsl: a domain-specific language for dynamic web applications[END_REF][START_REF] Hemel | Declaratively programming the mobile web with mobl[END_REF].

While WebDSL enables the development of generic web applications with a DSL, the Mobl language focuses on mobile application development. Both DSLs are supported by generators that ease quick iterations by generating respective HTML and JavaScript artifacts on-the-fly. The generated artifacts assemble UI elements and add interaction possibilities. The second technique of visual rapid prototyping is based on image slices that are assembled to form the screens of the application, and their annotation to allow for limited interaction support [START_REF] Jørgensen | Prototyping iphone apps: realistic experiences on the device[END_REF][START_REF] Hosseini-Khayat | Low-fidelity prototyping of gesture-based applications[END_REF]. PULP's usage domain, however, is situated in-between: the focus is on applications without predefined interface elements but with image objects that serve as actors which can be manipulated and which structure the user experience. PULP aims at designing for (novel) interfaces with touch and gesture support, as well as native sound and video output. At the same time, PULP is a textual DSL and allows for more control over the application structure, collaborative working and version control.

The DSL

The design of an appropriate domain-specific language PULP for the purpose of rapid prototyping of interactive (touch-based) applications needs to involve concepts of the domain as first-class citizens, but also the user of such a language having a distinct set of skills. The language concepts are explained in the following, before turning towards the necessary skills to master the language.

Language concepts

As mentioned before, the users of the PULP language are designers and content creators for different interactive media. They are trained, sometimes even formally, to think in terms of canvases and objects within. Behind this is the notion of coordinate systems and pixels as the basic measure of distance within such systems. Often, these users have good understanding of the size of screen objects and can reliably estimate the pixel size of objects or distances. The PULP DSL draws on these skills as all screen objects and the screens are measured and positioned according to pixel counts. For the sake of simplicity, only absolute positioning is used as relative positioning of elements could potentially lead to obscure dependencies between screen objects. The second important skill of language users is the ability to not only position elements in 2D space, but also according to a z-index, i.e. the notion of screen layers. The language supports this by first the straightforward convention to place objects in order of appearance, and second by layers which may group objects on the same (layer) z-index.

A PULP script contains essentially a number of screens, therein, screen objects, and definitions of interactions upon these screen objects. These interactions are expressed as action chains. The language was designed such that the number of structural tokens such as "=>" or "{" and "}" is kept to a minimum, whereas operative (or more verbal) keywords have a direct counter part in observable functionality like "show", "hide", "move", and "play". The general terminology originally aligned with the analogy of a theater stage with background, foreground, actors and requisites. It later evolved to a more open theme of screens, screen objects, and interactions.

Screen primitives

An application in PULP is first defined with a few global constants such as "title", "width", "height" and background color. Furthermore it is structured into different screens which can contain screen objects and associated interactions. Screen objects are divided into layers, images, and text. Layers enable grouping other screen objects and expressing a z-order on the screen. Images and text are defined with coordinates and size parameters, as well as optional styling (according to CSS3). In addition to screens, different media objects can be defined in a PULP application: videos, sounds, and voices. The difference between sounds and voices is the convention that sounds can be played in parallel, whereas voices are played exclusively to ensure understandability. Finally, a start screen is given for starting up the application.

Action chains

An action chain consists of at least one action trigger and one action result. More than one action trigger define either an ordered sequence of actions that have to be performed by the user to reach an action result, or an arbitrary sequence of actions that are needed to trigger the action result. In general, sets of combined action triggers are useful for setting with scripted behavior that is expected from the user, such as learning environments, whereas single actions triggers are incorporated most for user interface prototypes that strive for simplicity and good usability.

An action chain is defined as:

Trigger (=> Trigger)* => Result (=> Result)*
An example is a click action on a predefined image that triggers sound playback followed by a screen change. Note that the image defines "click" as a possible action:

Multiple triggers within an action denote a simple form of a state machine: the results are only triggered in case all specified triggers are performed in the right order by the user. An example is entering a code ("4321") on a graphical numeric pad to gain access to the result screen:

This last aspect of action chains enables to quickly prototype interactive applications with complex interaction patterns that would require larger efforts to achieve with manual JavaScript programming. PULP hides this complexity, and instead presents a designer-friendly, more application focused view on HTML5 scripting.

Tool implementation and the HTML5 generator

The PULP editor tool (cf. Fig. 1) is based on the Eclipse platform1 , and makes use of the Xtext domain-specific language toolkit2 to provide a textual editor with syntax coloring, auto-completion, and validation. The generation step is a model-to-text generation of HTML and JavaScript code and it is enabled by the Xtend23 tools. The editor allows browsing image and media files while creating PULP language elements. When a PULP file is saved in the editor, the PULP generator (for HTML5) runs automatically and creates a hierarchy of files in an /html/ subfolder where also the images and media files reside. The generator creates a single HTML file which first contains the declaration of all screens and screens object as HTML <div>s and images, then the associated media files as HTML5 <audio> and <video> objects. Finally, JavaScript is generated according to the given interaction capabilities and defined interaction of screen objects. The generated JavaScript makes use of jQuery 4 and a few custom library functions.

Evaluation

A short informal evaluation of the tool has been carried out. In general, the possibility to achieve small games with comparatively rich interaction and touch gestures was received positively. During the evaluation, the participants were presented first with an exemplary PULP script that demonstrates most of the functionality and uses few pictures and media files to script an application. Different items of the PULP script were explained and participants could ask questions if necessary. This step took at most 15 minutes. In the next evaluation phase the participants were asked to change minor parts of the PULP script, such as positioning of images, and styling of text. Subsequently, the focus shifted to modifying the interactions that were attached to the screen objects, e.g. changing the click action on an image to a mouse-over action and triggering different sounds after a drag and drop action. This second phase took at most 20 minutes. In the third and last phase, participants were asked to be creative with their own material that they brought to the evaluation. This last phase did not involve extensive coaching anymore, and took about 25 minutes.

A more formal follow-up study is planned and will be carried out with a later version of the tool. Interesting aspects of this evaluation will concern the creation of more complex control flows, visual positioning of elements, and embedding videos. Furthermore, tool iterations based on user feedback are expected to motivate not only functional improvements, but also improvements of language syntax and semantics. This paper introduces a novel domain-specific language (DSL) for design and content authoring stakeholders in the domain of mobile games and other interactive applications. The potential range of applications is larger than shown in this paper, however, the gaming domain was chosen due to its focus and availability of professional users and testers. The emphasis is on enabling to script interaction flows, gestures and behavior in general. Combined with appealing visuals and supportive media such as object sounds and ambient atmospheres (potentially also video), applications created with PULP can convey a user experience that adequately matches the final product in its main lines. This rapid prototyped experience is important for showing the product vision as a clear goal during development, but also for demo purposes and early user feedback.

The presented DSL aims at simplifying programming tasks that would normally involve parallel and event-based programming paradigms, gesture handling, and handling of browser compatibility issues. The associated generator component takes a PULP file and linked media files as input and generates an entire HTML5 web application, which can be directly tested with a web browser.

Behind the PULP language and tools is the question whether DSLs can be applied successfully in the domain of design where the use of textual tools is not as common. DSLs naturally relate to modeling and formalization -therefore the question is extended to the applicability of (more or less formal) modeling in the design domain. The research on the PULP language aims at investigating this problem domain in the future. Further future work can be also derived from the evaluation, namely to ease the positioning of screen objects and to allow for prototyping other, more elaborate user interfaces that make use of gestures. Finally, prototyping efforts should be aligned with means to observe use flows [START_REF] Funk | Analytics for the internet of things[END_REF] for the collection of user feedback during early stages of development.

Fig. 1 :

 1 Fig. 1: Architecture of PULP tool chain with media and script artifacts

Eclipse: http://eclipse.org

Xtext: http://eclipse.org/Xtext

a part of Eclipse Xtext

jQuery: http://jquery.org


John M Blythe
email: john.m.blythe@northumbria.ac.uk

Lynne Coventry
email: lynne.coventry@northumbria.ac.uk

Cyber Security Games: A New Line of Risk

Keywords: Information security, Behaviour change, Security games 1

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Organisations and individuals are becoming increasingly reliant on technology and the internet for the storage and processing of their information. Statistics reported by the Internet World Stats [START_REF]Internet usage statistics: the internet big picture[END_REF] indicate that the number of internet users worldwide has increased by 528.1% since 2000, and now represents 32.7% of the worldwide population. Whilst the globalisation of the internet and technology has brought many benefits for businesses and users, the increased dependency on cyberspace also creates vulnerability to security threats: for example, viruses, hacking attempts and malware. These threats present a major risk and so it is important that businesses and individuals protect themselves from the growing threats in cyberspace.

Attention has therefore been devoted to improving the security behaviour of endusers. In organisations, previous approaches have been adopted such as training, education and awareness campaigns. These approaches can take a number of different forms including presentations, newsletters, video games, and posters. A review of the existing literature on security interventions suggests that current approaches lack empirical evidence and a theoretical grounding with the majority of approaches being based upon practical experience [START_REF] Puhakainen | Improving Employees' Compliance Through Information Systems Security Training: An Action Research Study[END_REF]. To date, the use of serious games to improve security behaviour and awareness has received little attention, though the use of games for information security awareness has been proposed by researchers. However, in domains other than security, research into the use of serious games for behaviour change and knowledge impact has produced mixed results in research [START_REF] Connolly | A systematic literature review of empirical evidence on computer games and serious games[END_REF].

Serious games intending to change the behaviour of end-users need to incorporate models of behaviour change. Whilst there is relatively little research regarding behaviour change in security settings, there are a few examples. The research that exists has used behaviour models from health psychology literature. For example, one study used the Health Belief Model (HBM) to improve anti-phishing behaviour with the game 'Anti-Phishing Phil' teaching users to avoid phishing attacks. Using the HBM, this study manipulated participant's perceived susceptibility and found that tailored risk messages increased intentions to behave securely online regardless of whether participants were presented with at low risk or high risk message of being a potential victim of fraud. However, overall, the study found that the use of the game as a training program had no effect on actual secure behaviour [START_REF] Davinson | It won't happen to me: Promoting secure behaviour among internet users[END_REF]. Thus suggesting that intention to change did not lead to actual change. This study only manipulated one aspect of the HBM, perceived susceptibility, and generally more than one factor should be addressed simultaneously. Research from health has discussed the manipulation of behavioral determinants of models in great depth and meta-analyses have found behaviour change interventions for health behaviour to be efficacious [START_REF] Johnson | Meta-Synthesis of Health Behavior Change Meta-Analyses[END_REF].

We propose a framework based upon our current work investigating factors influencing security behaviour (see table 1). The framework is based upon two well-established theories of behaviour change; the protection motivation theory [START_REF] Maddux | Protection motivation theory and self-efficacy: A revised theory of fear appeals and attitude change[END_REF] and the theory of planned behaviour [START_REF] Ajzen | The theory of planned behavior[END_REF] with additional factors of locus of control and psychological ownership. We seek to address the practical efficiency of the framework in game design and argue that future serious game design should target the behavioural determinants (table 1) to increase the efficacy of behaviour change games. Games adopting this framework need concrete examples of how they are targeting each factor in the framework and how each determinant is manipulated in the game design. This will enhance the behaviour change effectiveness and further aid in the understanding of the use of serious games for behaviour change.

Security Games: A Double-Edge Sword?

Games designed to improve security behaviour have inherent trust and privacy issues. These games are designed with the intent to improve behaviour, yet they have the potential for people to expose their real life security behavior, its weaknesses and actual security data such as passwords. Firstly, users are pushed to a particular behaviour i.e. what the designers of the games target for a particular security issue. In the case of 'Anti-Phishing Phil', the game focuses on one generalized measure of behaviour which is the detection of fake URLs in phishing scams. In reality, users are more likely to face a range of phishing attacks so are required to use a number of heuristics to detect these attacks. Future security game design should ensure complete coverage of phishing attacks/security issues and required behaviour to ensure that a user is not left vulnerable.

A further issue surrounding the use of security games is that they can maintain logs of user behaviour, for example, the security resource management game cyber-CIEGE [START_REF] Thompson | Active Learning with the CyberCIEGE Video Game. 4th CSET workshop[END_REF]. The game requires the user to take the role of a decision maker for a fictional IT-dependent organisation and they must make choices regarding technical, procedural and physical security. Their role is to ensure that the organisation's employees are happy and productive whilst ensuring that security measures protect information. The game creates a log of the choices made by the user which can be viewed to provide summaries of progress and details of individual gameplay.

The content of these logs could potentially be very sensitive as they could provide information about the security behaviour of the individuals. For example, if a security game requires the development of more effective passwords, studies have shown that users manage around 8 passwords [START_REF] Grawemeyer | Using and managing multiple passwords: A week to a view[END_REF] and have on average 25 accounts protected [START_REF] Florencio | A large-scale study of web password habits[END_REF]. When combined they have on average 25 accounts that require a password but only have 8, therefore they are more likely to re-use current passwords. In games, users are also likely to re-use and disclose their real world passwords in a scenario that requires them to develop more secure ones. Those who have access to these logs could therefore use this information for malicious intentions.

It is important that the access to these logs is reflected in the policies of the games and acceptable usage by organisations using security games for improving awareness in employees. Wrongful access to logs of behaviour can give indication of weak aspects of users' security practice and what resources individuals may protect (in the case of a resource management game). This could potentially highlight weak areas in organisational infrastructures which could then be comprised by hackers. The acceptable use of security games should also be addressed as the competitive nature of some of these games may mean that organisations may wish to create a leaderboard in which employees may compete with each other to achieve higher scores. Such an approach may improve engagement and the potential effectiveness of the game. However, in the context of organisations, this may lead to many trust and privacy issues. For example, if an employee is particularly careless regarding their security then a leaderboard could present them a negative manner. An employee could perceive this as being procedurally unfair and this can have implications for their productivity and their psychological contract with their company. These issues are more concerning when games adopt a social media framework as they leave players vulnerable to social engineering attacks. For instance, researchers have designed a prototype security awareness game with a social media framework [START_REF] Labuschagne | Design of cyber security awareness game utilizing a social media framework[END_REF] that uses a leaderboard, so users have the ability to view their friend's scores and thus their friend's progression. They can share badges and achievements on their profile which can be viewed by friends. Users can select topics such as password security and social media security. A major issue with this sort of framework is that it leaves individuals open to a social engineering attack. By displaying an individual's security behaviour on their social network, it has the potential to highlight weak aspects of their security and those who score low could be the target of an attacker who could identify where to exploit based upon their score. Social engineers are known to use social media to gain information about users which they can then use to exploit them.

Phishing could also be potentially developed for security games, in which the user is tricked into thinking they are learning how to improve their security behaviour when the game is actually used to gather information regarding their security practice. It is therefore important that this sort of issue is addressed in future practice.

In conclusion this paper has presented a new framework for designing future games for security behaviour change based upon previous research findings. The paper has also identified potential trust and privacy issues with serious security games. In future work the framework presented will be validated and developed.

Table 1 .

 1 The behavioural determinants to be targeted in game design for behaviour change

	Behavioural Determinants	Security context for the game player
	Perceived vulnerability	Assessment of the probability of an event occurring as the result
		of a breach
	Perceived severity	The severity of the consequences of a security breach
	Response efficacy	Belief as to whether the recommended action will actually avoid
		the threat
	Response cost	Perceived costs of performing the security behaviour
	Self-efficacy	Belief they have the knowledge and skills to perform the securi-
		ty behaviour
	Attitude	Their positive or negative feelings toward security behaviour
	Subjective norms	Relevant others to the user are performing the security behav-
		iour
	Locus of control	The extent to which they believe that they can control events
		that affect them
	Psychological ownership	Perception that they own what they are protecting by performing
		the behaviour


Aneta Takhtamysheva

Jan Smeddinck
email: smeddinck@tzi.de

Serious Questions in Playful Questionnaires

Keywords: Social networks, social gaming, social media, playful applications, opinion-mining, survey

Conducting surveys is a time consuming and often expensive process. One of the main hurdles is motivating people to participate. The project presented herein proposes a playful approach, distributed via social network environments, where participants are intrinsically motivated to participate. A first evaluation showed an increased incentive to recommend friends to participate in the survey, as well as a preference of the playful approach to conducting surveys in general.

Introduction

Collecting feedback and opinions through playful applications is an approach that remains largely unexplored [START_REF] Schmidt | Crowdsourcing for Human Subjects Research[END_REF]. We argue that playful questionnaires, which attract users/gamers mostly through their playful aspect rather than through requests for a favor, can aid in circumventing some of the common challenges of human subject research, such as low response rates and survey fatigue [START_REF]For some consumers, surveys breed feedback fatigue[END_REF]. In a wide range of research fields, opinion mining / surveys and quizzes [START_REF] Krause | Playful Surveys: Easing Challenges of Human Subject Research with Online Crowds Challenges of Human Subject Research[END_REF] [4] [START_REF] Weichselbraun | Using games with a purpose and bootstrapping to create domain-specific sentiment lexicons[END_REF] are tools are potential subjects to applying gamification for serious tasks which don't intend to bring any personal benefit to the users other than engaging experience. The finding that users play games not because they are useful, but mostly because they are fun [START_REF] Hsu | Why do people play on-line games? An extended TAM with social influences and flow experience[END_REF] has already been applied to the games with a purpose [START_REF] Von Ahn | Human computation[END_REF] [8] [9] [START_REF] Chrons | Digitalkoot: Making Old Archives Accessible Using Crowdsourcing[END_REF].

In order to evaluate the method of embedding serious questions in playful surveys and distributing them via social networks, we have created a sample playful application and conducted an explorative user experience study that involves having social network users interact with two versions of a survey: a playful one and a standard one.

Playful Questionnaire Design

The social network playful application called Bake Your Personality contains six serious questions about the video gaming preferences of the users. Following a pattern that has proven successful in the development of social networks applications, the playful questionnaire was developed relying on a universal theme that a wide audience can connect with [START_REF] Von Ahn | Human computation[END_REF]; in this case the process of cooking. Questions are asked using the metaphorical concept of a cooking process and of choosing ingredients for a final product (here: a cake). Figure 1 shows the quest to select 3 game genres that the player prefers to play most. Each question is presented as an action the player may perform; possible answers are represented by items that users interact with. At the end the "cake" is submitted for tasting, and user receives a playful personality report based on the "taste" of the cake. The players are motivated to be truthful with their answers in order to receive their correct personality report. In the background, the decisions made by users are recorded. The earnestness of the answers provided is checked by introducing a control question (a question that was asked before but appears again later on in a rephrased fashion).

In order to evaluate the validity and reception of the playful questionnaires approach presented herein, a questionnaire with a generic visual style and with an identical set of questions was developed. It contains single-and multiple-choice questions that correspond to the same questions and answers embedded in the playful application. After completing the standard questionnaire the users receive a playful personality report that contains the same text as in the playful version.

The major differences between these two questionnaires thus are in visual style, presence/absence of storytelling, and the amount of time necessary to complete the questionnaire. The playful application requires around 3 minutes on average, while the simple application takes less than 1 minute to finish.

Evaluation

The evaluation involved 20 students from 15 different study departments of the University of Bremen. The participant pool consisted of 10 males and 10 females, ranging in age from 20 to 35 years (M=25, SD=3.3 N=20). In order to counterbalance the order in which subjects participated in the conditions the sequence was randomly selected. Once participants completed both applications, they were asked to complete a feedback form, which covered the following issues: 1. Whether the playful elements of the playful questionnaire distracted users from their major task. 2. How users perceived each application: as a survey, serious personality report, playful personality report, or a game. 3. Whether users would recommend any of the two applications to friends on a social network (or verbally if they have no social network account). 4. Which one of the two versions the users would prefer to use in the future?

1.

The participants were asked whether the visual elements of the playful application notably distracted them from the major task of answering the "serious" questions. The results were compared to the responses given to the same question concerning the control application. A Wilcoxon Signed Rank test was applied to test the significance of the difference between the self-reported amount of influence of aesthetic and ludic elements on the answers provided by the users. It did not show any statistically significant differences between the degrees of "distraction" of these two applications: Z=1.26 (Mdn=4) p>.05 and showing a mild effect: r=.21.

2.

The analysis of the responses received regarding the question "How do you perceive the application?" -given the answer options: game, playful personality report, serious personality report, survey and undecided -revealed significant differences in how participants perceived both applications (Z=-3.88, p<.00). The majority of players perceived the playful questionnaire as a playful personality report, closely followed by game. The other version was perceived mostly as a survey.

3.

The question "Which of the applications would you recommend to a friend on a social network?" revealed significant differences in replies (Z=-2.67 p<.00), with the majority of participants being positive about the idea of spreading the playful questionnaire further to friends, while showing significantly less intention of doing so regarding the short questionnaire.

4.

Concerning the question "Which application would you prefer to deal with", most females expressed a preference of the playful questionnaire, while male players could be divided into two categories: those who would prefer the playful format and those who would distinctively prefer the short format. Finally, when asked to estimate the degree of earnestness that they displayed while interacting with each application, the majority of the users believed that they considered their answers more seriously when filling out the short survey, rather than when interacting with the playful questionnaire.

While self-reported accounts of earnestness are bound to be biased and the observed difference can likely be explained by the playful mood of the playful questionnaire that inevitably sets a more relaxed approach to answering questions, it is important to further investigate the data provided by quality control questions, once the survey is run on a social network.

The user experience evaluation of both applications suggests that the majority of the experiment participants prefer to deal with the longer playful applications rather than generic short surveys. The experiment participants showed distinctively more willingness to recommend the playful version to their friends. They also expressed the belief that the playful elements do not distract them from the main task of answering serious questions.

The approach of playful questionnaires offers intriguing benefits in terms of motivation, cost and demographic control. Yet, for the time being, further studies need to be executed in order to investigate the potential biases, to improve filtering techniques and, in the long run, to determine whether the approach can be generalized to the point where businesses and research institutes can target certain demographics by design, while the extend of bias can be quantified. At the same time, a playful and fun experience must be offered to potential users, customers and players if they are to be confronted with playful surveys more frequently.

Figure 1 .

 1 Figure 1. Snapshot of the Bake your Personality application.


Thales Sabino
email: tsabino@ic.uff.br

Paulo Andrade
email: pandrade@ic.uff.br

Esteban Clua
email: esteban@ic.uff.br

Anselmo Montenegro
email: anselmo@ic.uff.br

Paulo Pagliosa
email: pagliosa@facom.ufmt.br

A Hybrid GPU Rasterized and Ray Traced Rendering Pipeline for Real Time Rendering of Per Pixel Effects

Keywords: ray tracing, rasterization, OptiX, CUDA, GPU, hybrid rendering, OpenGL, GLSL, real-time, global illumination effects, deferred shading

Rendering in 3D games typically uses rasterization approaches in order to guarantee interactive frame rates, since ray tracing, a superior method for rendering photorealistic images, has greater computational cost. With the advent of massively parallel processors in the form of GPUs, parallelized ray tracing have been investigated as an alternative to rasterization techniques. While many works present parallelization methods for the classical ray tracing algorithm, in order to achieve interactive, or even real time ray tracing rendering, we present a rasterized and ray traced hybrid technique, completely done in GPU. While a deferred render model determines the colors of primary rays, a ray tracing phase compute other effects such as specular reflection and transparency, in order to achieve effects that are not easily obtained with rasterization. We also present a heuristic approach that select a subset of relevant objects to be ray traced, avoiding traversing rays for objects that might not have a significant contribution to the real time experience. This selection is capable of maintaining the real time requirement of games, while offering superior visual effects.

Introduction

In the computer graphics field, it is a common belief that raster techniques are better suitable for real-time rendering while ray tracing is a superior technique to create photorealistic static images, due to the ray tracing processing cost. Recent Graphics Processing Units (GPUs) can also work as general-purpose massively parallel processors [START_REF] Kirk | Programming Massively Parallel Processors: A Handson Approach[END_REF], promoting the possibility of Real-Time Ray Tracing (RTRT) implementations using GPUs as an alternative to raster based approaches due to its parallel nature by its concept [START_REF] Bigler | Design for parallel interactive ray tracing systems[END_REF]. Many works explore the possibility to accelerate ray tracing in order to make it a real-time process with GPU only or hybrid CPU and GPU approaches. However, results of different investigations indicate that RTRT remains a challenging computational task [START_REF] Aila | Understanding the efficiency of ray traversal on gpus[END_REF][START_REF] Lauterbach | Fast BVH Construction on GPUs[END_REF][START_REF] Hachisuka | Ray tracing on graphics hardware[END_REF][START_REF] Heirich | A competitive analysis of load balancing strategies for parallel ray tracing[END_REF], suitable only with specific conditions and constraints.

Offline renderers accurately simulate the way light interact with surfaces. Since the simulation of every beam of light in a 3D space is impractical, other approaches were developed to simulate the way light works. One of these approaches is the Backward Ray Tracing, where rays are launched from the camera position to different parts of the 3D space. Depending on the characteristics of the surfaces of the objects hit by the rays, secondary rays may be recursively generated. These secondary rays can be used to model many light effects such as soft shadows, mirror and diffuse reflection, depth of field, motion blur, refraction, transparency, among others.

RTRT is a hard computational task, not only because each pixel in the image must be calculated separately, but also because the final color of a single pixel can be affected by more than one recursive ray. Another consideration is that ray tracing algorithms waste from 75% to 95% of its execution time calculating intersection points between rays and objects [START_REF] Whitted | An improved illumination model for shaded display[END_REF].

In this paper, we describe an improvement of the graphics pipeline, by creating a hybrid ray trace and raster rendering process. In this method, the deferred rendering process is used to calculate the primary rays collision, while the secondary rays use a ray tracing approach to obtain shadow, reflection and refraction effects. This approach vastly improves ray tracing performance, not only because we avoid many unnecessary traditional ray tracing tasks, but also because we guarantee that a complete image will be available to show in a demanded time, even if there is not enough time to finish all the effects calculations. We also developed an efficient and customized data structure to manage part of the geometry inside the GPU memory and a heuristic approach that adequately chooses a subset of objects to generate visual effects using secondary rays.

This proposal differs from most related works, since the goal is not entirely replace the graphics pipeline by a ray tracing only approach. This work use GPU ray tracing only for a set of objects, seeking for those that will have more visual impact for each frame generated. The main focus is to render complex scenes in real-time using raster techniques and get the refined best visual look including algorithms that simulate global illumination effects. Since most global illumination effects are better simulated using ray tracing techniques, one approach proposes to combine these two techniques in the same rendering pipeline. This paper presents and discusses strategies applied to develop a real-time hybrid GPU-only ray tracer, that uses raster techniques to improve the performance of a ray tracer and a smart strategy for prioritizing regions and objects that will receive the ray tracing light effects.

This paper is organized as following: after a brief introduction we present different hybrid CPU and GPU raytracing approaches in Section 2, then we present a hybrid ray tracing model, detailing the composition methods in Section 3. Section 4 presents and discusses our heuristic approach for prioritizing regions and objects for the ray tracing phase. In Section 7 we present implementation details, followed by the results, comparisons and discussions, in session 8. Finally, we conclude the work and state future proposals in Section 9.

Related Work

The concept of a hybrid Real-Time Raster and Ray Tracer renderer is not new. Beck et al [START_REF] Beck | Cpu-gpu hybrid real time ray tracing framework[END_REF] proposes a CPU-GPU Real-Time Ray-Tracing Framework and Bikker [START_REF] Bikker | Real-time ray tracing through the eyes of a game developer[END_REF] developed a Real-Time Path Tracer called Brigade, which divides the rendering task seamlessly over both GPU and CPU available cores. Brigade aims the production of proof-of-concept games that use path tracing as the primary rendering algorithm.

Beck [START_REF] Beck | Cpu-gpu hybrid real time ray tracing framework[END_REF] proposal spread the traditional stages of ray tracing in independent tasks for the GPU and CPU. These render tasks can be summarized into three GPU render passes: a shadow map generation pass, a geometry identification pass and a blur pass. In the geometry identification pass, the triangle numbers are encoded as RGB colors in a framebuffer and the result of the shadow map pass is blurred inside the alpha channel, in the same framebuffer. The CPU receives the framebuffer for reflection and refraction generation pass using a ray tracing algorithm. Finally it is applied a phong shading pass that also merges the results of the other passes.

NVIDIA's OptiX [START_REF] Parker | Optix: A general purpose ray tracing engine[END_REF] is a general purpose ray tracing engine targeting both NVIDIA's GPUs and general-purpose hardware in the current version. OptiX architecture offers a low level ray tracing engine, a programmable ray tracing pipeline with a shader language based on CUDA C/C++, a domain-specific compiler and a scene-graph based representation. OptiX is a GPU only solution with remarkably good results for interactive ray tracing.

Pawel Bak [START_REF] Bak | Real time ray tracing[END_REF] implements a Real-Time Ray Tracer using DirectX 11 and HLSL. Similar to Beck's work [START_REF] Beck | Cpu-gpu hybrid real time ray tracing framework[END_REF], his approach also uses rasterization in order to achieve the best possible performance for primary hits but uses DirectX 11 and HLSL instead of OpenGL and GLSL.

Chen [START_REF] Chen | Use of hardware z-buffered rasterization to accelerate ray tracing[END_REF] presented a hybrid GPU/CPU ray tracer renderer, where a Zbuffered rasterization is performed to determine the visible triangles at the same time that primary rays intersections are determined. The CPU reads the data back in order to trace secondary rays.

Finally, Hachisuka [START_REF] Hachisuka | Ray tracing on graphics hardware[END_REF] surveyed several ray-tracing algorithms for graphics hardware. The author concludes that although the ray tracing method seems to be extremely well studied and their parallel nature can be understand easily, many issues need to be solved to implement it efficiently. Some of the issues were presented, such as data retention, the requirement of graphics hardware to perform the same computation over several pixels and their stack-based characteristic. His work classifies different approaches based on their features. Additionally, these algorithms are compared considering their bottlenecks and possible improvements are also discussed.

Most works about hybrid ray tracing techniques tries to balance the workload between GPU and CPU in order to achieve maximum performance of both parts. Using modern graphics hardware and APIs that allows efficient use of rendering techniques such as Multiple Render Targets (MRT) and Deferred Shading [START_REF] Deering | The triangle processor and normal vector shader: a vlsi system for high performance graphics[END_REF], it is possible to use the traditional raster pipeline as the first stage of a complete ray tracing pipeline: the generation and intersection of primary rays.

Primary Rays Generation and Intersection with Deferred Shading

Deering [START_REF] Deering | The triangle processor and normal vector shader: a vlsi system for high performance graphics[END_REF] introduced the idea of deferred shading. Although the article never uses the term "deferred", it introduces a key concept; each pixel is shaded only once after depth resolution. The term deferred shading was adopted later, and its usage in real-time rendering applications, mainly video-games, became mainstream since 2008.

The basic idea behind deferred shading is to perform all visibility tests before performing any lighting computations. In traditional GPU rendering, the Zbuffer normally shades as it goes. This process can be inefficient, as a single pixel often generates more than one fragment. A rough front-to-back sort of objects can help to avoid this problem, but deferred shading perfectly solves it, and also solves light/material combination issues [START_REF] Akenine-Möller | Real-Time Rendering 3rd Edition[END_REF].

Deferred Shading takes advantage of a structure called G-Buffer [START_REF] Saito | Comprehensible rendering of 3-d shapes[END_REF]. This structure is filled with geometric data, using the presented geometry pass. Values saved includes the z-depth, normal, texture coordinates and material parameters. These values are saved to Multiple Render Targets accessed by the pixel shader program.

The values stored into G-Buffers depend on the application. For this work, we store the following per-pixel values, one for each target: position, normal, zdepth, albedo color and specular color. These values are used later in the lighting stage of deferred shading (see Figure 1). For information about deferred shading implementation in this work, please refer to Section 7.

Although the information stored in the G-Buffer is enough to determine the origin and direction of shadow rays, it is not possible to establish the need for tracing reflection and refraction rays only with geometry data. The G-Buffer is extended with one more render target that stores optical properties of each pixel. Reflectivity, index of refraction, opacity and specular exponent are included in this target.

Deferred shading does have some drawbacks. The video memory requirements and fill rate costs for the G-Buffers are significant. One of the most significant technical limitations is in the process of antialiasing and transparency. Antialiasing is not performed and stored for rendered surfaces. To overcome this limitation, antialiasing image-based techniques such as Shishkovtosov edge-detection method [START_REF] Shishkovtov | Deffered shading in s.t.a.l[END_REF] and, more recently, Morphological Antialiasing [START_REF] Reshetov | Morphological antialiasing[END_REF] can be employed for better image quality.

Selective Global Illumination Effects

In ray tracing, secondary rays are used to produce global illumination effects. Once primary rays are handled, shadows rays need to be traced from the hit point through the scene in the direction of light sources. Shadow maps present some advantages over ray traced shadows, including avoiding the knowledge of the scene geometry and automatic adjustment over geometry changes on GPU. On the other hand it requires a large amount of memory in order to avoid aliasing, and the scene must be rendered once per light source. Precise shadows resulting from the shadow map technique require a large amount of memory in order to avoid aliasing [START_REF] Williams | Casting curved shadows on curved surfaces[END_REF].

The G-Buffer produced by the deferred rendering stage contains information about optical properties of the underlying material of each pixel. The render target represented by Figure 1(f) is used to determine the need for tracing reflection/refraction rays. It is composed by reflectivity, index of refraction, specular exponent and opacity, respectively. The Armadillo was highlighted meaning that rays only need to be traced from its surface through the scene. Since it is composed by a refractive material, we are able to avoid trace of unnecessary rays in places where the material is neither refractive nor reflective. At this point, the ray tracing algorithm can follow its own path. Any secondary ray generated will be traced against scene in order to produce other global illumination effects, such as reflections and refractions. The result of this stage can be understood as the generation of a ray trace effects layer. This effects layer will be blended to the image already generated, in order to improve its visual quality with global illumination effects.

Ray Tracing Heuristic For Real Time Rasterization Pipelines

In order to improve the performance of a hybrid ray tracer for real time applications, we propose a heuristic to dynamically select relevant objects to trace. The selected objects are ray traced for effects in a predefined and fixed time constraint. The heuristic is capable of selecting the most relevant objects in a scene and still maintain the expected frame rate. We define relevant objects as those that better contribute to the visual experience at a specific frame.

The idea of ray tracing a subset of objects and still have an improved experience in real time applications is based on the real world observation that when the perceived image constantly changes, as when we drive a car or walk, many elements are ignored by our conscious mind. This simple fact is the motivation of the development of warning signs, as the ones we see in highways to call our attention for relevant information. It is a fact that our attention is more focused in near objects, and objects directly in front of our field of view. Considering this observation, a simple heuristic would be to trace the objects near the observer, and in front of his/her field of view. Unfortunately, this simple heuristic is not capable of guaranteeing performance, also, not all objects improve in visual quality when using ray tracing instead of rasterization. The decision of what objects deserve to be ray traced is an environment designer decision since no technology can substitute the artist's eye. The heuristic tries to select the best candidates to ray trace, using some predefined information.

Pre-Production Phase

The first step happens during the scene design. This step is the selection of a group of objects that are candidates to ray trace for a given environment. For every object chosen, it is also necessary to define the kind of secondary rays that should be generated after the first hit (primary ray). In this work, we considered three different light effects to be ray traced if possible: reflection, refraction and shadows for high detailed objects.

The initial cost of the object is defined by its initial visibility (V ), and the estimated number of secondary rays needed to represent the object light effect (Q). Visibility is defined by Equation 1 and Object cost (C) is defined by Equation 2. Visibility is defined by the average area initially visible of the object (A) times the 2D projected distance of the object considering the center of the projection (P ) divided by the distance (D) of the object from the observer. The farthest the object, less visible it is, considering its area. Also, the farther the object is from the center of the 2D projection of the visible space, less relevant it is for the final image. P is a value in the range [0, 1], where one is the exact center of the scene, and 0 means the object is outside the field of view. Both equations are simplifications of the complete formulation.

V = A × P D (1)
C = V × Q (2)
Finally, every object has a relevance factor R defined by the fact that it was selected S before to be traced. We call as S a binary value of 0 (previously unselected) or 1 (previously selected), times a constant that represents the importance I of the render of previous rendered objects (defined by the application. Equation 3 represents relevance for our heuristic.

R = S × I + V (3)
All the tree equations are calculated for all the objects, frame by frame, in order to update the scene graph.

Selection Graph

When the GPU loads the information necessary to render the objects selected for ray tracing in its memory, a directed graph with information of the objects is built for the ray trace phase. Since the GPU is a massive parallel processor, the number of initial objects to be traced is proportional to the number of Stream Processors of the GPU architecture. The graph is a directed graph, where every node represents an object. A node points to another whose cost (C) is smaller than the actual node but equal or higher than the cost of all other nodes. Also, every node points to all N other nodes that are more relevant but not selected yet to be ray traced. The N pointers in every node are ordered considering their relevance. When an object finishes rendering, the graph is traversed in order to find the node whose rendering cost is less than the cost required to render it, considering the time still available for the ray tracing phase. If the node points to other node more relevant node, this one is selected to be ray traced, and the graph is updated. Figure 2 presents the graph structure. Red circles are the first nodes selected because of their relevance, and the gray circles are nodes that will still be selected. Black arrows represent the nodes order according to their cost (C) and the blue dashed arrows represent the N more relevant nodes (R) than the selected node, and with less cost.

Object Selection and Graph Rebuild

When the render of the first object is finished, the next one must be selected according to the time left to render. The selection graph is traveled until a node with an estimated cost less than the cost left to render is achieved. In this node, it is verified if it points to another node less relevant. If so, this node is also verified for relevance, until the most relevant node is found. When the node is selected to render, it is also moved to another graph, under construction for the next frame. Using the information provided by render engine, this node and all the nodes with cost higher than the cost used to find the first node are inserted into the new graph and the graph is properly updated. The current graph is also updated if the selected node is not at the node that was selected only according to its cost. If no time is left to render any object, this time is used to move all the nodes not selected to the new graph. Figure 3 represent the selection of a new node to render and the new future selection graph. Considering that the time left to render allows just a node with cost 18 or less to be selected, nodes 9 and 10 are removed from the selection graph and will be moved to the new graph, in construction. Since node 11 has cost 18 but is not the most relevant, node 14 is selected and the corresponding object is ray traced.

Final Scene Composition

This step consists in assembling the final image that will be displayed. This process is done by a blend operation between the rasterized image and the ray traced image. The weights for this blend are relative to the desired amount of ray tracing effects desired for the final image. At this point, the frame buffer contains two color attachments, the first one generated by the raster stage and the second one filled by the ray tracer stage.

The simplest approach to generate the final image, given a filled framebuffer, is to superimpose the ray traced image with the rasterized image. This can be easily accomplished with a shader program adding another light-weight render pass to the process, since we only need to render a screen-size quadrilateral primitive. Note that a simple superimposing of the ray traced image with the rasterized one will not present additional problems since only pixels that were shaded using the ray-tracing engine are visible.

Hybrid Pipeline Overview

In previous sections we described the stages that compose our hybrid raster/ray tracer pipeline. In this Section, we present an overview of the complete pipeline.

In order to illustrate the process, we use a simple scene composed of three textured objects and one point light. This scene is composed by 4,746 vertices and 9,470 faces. Figure 4 shows the five stages of our proposed pipeline:

-Deferred rendering and primary Rays resolution: Stage 4(a) consists in rendering the scene using a deferred rendering technique resulting in a filled G-Buffer. The obtained G-Buffer contains information about visible fragments, and it can be seen as a primary ray resolution stage of a traditional ray tracer. The result image of this stage has the edge-detection antialiasing algorithm applied [START_REF] Shishkovtov | Deffered shading in s.t.a.l[END_REF]. -Shadows: With data extracted from the G-Buffer, shadow rays are generated for valid hit points. In Figure 4, invalid hit points are those that must be shaded using the sky color or environment map, being such pixels the blue ones of Figure 4(a). The shadow pass result is presented in Figure 4(b). -Reflections and refractions: Stage 4(c) follows the ray tracing algorithm in order to calculate reflection and refractions. For this example, we use reflections on the ground to illustrate an application of such effect. -Final Composing: The final composing stage 4(d) is responsible for blending images generated at stages 4(a) and 4(c). We compose this scene using a shader program to draw the ray tracing effects layer with an OpenGL blending operation. The amount of ray traced effects on the final image may also be configured.

Implementation Details

In this section, we give more details of our implementation concerning efficiency and robustness. This system was implemented using C++ as the main language. The Open Asset Import Library was used in order to read common scene file formats. The Free Image Project was used to read texture images. We use GLSL as the shading language on the primary rays resolution stage and for rendering purposes. The NVIDIA OptiX engine was adopted to trace and shade secondary rays, due to its practicability in terms of freedom on building the ray tracing pipeline and hiding GPU hardware details when writing ray tracing shaders.

Besides the advantages of being a generic ray tracer engine, its bond to OpenGL for reading and writing graphic resources is straightforward. The geometry stage of deferred shading implements a perspective projection camera, and it is responsible for feeding the G-Buffer with information to be used in the next stages. All subsequent stages operate in image-space and work with an orthographic projection camera using the screen resolution dimensions. The lighting stage receives as input the contents of the G-Buffer as well as light sources information and it accumulates lighting effects into a full resolution P-Buffer (pixel buffer). Table 2 shows the configuration adopted in the implementation of the deferred shading technique.

Results

In this section, we present the results in terms of performance comparing our hybrid approach with a pure GPU ray tracer as well as a comparisson with Brigade Real-Time Path Tracer. The difference between the pure GPU ray tracer implementation and our hybrid implementation is that, instead of using the G-Buffer information, primary rays are generated by the camera. In the pure GPU ray tracer implementation, OpenGL render is disabled. We conduct the tests in a desktop system equipped with an AMD Phenom II X4 965 3.4GHz, 16GB of RAM and a NVIDIA GeForce GTX570. As operating system, we use the 64bits version of Windows 7 Professional.

Table 3 summarizes the results in terms of performance with the measurements based on frames per second (FPS) for each scene. All scenes were rendered with resolution 1280x720 pixels. 3. Performance comparison between our hybrid render and a pure ray tracer implementation. The times are expressed in milliseconds.

As one can see in Table 3, our hybrid implementation was able to achieve a higher frame rate than a pure ray tracer implementation. It is easy to notice that both the Armadillo Scene and the Showcase Scene got a bigger difference than the Sponza Scene. This is because Armadillo and Showcase are open environments, which means that more rays are likely to escape avoiding extra computation. Since Sponza Scene is a closed scene, the method tends to spend more time when tracing both primary and secondary rays.

The comparison with Brigade was made with the Dining Room scene. It is available as a demo in Brigade Homepage [START_REF] Bikker | Brigade: Real-time path tracer[END_REF]. Table 4 shows the results.

We expect to reduce the time of our approach using OptiX support for mipmaps, since coalesced memory access in GPU is one of the keys to achieve real-time frame rates.

Conclusion

We have described a ray tracer approach with primary ray hits using traditional graphics pipeline, taking advantage of the depth-buffer algorithm implemented on hardware and the data stored in the G-Buffer generated with deferred shading strategy. It was presented a way to avoid merging the scene geometry into a single mesh. We also present the details regarding implementation on how to use the same geometry on OpenGL and OptiX contexts as well as the removal of the common bottleneck of data transfer between GPU and CPU. We present results in terms of performance for different scenes and show that our hybrid approach can accelerate ray tracing by turning the primary rays resolution stage into a render task. We highlight the fact that our system was built so that existing shaders are not modified taking advantage of the graphic effects created so far. The heuristic approach guarantees that we process the most important objects with ray tracing and guarantees that the real time constraint is being maintained, something that is fundamental for virtual reality applications.

As future works, we propose the development of new heuristics to find the best elements where to apply ray tracer effects. We also want to compare the use of shadow maps with ray traced shadows in terms of performance and visual quality within our hybrid pipeline. This may drastically reduce the number of rays that need to be traced. At the primary rays resolution stage, we propose a generation and compaction of a list of valid rays. Also, we want to incorporate animations in our implementations in order to evaluate the performance of rebuilding the acceleration data structures on the fly.

Considering the pre-production phase, where the objects are selected to be ray traced, one strategy not explored in our work is to have more than one model to represent the same object, using discreet level of detail approach. The artist could create, for example, tree objects, one highly detailed, one with medium detail and a simplest one. The level of detail does not need to be only in the geometry, but also in the effects characteristics. A translucent object, for instance, could have different diffuse characteristics, proportionately reducing the work necessary to ray trace.

One of the advantages of ray tracing over raster techniques is its natural way of using parametric surfaces. Implicit representation of surfaces requires only the storage of its associated parameters and ray intersection algorithms are faster when dealing with parametric equations. Also, due to the complexity of incorporation in raster systems, in future, we want to incorporate implicit surfaces in our hybrid approach. When computing the first hit stage, the object could be approximated with a low resolution polygonal mesh and then, the ray tracing stage will be responsible for global illumination effects applied on the accurate implicit representation.

As stated, ray tracing is a technique capable of high quality image synthesis. Across with the more efficient implementations, along with the advance of computational hardware, at future it will be possible to simulate effects only reliable in offline rendering. At the future, we may see global illumination effects applied in real-time at high frame rates inside game and visualization environments.

Fig. 1 .

 1 Fig. 1. The six textures generated by the geometry pass: (a) position, (b) normal, (c) zdepth, (d) diffuse or albedo color, (e) specular color and (f) encoded optical properties. (g) is the image produced after the lighting stage.

Table 1 . 2 Node 1

 121 Cost and Relevance for the Selection Graph represented in Figure

Fig. 2 .

 2 Fig. 2. Selection Graph.

Fig. 3 .

 3 Fig. 3. Current Selection Graph and the Future Selection Graph in Construction.

Fig. 4 .

 4 Fig. 4. Overview of our hybrid rendering raster/ray tracing pipeline. The first stage (a) consists in rendering the scene using a deferred rendering technique resulting in a filled G-Buffer and a basic rendered image. Stage (b) traces shadow rays. Stage (c) is responsible for tracing and shading secondary rays. In this example, the ground is made of a reflective material. Finally, stage (e) is responsible for blending images generated at stages (c) and (a).

  Performance comparison in milisseconds (ms) Scene Vertices Triangles DR 3 RT 4 Hybrid Gain Armadillo (Fig. 5(c)) 193737 380655 3,134 25,112 18,518 1,35 Sponza (Fig. 5(a)) 145173 262187 2,227 66,667 34,482 1

Fig. 5 .

 5 Fig. 5. Images rendered with our hybrid ray tracer implementation. (a) Sponza Atrium Scene. This scene highlights the real-time reflection and refractions effects. (b) Showcase Scene. In this scene we highlight the colored shadows of transparent objects. (c) Armadillo Scene. This is demonstration of a refractive material applied to a model. (d) Dining Room Scene. All images have a resolution of 1280x720 pixels.

Table 2 .

 2 Configuration properties of the G and P-Buffers.

	Storage Options for G-Buffer
	Target	Format	Type
	Position	GL RGBA32F 1	GL FLOAT
	Normal	GL RGBA8 GL UNSIGNED BYTE
	Depth	GL DC24 2	GL DC 2
	Albedo	GL RGBA8 GL UNSIGNED BYTE
	Specular	GL RGBA8 GL UNSIGNED BYTE
	Optical props GL RGBA32F 1	GL FLOAT
	Antialias	GL RGBA8 GL UNSIGNED BYTE
	Destination	GL RGBA8 GL UNSIGNED BYTE

GL RGBA32F was chosen because of the need to store the coordinates in viewspace in the position buffer and values that lies outside the rage [0, 1] for the Optical Properties buffer.

[START_REF] Bigler | Design for parallel interactive ray tracing systems[END_REF] GL DC is the abbreviation for GL DEPTH COMPONENT.

DT stands for Deferred Rendering Time. It is the time our implementation spends with the rasterization stage.

RT stands for Ray tracing Time. It represents the time necessary to render the scene with a ray tracing-only renderer.

Acknowledgment

The authors would like to thank Leandro Fernandes for his help with shader programs, NVIDIA and people that spent a little of time discussing OptiX and CUDA related subjects in the web forum and CNPq for the financial support of this work. We also thank Crytek for proving a renewed Sponza scene suitable for testing on modern graphics cards.