Walberla: Visualization of Fluid Simulation Data with POV-Ray

Total Page:16

File Type:pdf, Size:1020Kb

Walberla: Visualization of Fluid Simulation Data with POV-Ray FRIEDRICH-ALEXANDER-UNIVERSITAT¨ ERLANGEN-NURNBERG¨ INSTITUT FUR¨ INFORMATIK (MATHEMATISCHE MASCHINEN UND DATENVERARBEITUNG) Lehrstuhl f¨urInformatik 10 (Systemsimulation) waLBerla: Visualization of Fluid Simulation Data with POV-Ray Simon Bogner, Stefan Donath, Christian Feichtinger, Ulrich R¨ude Technical Report 09-13 waLBerla: Visualization of Fluid Simulation Data with POV-Ray Simon Bogner, Stefan Donath, Christian Feichtinger, Ulrich R¨ude Lehrstuhl f¨urSystemsimulation Friedrich-Alexander University of Erlangen-Nuremberg 91058 Erlangen, Germany [email protected] December 14, 2009 Contents 1 Introduction 3 2 Feature Outline 4 3 File Structure and Output Directory Structure5 3.1 Scene Composition........................................6 3.2 Resources and Visualization Types...............................6 4 pe Objects 9 5 DensFields 10 5.1 File Structure........................................... 10 5.2 Usage............................................... 10 6 CellFields 17 6.1 Usage and Output File Structure................................ 17 6.2 Porous Medium Example.................................... 17 7 Free Surface Visualization 20 7.1 Free Surface Extraction..................................... 20 7.2 Usage and Examples....................................... 20 8 Conclusion 23 1 Introduction The waLBerla framework is a versatile, parallel fluid solver based on the lattice Boltzmann method (LBM). The acronym waLBerla stands for widely applicable lattice Boltzmann solver from Erlangen. Besides simulation of simple fluid flow, it supports a variety of different applications involving multi-phase and free surface flows and particulate flows with fully resolved, moving particles [DGF+07, GFI+08]. To enable efficient analysis of the simulation outcome, waLBerla features different means of data visualization. Parallel generic modules [GDF+07b] enable plotting of computed values into XMGrace-compatible graphs and writing of arbitrary, cell-based data to file formats of the visualization tool kit (VTK) [VTK09] that can be viewed and further analyzed by VTK-based tools like ParaView [Par09]. Besides value-based validation, a realistic visualization of the flow and its characteristic quantities is important and of avail because human intuition is best proof for nature's behavior. Consequently, waLBerla has been extented by a generic module for output files that are readable by POV-Ray, which is a well-known ray tracer tool [oVPL04]. Thus, the motion would become visible by rendering images of different time steps with the POV-Ray raytracer. Initially developed to only visualize particulate flows, this waLBerla module has been enhanced in order to be compatible with free surface flows, too, and be able to visualize scientific relevant data like densities, velocities and forces. This report gives a detailed insight into the technical realization of a flexible interface between waLBerla and POV-Ray, using the POV-Ray scene description language (SDL). 3 2 Feature Outline WaLBerla can create special output data using the POV-Ray scene description language (SDL). SDL is a language used to define a 3-dimensional world consisting of various geometrical shapes, light sources, etc... The following list gives a rough summary of the output options currently provided by waLBerla. DensField: A DensField is a 3-dimensional array of floating point values. As described in [GDF+07a], waLBerla holds the simulation data in Fields. WaLBerla can be instructed to write out the values of any field of type ScalarField<Real> or type VecField<Real> (DensField1 and VelField, in which waLBerla stores the macroscopic values of density and fluid velocity, are also possible) in an axis-aligned subregion as a DensField. Typical application: Visualization of the velocity or density profile of a flow. CellField: CellFields can be used to visualize the waLBerla FlagField. A CellField is thus an axis-aligned subregion of the FlagField. Usually one is interested in cells of a certain flag state only. Typical application: Visualization of the geometry of a porous medium. FreeSurface: If a free surface flow is simulated, the behavior of the free surface may be visualized either by its surface normals, which can be shown as glyphs, or by a triangle mesh resembling the free surface. Typical application: Visualization of two-phase free surface flows, such as foams. Obstacles: The various kinds of obstacles (i.e. particles, walls, etc.) supported by waLBerla (see [GDF+07b]) can be visualized. Typical application: Visualization of particle suspensions. Ray tracing is a powerful way to create images from spatial information, but because of its computation- intensive nature it is far from being interactive. In spite of this limitation, one of the main design goals was to provide the user with as much flexibility as possible, i.e., to provide the output not only in a format adapted to POV-Ray, but also well-readable and modifiable for the user. The SDL files generated by waLBerla can be edited to adjust the output files to change the properties (point of view, light sources, colors and textures of objects, etc.) of the final images. The following section treats the activation of POV-Ray output via waLBerla parameter files. An overview of the most important output files and file dependencies is given. Also the incorporation of external resources, e.g. textures, to a visualization is explained. For the actual usage and visualization options of DensFields, CellFields, FreeSurfaces and Obstacles, respectively, own sections have been devoted. It is suggested to the reader to take a look on the next section carefully and then continue with a section of his interest. 1Name coincidence: There is also a waLBerla-internal scalar field called DensField! 4 3 File Structure and Output Directory Structure In order to facilitate POV-Ray visualizations, the various output options have been integrated in the waLBerla parameter file. A povray block has to be specified by the user in order to activate and control the POV-Ray specific output. Listing1 exemplarily shows a typical povray block that would create an output directory named /simdata/povray. In the output directory waLBerla creates the directory structure shown in Fig.3. Figure 1: Directory Structure ./dat contains the data to be rendered /0 objects/data written by process 1. /1 objects/data written by process 2. ... ./plane velocity planes (not subject of this report) /0 objects/data written by process 1. /1 objects/data written by process 2. ... ./png empty output directory for final images rendered by POV-Ray ./res include files for POV-Ray /resource1.inc user-declared include file 1 /resource2.inc user-declared include file 2 ... ./Globals.inc global declarations and scene composition for the POV-Ray visualization ./Cam0.pov Camera 0 ./Cam1.pov Camera 1 ... ./GenerateMPG.py a python script that calls FFmpeg to create animations from rendered images. ./GeneratePOV.py a python script that calls POV-Ray to render the final images. Inside the povray block, the spacing keyword specifies how often data is written to the ./dat direc- tory in the output directory specified by filename. Since a simulation may run on multiple processes in parallel, each process will store its data in a subdirectory named by the process number. All objects (DensFields, obstacles, etc.) for the visualization are stored in these subdirectories, depending on which process the respective data is computed. For more details on waLBerla parallelization, please refer to [GDF+07b]. The data output files of different time steps for each object are numbered in subsequent order starting from zero - irrespective of the setting of the spacing variable. To eventually compose the written objects to a scene, waLBerla creates the file ./Globals.inc, which will be described in the next subsection. Inside the povray block, one ore more cameras have to be defined in the form of camera blocks. For each camera, individual light sources can be added to the scene. Each camera block leads to the creation of a file ./Cam<number>.pov, where number is substituted by the number of the camera. The camera file automatically includes the scene file ./Globals.inc. For more information on cameras and light sources please refer to the POV-Ray documentation [oVPL04]. Additionally the user can instruct the inclusion of external POV-Ray resources to the file ./Globals.inc 5 Listing 1: Povray block example povray f spacing10; //writedataevery10.thtimestep filename /simdata/povray; // directory to create file −structure in camera f p o s i t i o n L <−25,−25,75>; // position of the camera l o o k A t L <25 ,25 ,25 >; //controlsthelook−direction of the camera p o i n t l i g h t f // automatically add a light source for this camera p o s i t i o n L <−25, −25, 75 >; // light position rgb <1 ,1 ,1 >; //lightcolor g a r e a l i g h t f // another type of light source p o s i t i o n L <10, 1 , 40 >; l o w e r l e f t L <15, 0 , 0>; t o p r i g h t L <0, 0 , 15 >; s a m p l e x 1 ; s a m p l e y 1 ; f a d e distance 120; f a d e p o w e r 1 ; g g // 'resource' blocks can be used to include additional sdl files in povray r e s o u r c e f file "textures.inc"; // povray standard textures g r e s o u r c e f file examples/povray/resources/Textures.dat; g // user defined textures g by specifying an arbitrary number of resource blocks. Each resource block must have one file pa- rameter defined, which is either the file name of a user-created file or a standard include file provided by POV-Ray. In the latter case, the file name must be given in the form ''<filename>''. In the former case, the external file will automatically be copied into the output directory as ./res/resource<number>.inc. Again, the files are tagged with a number <number>.
Recommended publications
  • Photon Mapping Assignment
    Photon Mapping Assignment 15-864 Advanced Computer Graphics, Carnegie Mellon University Instructor: Doug L. James TA: Christopher Twigg Introduction sampling to emit photons of equal intensity from the diffuse area light source. Use the ray tracer’s functionality to propagate photons In this assignment you will implement (portions of) a photon map- (reflect, transmit and absorb) throughout the scene. To maintain ping renderer. For simplicity, we will only consider scenes with a photons of similar intensity, use Russian roulette [Arvo and Kirk single area light source, and assume surfaces are diffuse, or purely 1990] to determine if photons are absorbed (diffuse), transmitted specular (e.g., mirror or glass). To generate images for testing and (transparent), or reflected at surfaces. Use Schlick’s approximation grading, a test scene will be provided for you on the class website; to Fresnel’s specular reflection coefficient to determine the prob- this will be a very simple consisting of the Cornell box, an area ability of transmission and reflection at specular interfaces, e.g., light source, and specular spheres. Although a brief explanation of glass. Store the photons in the photon map using Jensen’s kd-tree what needs to be done is given below, further implementation de- data structure implementation (provided on the web page). Once tails can be found in [Jensen 2001; Jensen 1996], as well as other these photons are stored, the data structure can compute the filtered ray tracing [Shirley 2000], Monte Carlo [Jensen 2003], and global irradiance estimates you need later. illumination texts [Dutre´ et al. 2003]. Build the Caustic Photon Map (20 points): The high- Getting Started: Familiarize yourself with resolution caustic photon map represents the LS+D paths, and it the ray tracer is therefore only necessary to emit photons toward specular objects when computing the caustic photon map.
    [Show full text]
  • POV-Ray Reference
    POV-Ray Reference POV-Team for POV-Ray Version 3.6.1 ii Contents 1 Introduction 1 1.1 Notation and Basic Assumptions . 1 1.2 Command-line Options . 2 1.2.1 Animation Options . 3 1.2.2 General Output Options . 6 1.2.3 Display Output Options . 8 1.2.4 File Output Options . 11 1.2.5 Scene Parsing Options . 14 1.2.6 Shell-out to Operating System . 16 1.2.7 Text Output . 20 1.2.8 Tracing Options . 23 2 Scene Description Language 29 2.1 Language Basics . 29 2.1.1 Identifiers and Keywords . 30 2.1.2 Comments . 34 2.1.3 Float Expressions . 35 2.1.4 Vector Expressions . 43 2.1.5 Specifying Colors . 48 2.1.6 User-Defined Functions . 53 2.1.7 Strings . 58 2.1.8 Array Identifiers . 60 2.1.9 Spline Identifiers . 62 2.2 Language Directives . 64 2.2.1 Include Files and the #include Directive . 64 2.2.2 The #declare and #local Directives . 65 2.2.3 File I/O Directives . 68 2.2.4 The #default Directive . 70 2.2.5 The #version Directive . 71 2.2.6 Conditional Directives . 72 2.2.7 User Message Directives . 75 2.2.8 User Defined Macros . 76 3 Scene Settings 81 3.1 Camera . 81 3.1.1 Placing the Camera . 82 3.1.2 Types of Projection . 86 3.1.3 Focal Blur . 88 3.1.4 Camera Ray Perturbation . 89 3.1.5 Camera Identifiers . 89 3.2 Atmospheric Effects .
    [Show full text]
  • Real-Time Global Illumination with Photon Mapping Niklas Smal and Maksim Aizenshtein UL Benchmarks
    CHAPTER 24 Real-Time Global Illumination with Photon Mapping Niklas Smal and Maksim Aizenshtein UL Benchmarks ABSTRACT Indirect lighting, also known as global illumination, is a crucial effect in photorealistic images. While there are a number of effective global illumination techniques based on precomputation that work well with static scenes, including global illumination for scenes with dynamic lighting and dynamic geometry remains a challenging problem. In this chapter, we describe a real-time global illumination algorithm based on photon mapping that evaluates several bounces of indirect lighting without any precomputed data in scenes with both dynamic lighting and fully dynamic geometry. We explain both the pre- and post-processing steps required to achieve dynamic high-quality illumination within the limits of a real- time frame budget. 24.1 INTRODUCTION As the scope of what is possible with real-time graphics has grown with the advancing capabilities of graphics hardware, scenes have become increasingly complex and dynamic. However, most of the current real-time global illumination algorithms (e.g., light maps and light probes) do not work well with moving lights and geometry due to these methods’ dependence on precomputed data. In this chapter, we describe an approach based on an implementation of photon mapping [7], a Monte Carlo method that approximates lighting by first tracing paths of light-carrying photons in the scene to create a data structure that represents the indirect illumination and then using that structure to estimate indirect light at points being shaded. See Figure 24-1. Photon mapping has a number of useful properties, including that it is compatible with precomputed global illumination, provides a result with similar quality to current static techniques, can easily trade off quality and computation time, and requires no significant artist work.
    [Show full text]
  • Efficient Rendering of Caustics with Streamed Photon Mapping
    BULLETIN OF THE POLISH ACADEMY OF SCIENCES TECHNICAL SCIENCES, Vol. 65, No. 3, 2017 DOI: 10.1515/bpasts-2017-0040 Efficient rendering of caustics with streamed photon mapping K. GUZEK and P. NAPIERALSKI* Institute of Information Technology, Lodz University of Technology, 215 Wolczanska St., 90-924 Lodz, Poland Abstract. In this paper, we present the streamed photon mapping method for enhancing the rendering of caustics. In order to achieve a realistic caustic effect, global illumination methods require additional data, which are gathered by creating a caustic map or increasing the number of samples used for rendering. Our method employs a stream of photons with a varying luminance level depending on the material properties of the surface. The application of a concentrated photon stream provides the ability to render caustics effectively without increasing the number of photons in a photon map. Such an approach increases visibility of results, while also allowing for faster computations. Key words: rendering, global illumination, photon mapping, caustics. 1. Introduction 2. Rendering caustics The interaction of light with matter in the real world results The first attempt to simulate a natural caustic effect was the in a variety of optical phenomena. Understanding how those path tracing method, introduced by James Kajiya in 1986 [4]. phenomena occur and where to implement them is crucial for However, the method proved to be highly inefficient. The creating realistic image renders. When observing the reflection caustics were poorly rendered, as the light source was obscure. or refraction of light through curved surfaces, one may notice A significant improvement was introduced both and inde- some characteristic patches of light, referred to as caustics.
    [Show full text]
  • Getting Started (Pdf)
    GETTING STARTED PHOTO REALISTIC RENDERS OF YOUR 3D MODELS Available for Ver. 1.01 © Kerkythea 2008 Echo Date: April 24th, 2008 GETTING STARTED Page 1 of 41 Written by: The KT Team GETTING STARTED Preface: Kerkythea is a standalone render engine, using physically accurate materials and lights, aiming for the best quality rendering in the most efficient timeframe. The target of Kerkythea is to simplify the task of quality rendering by providing the necessary tools to automate scene setup, such as staging using the GL real-time viewer, material editor, general/render settings, editors, etc., under a common interface. Reaching now the 4th year of development and gaining popularity, I want to believe that KT can now be considered among the top freeware/open source render engines and can be used for both academic and commercial purposes. In the beginning of 2008, we have a strong and rapidly growing community and a website that is more "alive" than ever! KT2008 Echo is very powerful release with a lot of improvements. Kerkythea has grown constantly over the last year, growing into a standard rendering application among architectural studios and extensively used within educational institutes. Of course there are a lot of things that can be added and improved. But we are really proud of reaching a high quality and stable application that is more than usable for commercial purposes with an amazing zero cost! Ioannis Pantazopoulos January 2008 Like the heading is saying, this is a Getting Started “step-by-step guide” and it’s designed to get you started using Kerkythea 2008 Echo.
    [Show full text]
  • 2014 3-4 Acta Graphica.Indd
    Vidmar et al.: Performance Assessment of Three Rendering..., acta graphica 25(2014)3–4, 101–114 author viewpoint acta graphica 234 Performance Assessment of Three Rendering Engines in 3D Computer Graphics Software Authors Žan Vidmar, Aleš Hladnik, Helena Gabrijelčič Tomc* University of Ljubljana Faculty of Natural Sciences and Engineering Slovenia *E-mail: [email protected] Abstract: The aim of the research was the determination of testing conditions and visual and numerical evaluation of renderings made with three different rendering engines in Maya software, which is widely used for educational and computer art purposes. In the theoretical part the overview of light phenomena and their simulation in virtual space is presented. This is followed by a detailed presentation of the main rendering methods and the results and limitations of their applications to 3D ob- jects. At the end of the theoretical part the importance of a proper testing scene and especially the role of Cornell box are explained. In the experimental part the terms and conditions as well as hardware and software used for the research are presented. This is followed by a description of the procedures, where we focused on the rendering quality and time, which enabled the comparison of settings of different render engines and determination of conditions for further rendering of testing scenes. The experimental part continued with rendering a variety of simple virtual scenes including Cornell box and virtual object with different materials and colours. Apart from visual evaluation, which was the starting point for comparison of renderings, a procedure for numerical estimation and colour deviations of ren- derings using the selected regions of interest in the final images is presented.
    [Show full text]
  • The Photon Mapping Method
    7 The Photon Mapping Method “I get by with a little help from my friends.” —John Lennon, 1940–1980 HOTON mapping is a practical approach for computing global illumination within complex P environments. Much like irradiance caching methods, photon mapping caches and reuses illumination information in the scene for efficiency. Photon mapping has also been successfully applied for computing lighting within, and in the presence of, participating media. In this chapter we briefly introduce the photon mapping technique. This sets the foundation for our contributions in the next chapter, which make volumetric photon mapping practical. 7.1 Algorithm Overview Photon mapping, introduced by Jensen[1995; 1996; 1997; 1998; 2001], is a practical approach for computing global illumination. At a high level, the algorithm consists of two main steps: Algorithm 7.1:PHOTONMAPPING() 1 PHOTONTRACING(); 2 RENDERUSINGPHOTONMAP(); In the first step, a lighting simulation is performed by tracing packets of energy, or photons, from light sources and storing these photons as they scatter within the scene. This processes 119 120 Algorithm 7.2:PHOTONTRACING() 1 n 0; e Æ 2 repeat 3 (l, pdf (l)) = CHOOSELIGHT(); 4 (xp , ~!p , ©p ) = GENERATEPHOTON(l ); ©p 5 TRACEPHOTON(xp , ~!p , pdf (l) ); 6 n 1; e ÅÆ 7 until photon map full ; 1 8 Scale power of all photons by ; ne results in a set of photon maps, which can be used to efficiently query lighting information. In the second pass, the final image is rendered using Monte Carlo ray tracing. This rendering step is made more efficient by exploiting the lighting information cached in the photon map.
    [Show full text]
  • The Beam Radiance Estimate for Volumetric Photon Mapping
    The Beam Radiance Estimate for Volumetric Photon Mapping Wojciech Jarosz, Matthias Zwicker, and Henrik Wann Jensen University of California, San Diego Abstract We present a new method for efficiently simulating the scattering of light within participating media. Using a theoretical reformulation of volumetric photon mapping, we develop a novel photon gathering technique for participating media. Traditional volumetric photon mapping samples the in-scattered radiance at numerous points along the length of a single ray by performing costly range queries within the photon map. Our technique replaces these multiple point-queries with a single beam-query, which explicitly gathers all photons along the length of an entire ray. These photons are used to estimate the accumulated in-scattered radiance arriving from a particular direction and need to be gathered only once per ray. Our method handles both fixed and adaptive kernels, is faster than regular volumetric photon mapping, and produces images with less noise. Keywords: participating media, light transport, global illumination, rendering, photon tracing, photon map, ray marching, nearest neighbor, variable kernel method. Categories and Subject Descriptors (according to ACM CCS): I.3.7 [Computer Graphics]: raytracing; color, shading, shadowing, and texture; I.6.8 [Simulation and Modeling]: Monte Carlo; G.1.9 [Numerical Analysis]: Fredholm equations; integro-differential equations. 1. Introduction these approaches is that they suffer from noise that can only The appearance of many natural phenomena, such as human be overcome with a huge computational effort. skin, clouds, fire, water, or the atmosphere, are strongly in- One strategy to solve this issue is to make simplifying as- fluenced by the interaction of light with volumetric media.
    [Show full text]
  • Kerkythea 2007 Rendering System
    GETTING STARTED PHOTO REALISTIC RENDERS OF YOUR 3D MODELS Available for Ver. 1.01 © Kerkythea 2008 Echo Date: April 24th, 2008 GETTING STARTED Page 1 of 41 Written by: The KT Team GETTING STARTED Preface: Kerkythea is a standalone render engine, using physically accurate materials and lights, aiming for the best quality rendering in the most efficient timeframe. The target of Kerkythea is to simplify the task of quality rendering by providing the necessary tools to automate scene setup, such as staging using the GL real-time viewer, material editor, general/render settings, editors, etc., under a common interface. Reaching now the 4th year of development and gaining popularity, I want to believe that KT can now be considered among the top freeware/open source render engines and can be used for both academic and commercial purposes. In the beginning of 2008, we have a strong and rapidly growing community and a website that is more "alive" than ever! KT2008 Echo is very powerful release with a lot of improvements. Kerkythea has grown constantly over the last year, growing into a standard rendering application among architectural studios and extensively used within educational institutes. Of course there are a lot of things that can be added and improved. But we are really proud of reaching a high quality and stable application that is more than usable for commercial purposes with an amazing zero cost! Ioannis Pantazopoulos January 2008 Like the heading is saying, this is a Getting Started “step-by-step guide” and it’s designed to get you started using Kerkythea 2008 Echo.
    [Show full text]
  • Introduction to POV-Ray
    Introduction to POV-Ray POV-Team for POV-Ray Version 3.6.1 ii Contents 1 Introduction 1 1.1 Program Description . 2 1.2 What is Ray-Tracing? . 2 1.3 What is POV-Ray? . 2 1.4 Features . 3 1.5 The Early History of POV-Ray . 3 1.5.1 The Original Creation Message . 5 1.5.2 The Name . 6 1.5.3 A Historic ’Version History’ . 7 1.6 How Do I Begin? . 8 1.7 Notation and Basic Assumptions . 9 2 Getting Started 11 2.1 Our First Image . 11 2.1.1 Understanding POV-Ray’s Coordinate System . 11 2.1.2 Adding Standard Include Files . 12 2.1.3 Adding a Camera . 13 2.1.4 Describing an Object . 13 2.1.5 Adding Texture to an Object . 14 2.1.6 Defining a Light Source . 14 2.2 Basic Shapes . 15 2.2.1 Box Object . 15 2.2.2 Cone Object . 16 2.2.3 Cylinder Object . 16 2.2.4 Plane Object . 16 2.2.5 Torus Object . 17 2.3 CSG Objects . 22 2.3.1 What is CSG? . 22 2.3.2 CSG Union . 22 2.3.3 CSG Intersection . 23 2.3.4 CSG Difference . 24 2.3.5 CSG Merge . 25 2.3.6 CSG Pitfalls . 26 2.4 The Light Source . 26 2.4.1 The Pointlight Source . 26 2.4.2 The Spotlight Source . 28 2.4.3 The Cylindrical Light Source . 29 2.4.4 The Area Light Source . 29 2.4.5 The Ambient Light Source .
    [Show full text]
  • Photon Mapping
    Photon Mapping CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Photon mapping A two-pass method Pass 1: Build the photon map (photon tracing) Pass 2: Render the image using the photon map CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Building the Photon Map Photon Tracing CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Rendering using the Photon Map Rendering CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Photon Tracing Photon emission • Projection maps • Photon scattering • Russian Roulette • The photon map data structure • Balancing the photon map • CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen What is a photon? Flux (power) - not radiance! • Collection of physical photons • ⋆ A fraction of the light source power ⋆ Several wavelengths combined into one entity CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Photon emission Given Φ Watt lightbulb. Emit N photons. Each photon has the power Φ Watt. N Photon power depends on the number of emitted • photons. Not on the number of photons in the photon map. CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Diffuse point light Generate random direction Emit photon in that direction // Find random direction do { x = 2.0*random()-1.0; y = 2.0*random()-1.0; z = 2.0*random()-1.0; while ( (x*x + y*y + z*z) > 1.0 ); } CSE272: Advanced Image Synthesis (Spring 2010) Henrik Wann Jensen Example: Diffuse square light - Generate random position p on square - Generate diffuse direction
    [Show full text]
  • Mimicking POV-Ray Photorealistic Rendering with Accelerated Opengl Pipeline
    Mimicking POV-Ray Photorealistic Rendering with Accelerated OpenGL Pipeline J. Peč iva P. Zemč ík J. Navrátil Brno University of Technology Brno University of Technology Brno University of Technology Božetě chova 2 Božetě chova 2 Božetě chova 2 612 66 Brno, Czech Republic 612 66 Brno, Czech Republic 612 66 Brno, Czech Republic [email protected] [email protected] [email protected] ABSTRACT Traditional ray tracing algorithms tend to provide photorealistic results but at high computing costs. Rendering times of minutes or days are not exceptional. On the other side, hardware accelerated OpenGL rendering can provide real-time interaction with virtual environment with unnoticeable rendering times. This paper attempts to bring these two together and attempts to give an answer on the difficulty of implementing real-time photorealistic rendering. The paper presents case study on mimicking of POV-Ray photorealistic rendering with accelerated OpenGL pipeline. The study shows the opportunity to accelerate some photorealistic algorithms by real-time approaches while, on the other side, it locates the parts that are difficult to replace by traditional real-time rendering paradigms. Particularly, it is shown how to implement primary and shadow rays and POV-Ray-like material model using accelerated OpenGL pipeline using modern shader techno- logy. On the other side, the difficulties of reflected and refracted rays implementation using real-time rendering approaches is discussed. Keywords photorealistic rendering, POV-Ray, OpenGL, raytracing, shaders 1 Introduction graphics usually tend to provide poor results on advanced scene lighting setups. If real-time photorealistic visualizations would be Photorealistic rendering is a very important domain in computer possible, they would provide high quality visualizations, making graphic because of the realism that is often expected from architects and designers much more time effective while graphics applications.
    [Show full text]