diff --git a/report/.gitattributes b/report/.gitattributes new file mode 100644 index 0000000..1c45135 --- /dev/null +++ b/report/.gitattributes @@ -0,0 +1,3 @@ +*.ttf filter=lfs diff=lfs merge=lfs -text +*.jpg filter=lfs diff=lfs merge=lfs -text +*.jpeg filter=lfs diff=lfs merge=lfs -text diff --git a/report/Interactive Exploration of Nonlinear Ray Casting.pdf b/report/Interactive Exploration of Nonlinear Ray Casting.pdf new file mode 100644 index 0000000..a6909a9 --- /dev/null +++ b/report/Interactive Exploration of Nonlinear Ray Casting.pdf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:51063fc66163d4a4b680f47705f436fec194eb17a2432aa64a470ba32da2106b +size 3197747 diff --git a/report/Practical.bib b/report/Practical.bib new file mode 100644 index 0000000..656ffc3 --- /dev/null +++ b/report/Practical.bib @@ -0,0 +1,372 @@ + +@article{amanatidesFastVoxelTraversal1987, + title = {A {{Fast Voxel Traversal Algorithm}} for {{Ray Tracing}}}, + author = {Amanatides, John and Woo, Andrew}, + date = {1987}, + journaltitle = {Proceedings of EuroGraphics}, + volume = {87}, + abstract = {A fast and simple voxel traversal algorithm through a 3D space partition is introduced. Going from one voxel to its neighbour requires only two floating point comparisons and one floating point addition. Also, multiple ray intersections with objects that are in more than one voxel are eliminated.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/YT3R8U7M/Amanatides und Woo - A Fast Voxel Traversal Algorithm for Ray Tracing.pdf} +} + +@article{amentRefractiveRadiativeTransfer2014, + title = {Refractive Radiative Transfer Equation}, + author = {Ament, Marco and Bergmann, Christoph and Weiskopf, Daniel}, + date = {2014-03}, + journaltitle = {ACM Transactions on Graphics}, + shortjournal = {ACM Trans. Graph.}, + volume = {33}, + number = {2}, + pages = {1--22}, + issn = {0730-0301, 1557-7368}, + doi = {10.1145/2557605}, + url = {https://dl.acm.org/doi/10.1145/2557605}, + urldate = {2021-08-03}, + abstract = {We introduce a refractive radiative transfer equation to the graphics community for the physically based rendering of participating media that have a spatially varying index of refraction. We review principles of geometric nonlinear optics that are crucial to discuss a more generic light transport equation. In particular, we present an optical model that has an integral form suitable for rendering. We show rigorously that the continuous bending of light rays leads to a nonlinear scaling of radiance. To obtain physically correct results, we build on the concept of basic radiance—known from discontinuous refraction—to conserve energy in such complex media. Furthermore, the generic model accounts for the reduction in the speed of light due to the index of refraction to render transient effects like the propagation of light echoes. We solve the refractive volume rendering equation by extending photon mapping with transient light transport in a refractive, participating medium. We demonstrate the impact of our approach on the correctness of rendered images of media that are dominated by spatially continuous refraction and multiple scattering. Furthermore, our model enables us to render visual effects like the propagation of light echoes or time-of-flight imagery that cannot be produced with previous approaches.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/V7NXZ5RB/Ament et al. - 2014 - Refractive radiative transfer equation.pdf} +} + +@online{beaufortAccessModernGPU2021, + title = {Access Modern {{GPU}} Features with {{WebGPU}}}, + author = {Beaufort, François and Wallez, Corentin}, + date = {2021}, + url = {https://web.dev/gpu/}, + urldate = {2021-10-25}, + abstract = {WebGPU enables high-performance 3D graphics and data-parallel computation on the web.}, + langid = {english}, + organization = {{web.dev blog}}, + file = {/Users/niklaskorz/Zotero/storage/94ISSY7J/gpu.html} +} + +@book{blandyProgrammingRust2021, + title = {Programming {{Rust}}}, + author = {Blandy, Jim}, + editor = {Orendorff, Jason and Tindall, Leonora}, + date = {2021}, + edition = {2}, + publisher = {{O'Reilly Media, Inc.}}, + isbn = {978-1-4920-5259-3}, + langid = {english} +} + +@inproceedings{blinnModelsLightReflection1977, + title = {Models of Light Reflection for Computer Synthesized Pictures}, + booktitle = {Proceedings of the 4th Annual Conference on Computer Graphics and Interactive Techniques}, + author = {Blinn, James F.}, + date = {1977}, + pages = {192--198}, + doi = {10.1145/563858.563893}, + abstract = {In the production of computer generated pictures of three dimensional objects, one stage of the calculation is the determination of the intensity of a given object once its visibility has been established. This is typically done by modelling the surface as a perfect diffuser, sometimes with a specular component added for the simulation of hilights. This paper presents a more accurate function for the generation of hilights which is based on some experimental measurements of how light reflects from real surfaces. It differs from previous models in that the intensity of the hilight changes with the direction of the light source. Also the position and shape of the hilights is somewhat different from that generated by simpler models. Finally, the hilight function generates different results when simulating metallic vs. nonmetallic surfaces. Many of the effects so generated are somewhat subtle and are apparent only during movie sequences. Some representative still frames from such movies are included.}, + isbn = {978-1-4503-7355-5}, + keywords = {computer graphics,graphic display,hidden surface removal,shading}, + file = {/Users/niklaskorz/Zotero/storage/IP99UIAY/Blinn - MODELS OF LIQrHT REFLECTION FOR CO1PUTER SYNTHESIZ.pdf} +} + +@online{FIFACoinsWoW, + title = {{{FIFA Coins}}, {{WoW Classic Gold}}, {{Game Key Deals}} - {{MMOGA}}}, + url = {https://www.mmoga.de/}, + urldate = {2021-09-24} +} + +@article{gaoIterativeNonlinearBeam, + title = {Iterative Nonlinear Beam Propagation Using {{Hamiltonian}} Ray Tracing and {{Wigner}} Distribution Function}, + author = {Gao, Hanhong and Tian, Lei and Zhang, Baile and Barbastathis, George}, + journaltitle = {Optics Letters}, + volume = {35}, + number = {24}, + pages = {4148}, + issn = {0146-9592}, + url = {https://www.academia.edu/1980442/Iterative_nonlinear_beam_propagation_using_Hamiltonian_ray_tracing_and_Wigner_distribution_function}, + urldate = {2021-04-17}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/PGSWHQAU/Iterative_nonlinear_beam_propagation_using_Hamiltonian_ray_tracing_and_Wigner_distribution_func.html} +} + +@article{grollerNonlinearRayTracing1995, + title = {Nonlinear {{Ray Tracing}}: Visualizing {{Strange Worlds}}}, + shorttitle = {Nonlinear Ray Tracing}, + author = {Gröller, Eduard}, + date = {1995}, + journaltitle = {The Visual Computer}, + shortjournal = {The Visual Computer}, + volume = {11}, + number = {5}, + pages = {263--274}, + issn = {1432-2315}, + doi = {10.1007/BF01901044}, + abstract = {Nonlinear ray tracing is investigated in this work. Sources of nonlinearity such as gravity centers, gravity lines, chaotic dynamical systems, and parametric curved rays are discussed. Curved rays are represented either iteratively or hierarchically. Algorithms for testing whether a curved ray and a 3D object intersect are presented. Sample images of a test implementation show the feasibility of the approach. Applications of nonlinear ray tracing are the visualization of relativistic effects, visualization of the geometric behavior of nonlinear dynamical systems, visualization of the movement of charged particles in a force field (e.g., electron movement), virtual reality, and arts.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/2VTKD2IE/Gröller - 1995 - Nonlinear ray tracing Visualizing strange worlds.pdf} +} + +@report{hansenLearnWgpu2021, + title = {Learn {{Wgpu}}}, + author = {Hansen, Benjamin}, + date = {2021}, + url = {https://sotrh.github.io/learn-wgpu/}, + urldate = {2021-09-20}, + langid = {american}, + file = {/Users/niklaskorz/Zotero/storage/4BKE3XLV/learn-wgpu.html} +} + +@article{ihrkeEikonalRenderingEfficient2007, + title = {Eikonal Rendering: Efficient Light Transport in Refractive Objects}, + shorttitle = {Eikonal Rendering}, + author = {Ihrke, Ivo and Ziegler, Gernot and Tevs, Art and Theobalt, Christian and Magnor, Marcus and Seidel, Hans-Peter}, + date = {2007-07-29}, + journaltitle = {ACM Transactions on Graphics}, + shortjournal = {ACM Trans. Graph.}, + volume = {26}, + number = {3}, + pages = {59}, + issn = {0730-0301, 1557-7368}, + doi = {10.1145/1276377.1276451}, + url = {https://dl.acm.org/doi/10.1145/1276377.1276451}, + urldate = {2021-07-25}, + abstract = {We present a new method for real-time rendering of sophisticated lighting effects in and around refractive objects. It enables us to realistically display refractive objects with complex material properties, such as arbitrarily varying refractive index, inhomogeneous attenuation, as well as spatially-varying anisotropic scattering and reflectance properties. User-controlled changes of lighting positions only require a few seconds of update time. Our method is based on a set of ordinary differential equations derived from the eikonal equation, the main postulate of geometric optics. This set of equations allows for fast casting of bent light rays with the complexity of a particle tracer. Based on this concept, we also propose an efficient light propagation technique using adaptive wavefront tracing. Efficient GPU implementations for our algorithmic concepts enable us to render a combination of visual effects that were previously not reproducible in real-time.}, + langid = {english}, + keywords = {maybe}, + file = {/Users/niklaskorz/Zotero/storage/3EGWH2ER/Ihrke et al. - 2007 - Eikonal rendering efficient light transport in re.pdf} +} + +@online{IntroductionShadingReflection, + title = {Introduction to {{Shading}} ({{Reflection}}, {{Refraction}} and {{Fresnel}})}, + url = {https://www.scratchapixel.com/lessons/3d-basic-rendering/introduction-to-shading/reflection-refraction-fresnel}, + urldate = {2021-08-04}, + file = {/Users/niklaskorz/Zotero/storage/5MBF9BIN/reflection-refraction-fresnel.html} +} + +@article{lehnSimulationMirages1992, + title = {Simulation of Mirages}, + author = {Lehn, W. H. and Friesen, W.}, + date = {1992-03-20}, + journaltitle = {Applied Optics}, + shortjournal = {Appl. Opt.}, + volume = {31}, + number = {9}, + pages = {1267}, + issn = {0003-6935, 1539-4522}, + doi = {10.1364/AO.31.001267}, + url = {https://www.osapublishing.org/abstract.cfm?URI=ao-31-9-1267}, + urldate = {2021-07-25}, + langid = {english}, + keywords = {maybe}, + file = {/Users/niklaskorz/Zotero/storage/MC4EML68/Lehn und Friesen - 1992 - Simulation of mirages.pdf} +} + +@online{malyshauRunningWebWebGPU2021, + title = {Running on the {{Web}} with {{WebGPU}} and {{WebGL}}}, + author = {Malyshau, Dzmitry and Connor, Fitzgerald}, + date = {2021}, + origdate = {2018-09-13T19:18:50Z}, + url = {https://github.com/gfx-rs/wgpu/wiki/Running-on-the-Web-with-WebGPU-and-WebGL}, + urldate = {2021-10-19}, + abstract = {Safe and portable GPU abstraction in Rust, implementing WebGPU API.}, + organization = {{wgpu wiki}} +} + +@online{malyshauShaderTranslationBenchmark2021, + title = {Shader Translation Benchmark on {{Dota2}}/{{Metal}}}, + author = {Malyshau, Dzmitry}, + date = {2021}, + url = {https://gfx-rs.github.io/2021/05/09/dota2-msl-compilation.html}, + urldate = {2021-10-12}, + organization = {{gfx-rs blog}}, + file = {/Users/niklaskorz/Zotero/storage/2XY34I3W/dota2-msl-compilation.html} +} + +@report{malyshauWebGPU2021, + type = {W3C Working Draft}, + title = {{{WebGPU}}}, + author = {Malyshau, Dzmitry and Ninomiya, Kai and Fan, Justin}, + date = {2021}, + institution = {{World Wide Web Consortium (W3C)}}, + url = {https://www.w3.org/TR/2021/WD-webgpu-20210915/}, + urldate = {2021-09-16}, + file = {/Users/niklaskorz/Zotero/storage/E7DIE8NF/WD-webgpu-20210915.html} +} + +@report{mdncontributorsCompilingRustWebAssembly2021, + title = {Compiling from {{Rust}} to {{WebAssembly}}}, + author = {{MDN contributors}}, + date = {2021}, + institution = {{Mozilla Developer Network}}, + url = {https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm}, + urldate = {2021-10-19}, + abstract = {If you have some Rust code, you can compile it into WebAssembly (wasm). This tutorial takes you through all you need to know to compile a Rust project to wasm and use it in an existing web app.}, + langid = {american}, + file = {/Users/niklaskorz/Zotero/storage/VQEDMUT9/Rust_to_wasm.html} +} + +@article{mollerFastMinimumStorage1997, + title = {Fast, {{Minimum Storage Ray}}-{{Triangle Intersection}}}, + author = {Möller, Tomas and Trumbore, Ben}, + date = {1997}, + journaltitle = {Journal of Graphics Tools}, + shortjournal = {Journal of Graphics Tools}, + volume = {2}, + number = {1}, + pages = {21--28}, + issn = {1086-7651}, + doi = {10.1080/10867651.1997.10487468}, + abstract = {We present a clean algorithm for determining whether a ray intersects a triangle. The algorithm translates the origin of the ray and then changes the base to yield a vector (t u v)T, where t is the distance to the plane in which the triangle lies and (u, v) represents the coordinates inside the triangle.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/3KBA9U5U/Möller und Trumbore - 1997 - Fast, Minimum Storage Ray-Triangle Intersection.pdf} +} + +@report{netoWebGPUShadingLanguage2021, + type = {W3C Working Draft}, + title = {{{WebGPU Shading Language}}}, + author = {Neto, David and Maxfield, Myles and Sinclair, Dan}, + date = {2021}, + institution = {{World Wide Web Consortium (W3C)}}, + url = {https://www.w3.org/TR/2021/WD-WGSL-20210910/}, + urldate = {2021-09-16}, + file = {/Users/niklaskorz/Zotero/storage/LUN9TLP4/WD-WGSL-20210910.html} +} + +@article{pereyraModelingRayTracing1996, + title = {Modeling, Ray Tracing, and Block Nonlinear Travel-Time Inversion in {{3D}}}, + author = {Pereyra, V.}, + date = {1996-09-01}, + journaltitle = {pure and applied geophysics}, + shortjournal = {PAGEOPH}, + volume = {148}, + number = {3}, + pages = {345--386}, + issn = {1420-9136}, + doi = {10.1007/BF00874572}, + url = {https://doi.org/10.1007/BF00874572}, + urldate = {2021-04-17}, + abstract = {We describe an integrated forward and inverse three-dimensional modeling system that can deal with complex geological structures. The system has been designed to handle large-scale problems by using a distributed approach. It uses seismic ray tracing for forward simulation, time-to-depth mapping, and nonlinear travel-time inversion.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/WJFRXF99/Pereyra - 1996 - Modeling, ray tracing, and block nonlinear travel-.pdf} +} + +@incollection{raoFINITEDIFFERENCEMETHODS2001, + title = {{{FINITE DIFFERENCE METHODS}}}, + booktitle = {Encyclopedia of {{Vibration}}}, + author = {Rao, S. S.}, + editor = {Braun, S.}, + date = {2001-01-01}, + pages = {520--530}, + publisher = {{Elsevier}}, + location = {{Oxford}}, + doi = {10.1006/rwvb.2001.0002}, + url = {https://www.sciencedirect.com/science/article/pii/B0122270851000023}, + urldate = {2021-08-11}, + isbn = {978-0-12-227085-7}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/A68R9DGH/Screenshot 2021-08-11 at 10-14-33 Central Difference - an overview ScienceDirect Topics.png;/Users/niklaskorz/Zotero/storage/ZJFZ46CK/Screenshot 2021-08-12 at 09-58-30 Central Difference - an overview ScienceDirect Topics.png;/Users/niklaskorz/Zotero/storage/PKWSAZXR/B0122270851000023.html} +} + +@article{scheuermannVisualizingNonlinearVector1998, + title = {Visualizing Nonlinear Vector Field Topology}, + author = {Scheuermann, G. and Kruger, H. and Menzel, M. and Rockwood, A.P.}, + date = {1998-04}, + journaltitle = {IEEE Transactions on Visualization and Computer Graphics}, + volume = {4}, + number = {2}, + pages = {109--116}, + issn = {1941-0506}, + doi = {10.1109/2945.694953}, + abstract = {We present our results on the visualization of nonlinear vector field topology. The underlying mathematics is done in Clifford algebra, a system describing geometry by extending the usual vector space by a multiplication of vectors. We started with the observation that all known algorithms for vector field topology are based on piecewise linear or bilinear approximation, and that these methods destroy the local topology if nonlinear behavior is present. Our algorithm looks for such situations, chooses an appropriate polynomial approximation in these areas, and, finally, visualizes the topology. This overcomes the problem, and the algorithm is still very fast because we are using linear approximation outside these small but important areas. The paper contains a detailed description of the algorithm and a basic introduction to Clifford algebra.}, + eventtitle = {{{IEEE Transactions}} on {{Visualization}} and {{Computer Graphics}}}, + keywords = {Algebra,Approximation algorithms,Geometry,Linear approximation,Mathematics,Piecewise linear approximation,Piecewise linear techniques,Topology,Vectors,Visualization}, + file = {/Users/niklaskorz/Zotero/storage/968MGNI6/Scheuermann et al. - 1998 - Visualizing nonlinear vector field topology.pdf;/Users/niklaskorz/Zotero/storage/JQBPFC9R/694953.html} +} + +@report{shirleyRayTracingOne2020, + title = {Ray {{Tracing}} in {{One Weekend}}}, + author = {Shirley, Peter}, + date = {2020}, + url = {https://raytracing.github.io/books/RayTracingInOneWeekend.html}, + urldate = {2021-04-29}, + editorb = {Hollasch, Steve and Black, Trevor David}, + editorbtype = {redactor}, + file = {/Users/niklaskorz/Zotero/storage/NBKG4W5H/RayTracingInOneWeekend.html} +} + +@inproceedings{shoemakeARCBALLUserInterface1992, + title = {{{ARCBALL}}: A {{User Interface}} for {{Specifying Three}}-{{Dimensional Orientation Using}} a {{Mouse}}}, + booktitle = {Proceedings of the {{Conference}} on {{Graphics Interface}} '92}, + author = {Shoemake, Ken}, + date = {1992}, + pages = {151--156}, + abstract = {Arcball is an input technique for 3-D computer graphics, using a mouse to adjust the spatial orientation of an object. In Arcball, human factors and mathematical fundamentals come together exceptionally well. Arcball provides consistency between free and constrained rotations using any direction as an axis; consistent visual input and feedback; kinesthetic agreement between mouse motion and object rotation; and consistent interpretation of mouse position. Attention to mathematical detail facilitates the tasks of users and implementors. Users say that as a general-purpose rotation controller Arcball is easier to use than its nearest rival, the Virtual Sphere. It is also more powerful, and simpler to implement.}, + langid = {english}, + file = {/Users/niklaskorz/Zotero/storage/9LSU59T7/Shoemake - ARCBALL A User Interface for Specifying Three-Dim.pdf} +} + +@incollection{stamRayTracingNonConstant1996, + title = {Ray {{Tracing}} in {{Non}}-{{Constant Media}}}, + booktitle = {Rendering {{Techniques}} ’96}, + author = {Stam, Jos and Languénou, Eric}, + editor = {Pueyo, Xavier and Schröder, Peter}, + date = {1996}, + series = {Eurographics}, + pages = {225--234}, + publisher = {{Springer Vienna}}, + location = {{Vienna}}, + doi = {10.1007/978-3-7091-7484-5_23}, + url = {http://link.springer.com/10.1007/978-3-7091-7484-5_23}, + urldate = {2021-07-25}, + abstract = {In this paper, we explore the theory of optical deformations due to continuous variations of the refractive index of the air, and present several efficient implementations. We introduce the basic equations from geometrical optics, outlining a general method of solution. Further, we model the fluctuations of the index of refraction both as a superposition of blobs and as a stochastic function. Using a well known perturbation technique from geometrical optics, we compute linear approximations to the deformed rays. We employ this approximation and the blob representation to efficiently ray trace non linear rays through multiple environments. In addition we present a stochastic model for the ray deviations derived from an empirical model of air turbulence. We use this stochastic model to precompute deformation maps.}, + isbn = {978-3-211-82883-0 978-3-7091-7484-5}, + langid = {english}, + keywords = {no}, + file = {/Users/niklaskorz/Zotero/storage/IJF3ZLBZ/Stam und Languénou - 1996 - Ray Tracing in Non-Constant Media.pdf} +} + +@inproceedings{vanwijkImplicitStreamSurfaces1993, + title = {Implicit Stream Surfaces}, + booktitle = {Proceedings {{Visualization}} '93}, + author = {van Wijk, J.J.}, + options = {useprefix=true}, + date = {1993-10}, + pages = {245--252}, + doi = {10.1109/VISUAL.1993.398875}, + abstract = {Streamlines and stream surfaces are well known techniques for the visualization of fluid flow. For steady velocity fields, a streamline is the trace of a particle, and a stream surface is the trace of a curve. Here a new method is presented for the construction of stream surfaces. The central concept is the representation of a stream surface as an implicit surface f (x) = C. After the initial calculation of f a family of stream surfaces can be generated efficiently by varying C. The shapes of the originating curves are defined by the value of f at the boundary. Two techniques are presented for the calculation of f: one based on solving the convection equation, the other on backward tracing of the trajectories of grid points. The flow around objects is discussed separately. With this method irregular topologies of the originating curves and of the stream surfaces can be handled easily. Further, it can also be used for other visualization techniques, such as time surfaces and stream volumes. Finally, an effective method for the automatic placement of originating curves is presented.{$<>$}}, + eventtitle = {Proceedings {{Visualization}} '93}, + keywords = {Cities and towns,Equations,Fluid flow,Image converters,Sampling methods,Shape,Streaming media,Topology,Visualization}, + file = {/Users/niklaskorz/Zotero/storage/JIVHKN37/van Wijk - 1993 - Implicit stream surfaces.pdf;/Users/niklaskorz/Zotero/storage/ADPU7MQC/398875.html} +} + +@article{weiskopfGPUBasedNonlinearRay2004, + title = {{{GPU}}-{{Based Nonlinear Ray Tracing}}}, + author = {Weiskopf, Daniel and Schafhitzel, Tobias and Ertl, Thomas}, + date = {2004}, + journaltitle = {Computer Graphics Forum}, + volume = {23}, + number = {3}, + pages = {625--633}, + issn = {1467-8659}, + doi = {10.1111/j.1467-8659.2004.00794.x}, + url = {https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1467-8659.2004.00794.x}, + urldate = {2021-04-17}, + abstract = {In this paper, we present a mapping of nonlinear ray tracing to the GPU which avoids any data transfer back to main memory. The rendering process consists of the following parts: ray setup according to the camera parameters, ray integration, ray-object intersection, and local illumination. Bent rays are approximated by polygonal lines that are represented by textures. Ray integration is based on an iterative numerical solution of ordinary differential equations whose initial values are determined during ray setup. To improve the rendering performance, we propose acceleration techniques such as early ray termination and adaptive ray integration. Finally, we discuss a variety of applications that range from the visualization of dynamical systems to the general relativistic visualization in astrophysics and the rendering of the continuous refraction in media with varying density. Categories and Subject Descriptors (according to ACM CCS): I.3.3 [Computer Graphics]: Picture/Image Generation I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism}, + langid = {english}, + annotation = {\_eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/j.1467-8659.2004.00794.x}, + file = {/Users/niklaskorz/Zotero/storage/DGWHRFNF/Weiskopf et al. - 2004 - GPU-Based Nonlinear Ray Tracing.pdf;/Users/niklaskorz/Zotero/storage/3KYXW4BT/j.1467-8659.2004.00794.html} +} + +@article{zhaoVisualSimulationHeat2007, + title = {Visual {{Simulation}} of {{Heat Shimmering}} and {{Mirage}}}, + author = {Zhao, Ye and Han, Yiping and Fan, Zhe and Qiu, Feng and Kuo, Yu-chuan and Kaufman, Arie E. and Mueller, Klaus}, + date = {2007}, + journaltitle = {IEEE Transactions on Visualization and Computer Graphics}, + shortjournal = {IEEE Trans. Visual. Comput. Graphics}, + volume = {13}, + number = {1}, + pages = {179--189}, + issn = {1077-2626}, + doi = {10.1109/TVCG.2007.24}, + abstract = {We provide a physically-based framework for simulating the natural phenomena related to heat interaction between objects and the surrounding air. We introduce a heat transfer model between the heat source objects and the ambient flow environment, which includes conduction, convection and radiation. The heat distribution of the objects is represented by a novel temperature texture. We simulate the thermal flow dynamics that models the air flow interacting with the heat by a hybrid thermal lattice Boltzmann model (HTLBM). The computational approach couples a multiple-relaxation-time LBM (MRTLBM) with a finite difference discretization of a standard advectiondiffusion equation for temperature. In heat shimmering and mirage, the changes in the index of refraction of the surrounding air are attributed to temperature variation. A nonlinear ray tracing method is used for rendering. Interactive performance is achieved by accelerating the computation of both the MRTLBM and the heat transfer, as well as the rendering on contemporary graphics hardware (GPU).}, + langid = {english}, + keywords = {yes}, + file = {/Users/niklaskorz/Zotero/storage/8E7VKXF4/Zhao et al. - 2007 - Visual Simulation of Heat Shimmering and Mirage.pdf} +} + + diff --git a/report/Practical.tex b/report/Practical.tex new file mode 100644 index 0000000..4525fb7 --- /dev/null +++ b/report/Practical.tex @@ -0,0 +1,198 @@ +\documentclass{mimosis} +\KOMAoptions{twoside=false} +% \PassOptionsToClass{14pt}{scrbook} +\usepackage{metalogo} + +\usepackage{textcomp} +\usepackage{gensymb} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Some of my favorite personal adjustments +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% These are the adjustments that I consider necessary for typesetting +% a nice thesis. However, they are *not* included in the template, as +% I do not want to force you to use them. + +% This ensures that I am able to typeset bold font in table while still aligning the numbers +% correctly. +\usepackage{etoolbox} + +\usepackage[binary-units=true]{siunitx} +\DeclareSIUnit\px{px} + +\sisetup{% + detect-all = true, + detect-family = true, + detect-mode = true, + detect-shape = true, + detect-weight = true, + detect-inline-weight = math, +} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Hyperlinks & bookmarks +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\usepackage[% + colorlinks = true, + citecolor = Black, + linkcolor = Black, + urlcolor = Black, + ]{hyperref} + +\usepackage{bookmark} +\usepackage[capitalise]{cleveref} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Bibliography +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% I like the bibliography to be extremely plain, showing only a numeric +% identifier and citing everything in simple brackets. The first names, +% if present, will be initialized. DOIs and URLs will be preserved. + +\usepackage[% + autocite = plain, + backend = biber, + doi = true, + url = true, + giveninits = true, + hyperref = true, + maxbibnames = 99, + maxcitenames = 2, + sortcites = true, + style = alphabetic, + citestyle = alphabetic, + backref = true, + ]{biblatex} + + +\input{bibliography-mimosis} +\bibliography{Practical} +\bibliography{Streaming} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Fonts +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\usepackage{mathpazo} +\usepackage{lettrine} + +\setmainfont{XCharter} +\setsansfont{OpenSans}[ + Path = fonts/, + Extension = .ttf, + UprightFont = *-Regular, + ItalicFont = *-RegularItalic, + BoldFont = *-SemiBold, + BoldItalicFont = *-SemiBoldItalic +] +\setmonofont{Inconsolata}[ + Path = fonts/, + Extension = .ttf, + UprightFont = *-Regular, + BoldFont = *-Bold, +] + + +\usepackage{makeidx} +\makeindex + +\newacronym[description={Principal component analysis}]{PCA}{PCA}{principal component analysis} +\newacronym {SNF}{SNF}{Smith normal form} +\newacronym[description={Topological data analysis}] {TDA}{TDA}{topological data analysis} + +%\makeindex +\makeglossaries + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Incipit +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\newcommand*{\titleGP}{\begingroup % Create the command for including the title page in the document +\centering % Center all text +\vspace*{\baselineskip} % White space at the top of the page + +%\rule{\textwidth}{1.6pt}\vspace*{-\baselineskip}\vspace*{2pt} % Thick horizontal line +%\rule{\textwidth}{0.4pt}\\[1.0\baselineskip] % Thin horizontal line + +{\huge Interactive Exploration of Nonlinear Ray Casting}\\[0.2\baselineskip] % Title + +%\rule{\textwidth}{0.4pt}\vspace*{-\baselineskip}\vspace{3.2pt} % Thin horizontal line +%\rule{\textwidth}{1.6pt}\\ % Thick horizontal line + +\vspace*{\baselineskip} + +{\Large Advanced Software Practical\\[\baselineskip]} % Tagline(s) or further description +\vspace*{\baselineskip} + +{\LARGE Niklas Korz\\[\baselineskip]} % Editor list + +\vspace*{\baselineskip} % Whitespace between location/year and editors + +Supervisor\\ +{\large Prof. Dr. Filip Sadlo\\[\baselineskip]} % Editor list + +\vfil + +Heidelberg, \today \par % Location and year + +\vspace*{\baselineskip} + +{\itshape Faculty of Mathematics and Computer Science\par} % Editor affiliation +{\itshape Heidelberg University\par} % Editor affiliation + +\endgroup} + + +\usepackage{mathtools} +\usepackage{amssymb} +\usepackage{siunitx} + +\usepackage{blindtext} + +% Corrects \autoref{}: chapter -> Chapter, section -> Section, subsection -> Section +\addto\extrasenglish{% + \renewcommand{\chapterautorefname}{Chapter}% + \renewcommand{\sectionautorefname}{Section}% + \renewcommand{\subsectionautorefname}{Section}% +} + +\begin{document} + +\frontmatter +\thispagestyle{empty} + \titleGP + \cleardoublepage + \pagestyle{empty} + \include{Sources/0-1-DeclarationOfAuthorship} + \include{Sources/0-2-Abstract} + \tableofcontents + +\mainmatter + \pagestyle{scrheadings} + + \include{Sources/1-Introduction} + \include{Sources/2-Approach} + \include{Sources/3-Results} + \include{Sources/4-Conclusion} + +% This ensures that the subsequent sections are being included as root +% items in the bookmark structure of your PDF reader. +\bookmarksetup{startatroot} +\backmatter + + % \begingroup + % \let\clearpage\relax + % \glsaddall + % \printglossary + % \endgroup + + \printindex + \label{sec:index} + + \printbibliography + +\end{document} \ No newline at end of file diff --git a/report/Sources/0-1-DeclarationOfAuthorship.tex b/report/Sources/0-1-DeclarationOfAuthorship.tex new file mode 100644 index 0000000..8bc06d5 --- /dev/null +++ b/report/Sources/0-1-DeclarationOfAuthorship.tex @@ -0,0 +1,6 @@ +\section*{Declaration of Authorship} + +I hereby declare that the software practical submitted is my own unaided work. All direct or indirect sources used are acknowledged as references. The principles and recommendations \enquote{Verantwortung in der Wissenschaft} of Heidelberg University have been followed. +\vspace{5cm}\\ +\noindent\rule[0.5ex]{8em}{0.5pt} \hfill \rule[0.5ex]{10em}{0.5pt}\\ +\noindent city and date \hfill signature \ No newline at end of file diff --git a/report/Sources/0-2-Abstract.tex b/report/Sources/0-2-Abstract.tex new file mode 100644 index 0000000..df8f2de --- /dev/null +++ b/report/Sources/0-2-Abstract.tex @@ -0,0 +1,29 @@ +\begin{center} + \textsc{Abstract} +\end{center} +% +\noindent In this advanced software practical, the field of nonlinear ray casting is investigated through the development of a sandbox application. +The technical implementation is based on the memory safe Rust programming language and the upcoming WebGPU graphics standard. +The path of rays inside the sandbox is determined by user defined field functions that are evaluated using Runge-Kutta integration. +Additionally to the nonlinear ray casting view, the path of rays can be visualized as an outline mesh in a linearly rendered reference view. +As scene, the Cornell box is used, which consists of two differently sized cuboids in a cubic room. +Several predefined functions are included from which the user can choose: four mirage functions which simulate continuous refraction in heated air, two translation functions that bend the rays in a certain direction, a rotation function and the Lorenz and Rössler attractors. +The influence of the field on the rays can be controlled through a field weight parameter. +By using Lyaponov exponents, areas of different behavior can be highlighted, either as an overlay on the ray casting view or as an outline mesh in the reference view. + +\begin{center} + \textsc{Zusammenfassung} +\end{center} +% +\selectlanguage{ngerman} +\noindent In diesem Fortgeschrittenenpraktikum wird das Feld des nichtlinearen Ray Castings anhand der Entwicklung einer Sandbox-Anwendung untersucht. +Die technische Umsetzung basiert dabei auf der speichersicheren Programmiersprache Rust und dem kommenden WebGPU-Grafikstandard. +Die Pfade der Rays innerhalb der Sandbox werden durch nutzerdefinierte Feldfunktionen bestimmt, die mit Runge-Kutta-Integration ausgewertet werden. +Zusätzlich zum nichtlinearen Ray-Casting-View können die Raypfade als Outline-Mesh in einem linear gerenderten Referenz-View dargestellt werden. +Als Szene wird die Cornell Box genutzt, welche aus zwei verschiedengroßen Quadern in einem würfelförmigen Raum besteht. +Mehrere vordefinierte Funktionen sind enthalten, aus denen die Nutzer wählen können: vier Fata-Morgana-Funktionen, die kontinuierliche Brechung in heißer Luft simulieren, zwei Translation-Funktionen, die die Rays in eine bestimmte Richtung ablenken, eine Rotationsfunktion sowie Lorenz- und Rössler-Attraktoren. +Der Einfluss des Felds kann dabei durch einen Feldgewichtungsparameter reguliert werden. +Durch den Einsatz von Lyapunov-Exponenten können Bereiche unterschiedlichen Verhaltens hervorgehoben werden, entweder als Overlay auf dem Ray-Casting-View oder als Outline-Mesh auf dem Referenz-View. + +\selectlanguage{english} + diff --git a/report/Sources/1-Introduction.tex b/report/Sources/1-Introduction.tex new file mode 100644 index 0000000..0e8554f --- /dev/null +++ b/report/Sources/1-Introduction.tex @@ -0,0 +1,113 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\chapter{Introduction} + +\section{Motivation} + +Light is commonly assumed to travel linearly from source to destination. +There are however cases where the path of light can be bent or distorted. +In the case of black holes for example, the light is attracted by a very strong gravitational center. +Heated air can change the direction of light through the varying refraction caused by the temperature transition from heat source to environment. +To create an interactive environment for exploration of such phenomena may help in understanding the images they bring to life. +In visual simulations, realistic graphics can be achieved through ray tracing, where the paths of light towards the camera are backtracked towards the light source, incorporating occlusions and reflections along the way. +This usually assumes the light rays to have linear paths. +Analyzing the effects of nonlinear light rays on the final visual outcome requires continuous evaluation of the forces that affect the rays. +To be able to experiment with the effects a vector field function can have on visuals, a sandbox application is developed that allows evaluation of user-specified field functions and renders them through nonlinear ray casting. + +\section{Related Work} + +In his paper \enquote{Nonlinear ray tracing: visualizing strange worlds}, Gröller~\cite{grollerNonlinearRayTracing1995} investigates the visualisation of three-dimensional scenes in which light does not travel in a linear way but is affected by surrounding forces. +The paper investigates ray casting with gravity centers and gravity lines, the chaotic dynamical Lorenz and Rössler systems as well as parametric curved rays, that is, parametric functions of which the entire path is known in advance. +Two data structures are introduced, an iterative ray representation using line segments where the segment length can either be uniform or adaptive, and a hierarchical ray representation based on a binary tree of bounding boxes. +Based on these data structures, three algorithms are discussed: +The \enquote{sub/iter} algorithm makes use of the iterative ray representation with uniform subdivision. +Based on this, the \enquote{bvh/iter} algorithm additionally stores the objects of the scene in a binary hierarchical bounding volume structure for faster intersection tests. +The \enquote{bvh/hier} algorithm assumes the ray paths to be defined by a parametric function, allowing the storage of these curved rays in a non-overlapping binary tree. +The scene objects are then stored in a possibly overlapping binary hierarchical bounding volume structure. +While the object structure is precomputed, the curved ray tree is constructed as needed. +Only if nodes of the two structures overlap, intersection between the curved ray and the object will be tested, avoiding intersection tests for objects that are not even close to a ray's current position. +Gröller's approach does not consider shadows as finding a ray that connects two points in a nonlinear system is very complex, especially as there is no guarantee that such a connection even exists. +For illumination in general, Gröller simply assumes that light particles are massless until they hit an object, thus circumventing the problem of finding a nonlinear connection between the intersection point and the light source. +There is no possibility to interactively explore the rendered scenes or visualize the paths the rays follow through the field to help in understanding the final image. + +Zhao et al.~\cite{zhaoVisualSimulationHeat2007} present a physically-based framework for simulating the visual effects of heated air. +The simulation models the heat-transfer between heat source objects and the environment with support for conduction, convection and radiation. +A novel temperature texture is used for storing the heat distribution and making it available to the GPU. +The rendering is performed as ray tracing on a GPU as a general purpose computation (GPGPU), using an iterative approach with a small step size when a ray is traversing the heat volume. +The air refraction is computed per iteration using Snell's law, where the refraction index is derived from the air temperature. +While the scenes are rendered in real time on the GPU and thus allow for interaction, there is no alternative representation of the ray paths, thus making it harder to understand how the final image comes into existence. + +\chapter{Technical Background} + +The project is based on the upcoming WebGPU graphics standard and the memory safe Rust programming language, which will be discussed in the following sections. + +\section{WebGPU} + +WebGPU~\cite{malyshauWebGPU2021} is an upcoming standard for computer graphics by the World Wide Web Consortium~(W3C). +Unlike its OpenGL-based predecessor WebGL, WebGPU's design is based on and targets a family of newer graphics APIs: Vulkan, Metal and Direct3D~12. +The primary difference between OpenGL and the more modern APIs is the explicit management of state and resources. +While OpenGL relies on a globally exposed state machine, state in WebGPU and the APIs it is based on has to be stored and passed to the relevant API calls by the developer. +Unlike Vulkan, the most verbose of the three modern APIs, WebGPU abstracts some concepts such as memory management or validation. +As WebGPU is not only targeting native platforms but the web in particular, it is part of its security model that invalid API calls cannot reach the underlying native APIs, with the intention of preventing undefined behavior. +These abstractions overall make it easier to work with WebGPU than with other modern APIs while still benefiting from the explicit state management. + +To emphasize the differences, consider the simple example of drawing a single triangle. +In modern OpenGL, the first step is to generate and bind a vertex buffer object and a vertex array object. +We then pass the points of the triangle to the GPU which allocates GPU memory bound to the vertex buffer object and writes the data. +The vertex array object describes what will be passed to our shader during rendering and references the vertex buffer object. +While the vertex buffer object just contains the raw data, the vertex array object holds information on how this data is structured, for example, that it contains three-component vectors with a 32-bit floating point data type. +Before being able to draw this data, a GLSL shader program must be compiled and linked. +A shader program consists of a vertex and a fragment shader, the two mandatory programmable stages of the graphics pipeline. +Submitting this configuration to the GPU for drawing is rather straightforward. +First, we set a color to be used as base color (or \emph{clear color}) and command OpenGL to clear the color buffer so we have a fresh canvas to draw our triangle on. +Then, we bind the linked shader program and the generated vertex array object. +Finally, we command OpenGL to draw a triangle using the first three points in the vertex buffer object of the currently bound vertex array object. +A common pattern can be noticed in this workflow: before the GPU can work on a resource, it has to be \emph{bound} or \emph{used}. +Allocating data and writing to it requires generating and binding a vertex buffer object. +Drawing requires using a shader program and binding a vertex array object. +All of this ends up as global state in OpenGL. +Furthermore, OpenGL never explicitly made us choose which GPU should be used, making it harder to select the proper device on multi GPU systems. + +In WebGPU, we first have to request an \emph{adapter}, which may be a physical adapter such as a GPU or a software renderer~\cite{hansenLearnWgpu2021}. +From this adapter, a logical \emph{device} is created which manages all resources requested by the application. +Buffers, textures and other resources must be created through this logical device. +All information relevant for rendering such as shaders, vertex layouts or uniforms is contained in a \emph{render pipeline}, which is again created through the logical device. +Unlike in OpenGL, render pipelines are not bound in any global state. +Instead, the pipeline is passed to a \emph{render pass} created by a \emph{command encoder}. +To finally be able to draw, the result of this command encoder is passed to a \emph{queue} managed by the logical device. +This queue is then processed by the GPU in the background and the application can continue doing work on the CPU. +Synchronization is handled transparently as well. +While explicit APIs such as Vulkan require barriers to prevent read-write-conflicts, WebGPU automatically detects if a render pass reads from a buffer that may be written by a different pass and postpones its execution. +Compute programs on WebGPU follow a similar path, using \emph{compute pipelines} and \emph{compute passes} instead. + +As WebGPU targets multiple native APIs, shaders have to be translated to either SPIR-V~(Vulkan), MSL~(Metal) or HLSL~(Direct3D~12) accordingly. +To that end, the W3C specifies a new shading language, the WebGPU Shading Language~(WGSL)~\cite{netoWebGPUShadingLanguage2021}. +The most notable differences between GLSL and WGSL besides the different syntax are the ability to implement multiple shader stages in the same file and the idiom of passing attributes and results as function parameters and return types of the shader entrypoint functions. + +The implementation of the WebGPU standard is mainly driven by wgpu\footnote{\url{https://github.com/gfx-rs/wgpu} (accessed September 20, 2021)} used in web browser Mozilla Firefox and Dawn\footnote{\url{https://dawn.googlesource.com/dawn} (accessed September 20, 2021)} used in Google Chrome. +While Dawn is written in the systems programming language C++ commonly used in computer graphics, wgpu employs the younger memory-safe systems programming language Rust that has already been used in other parts of Mozilla Firefox. +While WebGPU is primarily designed to be used in web applications through the JavaScript programming language, it can be used in native applications outside the browser by using one of the two native implementations directly. +With the goal of attracting developers of native applications, the wgpu project offers an idiomatic version of its API for users of the Rust programming language. + +\section{Rust} + +The Rust programming language belongs to the family of systems programming languages, which is targeted at the development of performance critical application such as operating systems, device drivers, databases, games or scientific simulations~\cite{blandyProgrammingRust2021}. +The most prominent members of this family are the C and C++ programming languages, which make it easy to introduce undefined behavior, that is, usage of the programming language for which the language standard does not formally define the outcome. +An example of such undefined behavior is the access of array indices beyond an array's capacity or the freeing of already freed memory. +Such cases are covered by the restrictiveness of the Rust compiler, which among others performs array boundary checks, and most importantly the Rust ownership model and its borrow checker. +While other languages try to solve the problem of memory leaks by using garbage collectors, which are mechanisms in a programming language's runtime that frequently check if a certain memory area is still referenced by any variables, the Rust ownership model ensures that the pointer to a specific memory area is held by only one variable. +The ownership of such memory can moved between scopes, but can only ever be held by one scope at the same time. +When the owner is \textit{dropped}, for example, when it goes out of scope, the memory is freed. +To be able to access this memory by multiple functions at the same time, Rust supports the concept of references, similar to C++. +Unlike C++ though, references cannot outlive the owner's scope or lifetime and only one reference with write access, called a mutable reference, can exist at the same time. +By ensuring a variable's memory can only be written to from one specific location at any time, Rust solves the problem of data races, which are particularly interesting for concurrent programming. +However, Rust also includes synchronization primitives such as mutexes or channels. +These use \enquote{unsafe} implementations internally, but make promises to the user that ensure undefined behavior can never occur. +Rust also allows optional access to the same memory from different locations by using reference counted smart pointers. +They are similar to C++ shared pointers, but come with an important difference. +In Rust, reference counted smart pointers can also hold immutable data. +For mutable data, the additional data type of the reference counted cell allows taking mutable and immutable references to the data, but will enforce the borrow checking rules at runtime. + +Rust targets a wide array of native platforms as it is based on the LLVM\footnote{\url{https://llvm.org/} (accessed October 19, 2021)} compiler infrastructure. +For WebGPU, a particularly interesting target is WebAssembly, an intermediate binary format that allows execution of code on the web not written in JavaScript which is compiled to a platform's native code at runtime by the browser~\cite{mdncontributorsCompilingRustWebAssembly2021}. +Rust programs can be compiled directly to WebAssembly through the Rust build toolchain, and can even access and expose functions to JavaScript, making it possible to use any of the available Web APIs in a Rust program. +Running Rust WebGPU programs natively on the desktop and on the web through WebAssembly is officially supported by the wgpu project~\cite{malyshauRunningWebWebGPU2021}. diff --git a/report/Sources/2-Approach.tex b/report/Sources/2-Approach.tex new file mode 100644 index 0000000..154c72e --- /dev/null +++ b/report/Sources/2-Approach.tex @@ -0,0 +1,218 @@ +\chapter{Approach} + +\begin{figure}[!t] + \centering + \includegraphics[width=0.75\linewidth]{figures/2021-05-05.png} + \caption{In the beginning there was linearity.} + \label{fig:simple-cornell-box} +\end{figure} + + +\noindent Before non-linear ray casting will be investigated, a simple linear ray caster is established as a foundation. +By using compute shaders, the scheduling and coordination of work on the GPU can be coordinated rather easily. +Although compute shaders are able to write to textures and the screen's current texture can be accessed for rendering, at the time of writing, the screen's texture only applies the render attachment usage flag, which means that only render passes can write to it~\cite{malyshauWebGPU2021}. +Therefore, a render pass has to be used to present a compute shader's result to the screen. +For this, a proxy geometry is used that covers the whole screen, that is, two triangles that form a quad. +A texture with the screen's dimensions is bound to the compute pass for writing and to the render pass for reading. +The texture is read from in the render pass's fragment shader, thus making the compute shader's result available to the user. +To render the scene, a ray is cast from the camera center through every pixel of the screen~\cite{shirleyRayTracingOne2020}. +The color of a ray's pixel is then determined by calculating intersections of the ray with objects in the scene. +If no transparency or light are involved, the pixel's color is simply the color of the intersection closest to the camera. +In case of meshes consisting of triangles, the intersection tests can be performed using the ray-triangle intersection algorithm by Möller and Trumbore~\cite{mollerFastMinimumStorage1997}. +A simple scene commonly used for testing 3D graphics rendering is the Cornell Box\footnote{\url{http://www.graphics.cornell.edu/online/box/data.html} (accessed May 1, 2021)}. +It consists of two differently sized boxes in a cube shaped room of which the front is open so the camera can see inside. +For initial testing, it is sufficient to hardcode the triangle meshes inside the compute shader and iterate over each triangle to test for intersections with the ray. +The color of the closest intersection is then written to the storage texture, which is presented through the additional render pass. +To make it easier to tell the boxes apart from the walls without using lighting, the surface normals are used as colors~(\cref{fig:simple-cornell-box}). +Allowing the user to interactively navigate the scene is useful for quickly testing the rendering of a scene from different positions and angles. +While video games usually resolve to first person or third person cameras to give a sense of immersion, the arc ball camera by Shoemake~\cite{shoemakeARCBALLUserInterface1992} makes it possible to rotate and move the scene as a whole. +For Rust, an implementation of this technique\footnote{\url{https://github.com/Twinklebear/arcball} (accessed May 6, 2021)} exists. +The Rust arcball implementation can be incorporated into the described WebGPU ray caster by extracting the relevant camera parameters (origin, forward direction and upward direction) and using them instead of the hardcoded parameters in the compute shader when calculating the ray directions. +To be able to pass these parameters to the shader, uniform buffers have to be used. +The mouse input events on the window are passed directly to the camera handler, which then adjusts the camera parameters accordingly. +The scene can now be moved, rotated and zoomed. +Although the surface normals make it possible to tell the surfaces apart to some degree, surfaces with similar normals will receive the same colors and thus might appear as one if they are too close together, depending on the camera perspective. +The Blinn-Phong illumination model~\cite{blinnModelsLightReflection1977} is a rather simple way of introducing lighting into a scene and helps with the distinction of such surfaces. +Finally, to be able to load more scenes than the Cornell Box, the hardcoded meshes are replaced by two storage buffers: a vertex buffer that contains the position vectors of all vertices inside the scene and a face buffer that contains the indices of vertices that form a triangle. +A simple file format for 3D models that has wide support by 3D modelling applications is the Wavefront OBJ\footnote{\url{https://www.loc.gov/preservation/digital/formats/fdd/fdd000507.shtml} (accessed October 11, 2021)} format. +Loader implementations for this format already exist in the Rust ecosystem, such as the \texttt{tobj}\footnote{\url{https://github.com/Twinklebear/tobj} (accessed May 13, 2021)} library. +When dragging a file on the application window, the file's content is parsed by \texttt{tobj} and the vertices and indices are written to the respective buffers on the GPU. +This concludes the linear foundation of the ray caster, which includes arcball camera controls, Blinn-Phong illumination and loading of Wavefront OBJ models~(\cref{fig:linear-ray-caster}). + +\begin{figure}[!t] + \centering$ + \begin{array}{cc} + \includegraphics[width=0.45\linewidth]{figures/2021-05-16.png} & + \includegraphics[width=0.45\linewidth]{figures/2021-05-16-suzanne.png} + \end{array}$ + \caption{A basic WebGPU ray caster with arcball camera controls, Blinn-Phong illumination and loading of external models.} + \label{fig:linear-ray-caster} +\end{figure} + +On top of this linear foundation, a nonlinear ray caster can be built by extending the compute shader. +The goal of this nonlinear ray caster is to evaluate the path of a ray inside a vector field, defined by a vector field function inside the shader. +For this, the field function must be evaluated multiple times as the ray is traversed to determine the next direction of the ray. +Intersection tests are then performed between these integration steps by checking for intersections along a linear path from one ray position to the next. +If an intersection is found, the iteration of ray steps is stopped. +A finite amount of steps must be defined to prevent the integration from becoming an infinite loop. +Choosing this limit depends on the integration step size and the hardware the program is running on. +To improve integration accuracy, fourth order Runge-Kutta is used. +Applying a gravity center function similar to the one used by Gröller~\cite{grollerNonlinearRayTracing1995} results in a noticeable distortion towards the gravity center as can be seen in \cref{fig:gravity-center}. + +\begin{figure}[!t] + \centering + \includegraphics[width=0.75\linewidth]{figures/2021-05-25.png} + \caption{Nonlinear ray casting using fourth order Runge-Kutta and a gravity center function.} + \label{fig:gravity-center} +\end{figure} + +Interactive experimentation requires the user to be able to insert custom functions into the application. +As WGSL shaders are compiled from string source during runtime, this can be achieved by interpolating the string of the field function into the ray casting compute shader. +To allow editing the field function graphically inside the application, a text input has to be rendered and keyboard events have to be processed. +The egui\footnote{\url{https://github.com/emilk/egui} (accessed May 27, 2021)} library is able to handle input events in Rust windows and can render to wgpu textures. +Next to text areas, egui also supports buttons, drop downs, checkboxes and image views. +To make egui play nicely with the existing application, the ray caster texture is now displayed through an egui image view that is also responsible for handling the mouse input of the ray caster view. +Giving egui the sovereignty over all user input to the application window has the benefit of automatic event delegation depending on which part of the window the user has clicked on or is hovering over with the mouse cursor. +Additionally, egui abstracts mouse and touch events so that the ray caster camera controls will also work if the application is run on a tablet with a touch screen. +When the user makes changes to the field function through the text area, the new field function source is interpolated into the ray caster compute shader. +The changed shader is then compiled and used to create a new compute pipeline. +The shader translation library naga used in wgpu is very fast~\cite{malyshauShaderTranslationBenchmark2021}, which makes it suitable for hot reloading shaders. +In his paper on nonlinear ray tracing, Gröller~\cite{grollerNonlinearRayTracing1995} applies field functions of chaotic systems, such as the Lorenz or Rössler attractors. +The direction of a particle in these fields only depends on the current position and a set of predefined constant parameters. +Once a ray has entered the scene, its previous direction would be ignored as the new direction does not depend on it. +By introducing a new parameter, the \textit{field weight}, the effect of the field on a ray's direction can be controlled. +The user can control this parameter through a graphical range slider that starts at zero percent (field has no effect) and ends at hundred percent (field has full control). +The field weight is then used for linear interpolation between the result of the field function and the ray's previous direction. + +\begin{figure}[!t] +\centering +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-06-20-p005.png} + \caption{Ray wavefronts for translation field function.} + \label{fig:reference-view-2d-translation} +\end{subfigure} +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-06-20-rotation.png} + \caption{Ray wavefronts for rotation field function.} + \label{fig:reference-view-2d-rotation} +\end{subfigure} + \caption{A two-dimensional reference view for visualizing ray paths as wavefronts.} + \label{fig:reference-view-2d} +\end{figure} + +To give a better understanding of how the rays travel along the scene, the paths of selected rays are recorded. +By sampling the position's of these rays at regular intervals and drawing them into a two-dimensional texture, the paths can be observed in the form of a wavefront. +The two-dimensional texture of this reference view is then presented through egui using an image view (\cref{fig:reference-view-2d-translation}). +As long as the selected rays travel mostly along an $x$-$y$-plane, the user can easily understand how the ray cast image is generated. +For three-dimensional fields that do not primarily stay on the same $x$-$y$-plane, such as the chaotic systems used by Gröller~\cite{grollerNonlinearRayTracing1995} or a function that applies rotations to the vectors (\cref{fig:reference-view-2d-rotation}), the paths are harder to comprehend. +Thus, a three-dimensional reference view with camera controls is needed (\cref{fig:ray-arrow-glyphs}). +As this reference view only needs to visualize the sampled ray positions in a linear three-dimensional space, rasterization through render passes can be used. +The mesh of the arrow glyph that will represent the ray position samples can be drawn multiple times through instancing. +That way, only a minimum of memory transfer between CPU and GPU is needed. +The positions of selected rays are sampled inside the compute shader and stored inside a buffer. +This buffer is then applied to the instanced drawing so that the glyph is drawn once for every sample and each run of the vertex shader has access to the sample position, which is then applied as translation to the vertices. +The camera controls reuse the arcball camera, but instead of extracting the camera parameters, a projection matrix is computed from the camera and applied to the vertices inside the vertex shader. +\begin{figure}[!t] + \centering + \includegraphics[width=0.5\linewidth]{figures/2021-06-30-glyphs.png} + \caption{A three-dimensional reference view using arrow glyphs for visualisation of ray paths.} + \label{fig:ray-arrow-glyphs} +\end{figure} +The arrow glyph approach however does not emphasize which samples belong to the same ray. +While the user might be able to determine that two glyphs that are spatially close to one another belong to the same ray, especially field functions with large gradients may not allow such a visual connection. +Thus, another approach to ray path visualization is introduced. +Instead of drawing multiple instanced arrow glyphs in the reference view, a multicolored three-dimensional mesh is constructed (\cref{fig:reference-view-3d-mesh-full}). +This mesh is sampled from eight rays on the outline of the camera's view, that is, the four corner points and the middle points between them. +Each ray is assigned a different color in the mesh, therefore visualizing how the individual rays of the mesh are transformed along the way. +The index buffer for this triangular mesh can be precomputed once as each ray will sample a predefined amount of positions. +Only the positions inside the vertex buffer are changed. +The vertex buffer is then filled by the compute pass of the ray cast view and subsequently drawn by the render pass of the reference view. +An optional wireframe mode further emphasizes the sampled rays as lines while preserving the overall mesh structure (\cref{fig:reference-view-3d-mesh-wireframe}). + +\begin{figure}[!t] +\centering +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-07-14.png} + \caption{Camera outline mesh in filled mode.} + \label{fig:reference-view-3d-mesh-full} +\end{subfigure} +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-07-14-wireframe.png} + \caption{Camera outline mesh in wireframe mode.} + \label{fig:reference-view-3d-mesh-wireframe} +\end{subfigure} + \caption{A three-dimensional reference view using a camera outline mesh for visualisation of ray paths.} + \label{fig:reference-view-3d-mesh} +\end{figure} + +A more practical application of non linear ray casting is the simulation of mirages. +Mirages can be expressed as field functions by computing the refraction between two points, that is, the previous and the current position of the ray. +In combination with Runge-Kutta, this can approximate the continuous refraction inside a medium, such as heated air. +As simplification, the heat spread of air is considered to be linear on a maximum distance defined inside the field function. +For a heat source with spherical heat spread, the temperature is given by the distance from the current position towards the center of the heat source and for a plane heat source by the point-plane-distance. +The temperature at a certain position is then calculated by linear interpolation between environmental temperature and the temperature at the heat source. +For a temperature $T$, the refraction index of air is given as +\begin{equation} + n = \frac{0.0000104 \cdot P \cdot (1 + P \cdot (60.1 - 0.972 \cdot T) \cdot 10^{-10})}{1 + 0.00366 \cdot T} , +\end{equation} +where $P = 101325 \text{ Pa}$ is the nominal air pressure at sea level for $15$ degrees Celsius \cite{zhaoVisualSimulationHeat2007}. +In the case of mirages, the camera outline mesh becomes less useful, as the rays on the outline may not be affected by the heat fields at all. +Instead of rendering the outline of the camera view, the outline mesh of a selected area of the ray cast view can be visualized so that the user is able to pick points of interest that are visually distorted, such as the mirages inside the heat field. +When the user clicks on a pixel inside the ray cast view, rays for eight neighboring pixel with a predefined distance from the chosen pixel are sampled, forming a mesh similar to the camera outline constructed before. +For areas on the border of a mirage, this emphasizes how the surrounding rays travel into different direction. +When all sampled rays lie inside the mirage, on the other hand, the mesh shows how the resulting image is distorted and stretched by the heat (\cref{fig:mirage-spherical-linear}). +\begin{figure}[!t] + \centering + \includegraphics[width=0.75\linewidth]{figures/2021-08-04-spherical.png} + \caption{A mirage in a spherical heat field visualized by the outline of rays surrounding a chosen pixel.} + \label{fig:mirage-spherical-linear} +\end{figure} +The heat field itself can be further highlighted by extracting Lyapunov exponents and generating an overlay from them. +To be able to extract the Lyapunov exponents for the ray cast view, the end position of each camera ray has to be stored inside the compute shader. +Then, the gradient is constructed for each pixel by taking the central differences in $x$- and $y$-direction. +The transpose of the gradient is multiplied with the gradient itself, resulting in a square matrix from which two eigenvalues are extracted. +The Lyapunov exponent is then given as the square root of the larger eigenvalue. +For the overlay, the Lyapunov exponent is scaled through an exponential function and filtered for large values, which are then drawn on top of the ray cast view in white with the scaled exponent as opacity (\cref{fig:lyapunov-exponent-overlay-sharp}). +By increasing the delta used for computing the central differences, the overlay can optionally be smoothed (\cref{fig:lyapunov-exponent-overlay-smooth}). +\begin{figure}[!t] +\centering +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-08-19.png} + \caption{Using a central difference delta of $1$.} + \label{fig:lyapunov-exponent-overlay-sharp} +\end{subfigure} +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-08-19-smooth.png} + \caption{Using a central difference delta of $10$.} + \label{fig:lyapunov-exponent-overlay-smooth} +\end{subfigure} + \caption{Lyapunov exponent overlay for visualizing diverging ray paths.} + \label{fig:lyapunov-exponent-overlay} +\end{figure} +Similar to the camera outline mesh before, a mesh can be constructed for the outline of the Lyapunov overlay by extracting a predefined amount of outermost points, which are then sampled to retrieve the vertices for the outline mesh. + +As the application is designed for interactive usage, the ray casting must be able to render frames in an adequate time. +To keep frame time low, a relatively large step size must be chosen for Runge-Kutta. +However, this step size must still be small enough so that the final result is very close to a frame rendered with a much smaller step size. +For testing purposes, a high accuracy mode is introduced that re-renders the ray cast view with the same parameters and a small step size of $h = 0.001$. +This high accuracy mode can be triggered through a button in the graphical user interface. +Changing any parameters, including the camera perspective, switches the frame back to normal accuracy. +Usage of the high accuracy mode revealed an incorrectness in the Runge-Kutta integration for the mirage functions. +\begin{figure}[!t] +\centering +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-09-14-linear-main.png} + \caption{Using a large step size $h = 0.1$.} +\end{subfigure} +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-09-14-linear-high-accuracy-main.png} + \caption{Using a small step size $h = 0.001$.} +\end{subfigure} + \caption{Comparison of an incorrectly integrated mirage function with different step sizes.} + \label{fig:incorrect-mirage-comparison} +\end{figure} +As can be seen in \cref{fig:incorrect-mirage-comparison}, rendering with a large step size results not only in vastly different mirages but also introduces a circle in the center that looks as if the sphere contained two entirely different fields. +This was caused by a misconfiguration of parameters passed to the functions of the Runge-Kutta integration. +Additionally to the linear heat spread functions, variants with sigmoid heat spread are implemented for both the spherical and the plane heat source to simulate a smoother transition between heat source and environmental temperature. +Although the large step size generally looks more correct now, it still leads to some minor flaws for high gradients. +By applying the smaller step size of $h = 0.001$ when a large gradient is detected and switching back to $h = 0.1$ once the gradient is small enough again, the application achieves a nice compromise between interactivity and accuracy. diff --git a/report/Sources/3-Results.tex b/report/Sources/3-Results.tex new file mode 100644 index 0000000..3fe0325 --- /dev/null +++ b/report/Sources/3-Results.tex @@ -0,0 +1,63 @@ +\chapter{Results and Discussion} + +\begin{figure}[!t] + \centering + \includegraphics[width=0.98\linewidth]{figures/2021-10-05-sigmoid.png} + \caption{The final nonlinear ray casting application showing results of a spherical mirage function with sigmoid heat spread.} + \label{fig:final application} +\end{figure} + +The final application is a sandbox for analyzing visual phenomena occurring in user provided vector fields (\cref{fig:final application}). +The user can select from one of the predefined vector field functions or input their own function code that takes as parameters the previous and current position, the initial and current ray velocity, and the time passed since the ray was created. +The velocity returned by this vector field function is optionally interpolated with the ray direction of the last iteration using the field weight slider value. +The results are rendered non linearly in the main view using Runge-Kutta on the field function and linearly with ray outlines in the reference view. +Both views are controllable through arcball camera controls and clicking on the main view visualizes the outline of the ray neighborhood of the chosen pixel on the reference view. +An optional Lyapunov exponents overlay can be enabled through a dropdown menu to show the extent of a field's effects. +The exponents are visualized in white on top of the main view, using the scaled exponents as opacity. +The outline of the exponents can also be visualized as a ray outline mesh on the reference view using the outline button. +An optional high accuracy mode can be triggered by the enhance button to ensure the field integration is not influenced too much by the integration step size chosen for interactive rendering. + +The application includes nine predefined field functions. +The four mirage functions perform continuous refraction by computing the refraction between the previous and the current ray position in the field function, where the refraction index of each position is determined by the air temperature. +The temperature is calculated by interpolation between the core and the environmental temperature using the distance towards the heat source, either using point-point-distance for the spherical heat source or plane-point-distance for the plane heat source. +Both variants have a linear and a sigmoid variant for computing the interpolation parameters, where the linear variant leads to a more visible border of the heat spread whereas the sigmoid variant leads to a smoother transition. +Two translation functions show a rather simple way of manipulating the rays. +Using the default camera parameters where the camera is looking into $z$-direction, the translation on the $x$-axis leads to objects being moved more to the right the further they are away from the camera, while the translation on the $z$-axis can make objects appear in the camera twice, once from the front and once from the back when the ray goes into the opposite direction. +The rotation function takes initial ray direction and rotates it around the $z$-axis based on the time that has passed since the ray has been created. +Furthermore, two chaotic systems are included, the Lorenz and Rössler attractors as used by Gröller~\cite{grollerNonlinearRayTracing1995}. +\begin{figure}[!t] +\centering +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-10-05-spherical-linear-outline.png} + \caption{Using linear heat spread.} +\end{subfigure} +\begin{subfigure}{0.48\linewidth} + \includegraphics[width=\textwidth]{figures/2021-10-05-sigmoid-outline.png} + \caption{Using sigmoid heat spread.} +\end{subfigure} + \caption{Comparison of spherical mirage functions and their outlines.} + \label{fig:mirage-heat-spread-comparison} +\end{figure} +A side-by-side comparison of the spherical mirage functions with linear and sigmoid heat spread shows the difference of Lyapunov exponents very clearly (\cref{fig:mirage-heat-spread-comparison}. +While the linear heat spread leads to a clear border between the inside of the heat field and the environment, the sigmoid heat spread is too smooth to be detected using the default settings. +By increasing the central difference delta, the overlay is showing Lyapunov exponents based on the comparison of rays far more inside and far more outside the heat field. +While the result is no clear border either, it allows visualisation of the heat field in image space as a whole, which can again be used to create the outline mesh for the reference view. +The smoothness of the transition between environment and heat field can of course be noticed the most on this outline. +While the linear heat spread shows a clear distinction between inside and outside the heat field in the ray casted image, the transition would barely be noticeable at first for the sigmoid heat spread if it was not for the Blinn-Phong illumination. +This shows that the Blinn-Phong illumination increases the usability even for nonlinear ray casting as it gives an idea of the direction the rays are coming from before intersecting with a surface. +These points of interest can then be further examined by clicking on the particular pixel, triggering the visualizing of that pixel's neighboring rays in the reference view. +In \cref{fig:final application}, this has been done for the red mirage surface on the right half of the heat field. +The reference view shows not only that the rays are bend into the direction of the red wall inside the heat field, but also that the ray neighborhood is stretched in positive and negative $y$-direction. + +\begin{figure}[!t] + \centering + \includegraphics[width=0.98\linewidth]{figures/2021-10-25-chrome-mac.png} + \caption{The final application running on macOS inside Google Chrome as WebAssembly, rendered through Dawn's Metal backend.} + \label{fig:chrome-mac} +\end{figure} +Finally, the application can not only be run natively on Windows machines, it can also be run macOS and Linux, either natively or inside the Google Chrome or Mozilla Firefox web browsers by compiling the application to WebAssembly (\cref{fig:chrome-mac}). +Note that the WebGPU specification is still in flux. +Thus, running the application inside the browser may require a nightly build of the specific browser and further configuration \cite{beaufortAccessModernGPU2021}. +Furthermore, the application may not work in newer browser versions when the specification does not match the version the application was developed against. +Fixing these incompatibilities is usually an easy task and has been done multiple times during the execution of this software practical. +Once the standardisation process of WebGPU has been finished, there will be no more breaking changes in the API. diff --git a/report/Sources/4-Conclusion.tex b/report/Sources/4-Conclusion.tex new file mode 100644 index 0000000..f9c1708 --- /dev/null +++ b/report/Sources/4-Conclusion.tex @@ -0,0 +1,20 @@ +\chapter{Conclusion and Outlook} + +The implemented sandbox application offers a high level of flexibility for testing the visual influence of field functions. +Being able to reproduce the rays' path in the reference view makes it easy for users to understand how the final image is produced. +Through the Lyapunov exponents overlay and the assisting outline mesh, areas of different behavior in the field can be spotted easily. +Focusing on comprehension of visual phenomena, alternative visualisations of ray paths have been analyzed. +A reference view with two- or three-dimensional wavefronts in general gives a good idea of how rays contribute to the final image, but are not suitable for all kinds of functions. +The three-dimensional outline mesh has shown to be suitable for functions that affect all parts of the scene in an equal or comparable amount. +For mirages in particular, this mesh technique has been extended to visualize a pixel's ray neighborhood to allow the inspection of areas interesting to the user. +The combination of WebGPU and Rust is very promising for the field of scientific visualisation. +While modern standards such as Vulkan focus on more fine grained control and improved performance, they are generally harder to use than OpenGL. +WebGPU fills this void nicely by abstracting over these modern standards. +Additionally, the prospect of having one code base for many platforms including the web makes WebGPU a suitable successor to OpenGL. + +In future iterations of the application, the possibility to not only visualize a pixel's ray neighborhood but also the outline mesh of rays for similarly colored areas could make it easier to understand how specific parts of a mirage come into existence. +A larger library of predefined field functions could lay a good foundation for further experiments, for example, by adding functions for the simulation of black holes. +Finally, nonlinear ray casting is a very computation intensive process, which makes it hard to run the application interactively on devices with less powerful GPUs, such as laptops or tablets. +While the acceleration techniques proposed by Gröller~\cite{grollerNonlinearRayTracing1995} may allow interactive rendering of simple scenes such as the Cornell box on such devices, more complex scenes still require powerful hardware. +Researching the integration of remote rendering techniques as proposed by Lamberti and Sanna~\cite{lambertiStreamingBasedSolutionRemote2007} or Liao et al.~\cite{liaoLiveRenderCloudGaming2016} may thus be of interest. + diff --git a/report/Streaming.bib b/report/Streaming.bib new file mode 100644 index 0000000..72f5bb6 --- /dev/null +++ b/report/Streaming.bib @@ -0,0 +1,116 @@ + +@inproceedings{chengRealtime3DGraphics2004, + title = {Real-Time {{3D}} Graphics Streaming Using {{MPEG}}-4}, + booktitle = {In {{Proc}}. of the {{IEEE}}/{{ACM Workshop}} on {{Broadband Wireless Services}} and {{Applications}}}, + author = {Cheng, Liang and Bhushan, Anusheel and Pajarola, Renato and Zarki, Magda El}, + date = {2004}, + abstract = {Abstract — In this paper, we consider a real-time MPEG-4 streaming architecture to facilitate remote visualization of large scale 3D models on thin clients, which denote most of the hand-held devices that have limited computing resources. MPEG-4 serves as a key component to handle the compression, transmission, and visualization of the high-end supercomputer rendered image sequence, allowing the synchronization of the data in both the terminal and the server. The MPEG-4 encoding speed is thus the bottleneck of the system, in particular, the motion estimation process takes more than half of the total encoding time. We propose a fast motion estimation algorithm that expedites the MPEG-4 encoding process. Our algorithm utilizes the 3D data available at the server and is able to directly calculate the motion vector on a block basis without having to employ the expensive MPEG motion searching procedure. In addition, our algorithm can be implemented on the Graphic Processor Units(GPUs) such that most of the motion estimation process can be done in parallel to the encoding process. Our preliminary results show that the proposed motion estimation is able to significantly speed up the encoding process while maintaining the encoding quality. I.}, + file = {/Users/niklaskorz/Zotero/storage/5QI9PKSC/Cheng et al. - 2004 - Real-time 3D graphics streaming using MPEG-4.pdf;/Users/niklaskorz/Zotero/storage/4Z95EVKB/summary.html} +} + +@inproceedings{eisertLowDelayStreaming2008, + title = {Low Delay Streaming of Computer Graphics}, + booktitle = {2008 15th {{IEEE International Conference}} on {{Image Processing}}}, + author = {Eisert, P. and Fechteler, P.}, + date = {2008-10}, + pages = {2704--2707}, + issn = {2381-8549}, + doi = {10.1109/ICIP.2008.4712352}, + abstract = {In this paper, we present a graphics streaming system for remote gaming in a local area network. The framework aims at creating a networked game platform for home and hotel environments. A local PC based server executes a computer game and streams the graphical output to local devices in the rooms, such that the users can play everywhere in the network. Since delay is extremely crucial in interactive gaming, efficient encoding and caching of the commands is necessary. In our system we also address the round trip time problem of commands requiring feedback from the graphics board by simulating the graphics state at the server. This results in a system that enables interactive game play over the network.}, + eventtitle = {2008 15th {{IEEE International Conference}} on {{Image Processing}}}, + keywords = {3D coding,caching,Computational modeling,computer game,computer games,computer graphics,Computer graphics,Computer networks,Delay,encoding,Encoding,Games,graphics streaming,home environments,hotel environments,interactive gaming,local area network,local area networks,Local area networks,local PC based server,low delay streaming,media streaming,Network servers,remote gaming,Rendering (computer graphics),round trip time problem,Streaming media}, + file = {/Users/niklaskorz/Zotero/storage/HC5QBLBQ/Eisert und Fechteler - 2008 - Low delay streaming of computer graphics.pdf;/Users/niklaskorz/Zotero/storage/YLKRPFBU/4712352.html} +} + +@inproceedings{engelRemote3DVisualization1999, + title = {Remote {{3D}} Visualization Using Image-Streaming Techniques}, + booktitle = {In {{ISIMADE}} - 11 {{TH Internationl Conference}} on {{Systems Research}}, {{Informatics}} and {{Cybernetics}}}, + author = {Engel, Klaus and Sommer, Ove and Ernst, Christian and Ertl, Thomas}, + date = {1999}, + pages = {91--96}, + abstract = {1 Introduction and Related Work The World Wide Web provides access to a huge amount of scien-tific data. New algorithms and applications have to be developed in order to visualize such data on the large variety of clients on theWorld Wide Web. Data sets from typical scientific applications are growing fast. For example data volumes from 3D medical imaginglike CT are approaching sizes of 512 3 which amounts to more than}, + file = {/Users/niklaskorz/Zotero/storage/XE7SWQ73/Engel et al. - 1999 - Remote 3D visualization using image-streaming tech.pdf;/Users/niklaskorz/Zotero/storage/C98TZQVB/summary.html} +} + +@article{lambertiStreamingBasedSolutionRemote2007, + title = {A {{Streaming}}-{{Based Solution}} for {{Remote Visualization}} of {{3D Graphics}} on {{Mobile Devices}}}, + author = {Lamberti, F. and Sanna, A.}, + date = {2007-03}, + journaltitle = {IEEE Transactions on Visualization and Computer Graphics}, + volume = {13}, + number = {2}, + pages = {247--260}, + issn = {1941-0506}, + doi = {10.1109/TVCG.2007.29}, + abstract = {Mobile devices such as personal digital assistants, tablet PCs, and cellular phones have greatly enhanced user capability to connect to remote resources. Although a large set of applications is now available bridging the gap between desktop and mobile devices, visualization of complex 3D models is still a task hard to accomplish without specialized hardware. This paper proposes a system where a cluster of PCs, equipped with accelerated graphics cards managed by the Chromium software, is able to handle remote visualization sessions based on MPEG video streaming involving complex 3D models. The proposed framework allows mobile devices such as smart phones, personal digital assistants (PDAs), and tablet PCs to visualize objects consisting of millions of textured polygons and voxels at a frame rate of 30 fps or more depending on hardware resources at the server side and on multimedia capabilities at the client side. The server is able to concurrently manage multiple clients computing a video stream for each one; resolution and quality of each stream is tailored according to screen resolution and bandwidth of the client. The paper investigates in depth issues related to latency time, bit rate and quality of the generated stream, screen resolutions, as well as frames per second displayed}, + eventtitle = {{{IEEE Transactions}} on {{Visualization}} and {{Computer Graphics}}}, + keywords = {3D graphics,3D model visualization,Acceleration,Application software,cellular phones,Cellular phones,Chromium,Chromium software,client-server system,client-server systems,cluster-based rendering,cluster-based rendering.,Computer Communication Networks,Computer Graphics,Computers; Handheld,Data Compression,Echocardiography; Three-Dimensional,Equipment Design,Equipment Failure Analysis,Graphics,graphics cards,Hardware,image texture,mobile computing,mobile devices,MPEG,MPEG video streaming,multimedia,multimedia computing,notebook computers,object visualization,Personal communication networks,personal digital assistants,Personal digital assistants,remote visualization,Remote visualization,Signal Processing; Computer-Assisted,smart phones,Software,solid modelling,Streaming media,tablet PC,textured polygons,video streaming,Visualization,voxels}, + file = {/Users/niklaskorz/Zotero/storage/DSA9IQPE/Lamberti und Sanna - 2007 - A Streaming-Based Solution for Remote Visualizatio.pdf;/Users/niklaskorz/Zotero/storage/7JZM7EQ5/4069234.html} +} + +@article{liaoLiveRenderCloudGaming2016, + title = {{{LiveRender}}: A {{Cloud Gaming System Based}} on {{Compressed Graphics Streaming}}}, + shorttitle = {{{LiveRender}}}, + author = {Liao, X. and Lin, L. and Tan, G. and Jin, H. and Yang, X. and Zhang, W. and Li, B.}, + date = {2016-08}, + journaltitle = {IEEE/ACM Transactions on Networking}, + volume = {24}, + number = {4}, + pages = {2128--2139}, + issn = {1558-2566}, + doi = {10.1109/TNET.2015.2450254}, + abstract = {In cloud gaming systems, the game program runs at servers in the cloud, while clients access game services by sending input events to the servers and receiving game scenes via video streaming. In this paradigm, servers are responsible for all performance-intensive operations, and thus suffer from poor scalability. An alternative paradigm is called graphics streaming, in which graphics commands and data are offloaded to the clients for local rendering, thereby mitigating the server's burden and allowing more concurrent game sessions. Unfortunately, this approach is bandwidth-consuming, due to large amounts of graphic commands and geometry data. In this paper, we present LiveRender, an open-source gaming system that remedies the problem by implementing a suite of bandwidth optimization techniques including intraframe compression, interframe compression, and caching, establishing what we call compressed graphics streaming. Experiments results show that the new approach is able to reduce bandwidth consumption by 52\%-73\% compared to raw graphics streaming, with no perceptible difference in video quality and reduced response delay. Compared to the video streaming approach, LiveRender achieves a traffic reduction of 40\%-90\% with even improved video quality and substantially smaller response delay, while enabling higher concurrency at the server.}, + eventtitle = {{{IEEE}}/{{ACM Transactions}} on {{Networking}}}, + keywords = {bandwidth optimization techniques,cloud computing,Cloud gaming,cloud gaming system,compressed graphics streaming,compressed sensing,computer games,computer graphics,Delays,game services,Games,Geometry,geometry data,graphic commands,graphics streaming,interframe compression,intraframe compression,LiveRender,model compression,open-source gaming system,optimisation,performance-intensive operations,Rendering (computer graphics),Servers,Streaming media,telecommunication traffic,video quality,video servers,video streaming}, + file = {/Users/niklaskorz/Zotero/storage/22URWX35/Liao et al. - 2016 - LiveRender A Cloud Gaming System Based on Compres.pdf;/Users/niklaskorz/Zotero/storage/MB6XSL7M/7166339.html} +} + +@article{noimarkStreamingScenesMPEG42003, + title = {Streaming Scenes to {{MPEG}}-4 Video-Enabled Devices}, + author = {Noimark, Y. and Cohen-Or, D.}, + date = {2003-01}, + journaltitle = {IEEE Computer Graphics and Applications}, + volume = {23}, + number = {1}, + pages = {58--64}, + issn = {1558-1756}, + doi = {10.1109/MCG.2003.1159614}, + abstract = {Streaming a remote walkthrough of a complex computer-generated environment is an emerging challenge in computer graphics. The size of most models precludes downloading the entire model from the server to the client. We stream real-time computer graphic scenes to handheld devices using object-based encoding from MPEG-4 and knowledge from a 3D model.}, + eventtitle = {{{IEEE Computer Graphics}} and {{Applications}}}, + keywords = {3D model,client server system,client-server systems,code standards,complex computer-generated environment,Computer displays,computer graphics,Discrete cosine transforms,downloading,Encoding,handheld device,Layout,Mobile computing,Motion estimation,MPEG 4 Standard,MPEG-4 video-enabled devices,object-based encoding,Quantization,real-time computer graphic scenes,real-time systems,remote walkthrough,scene streaming,Streaming media,telecommunication standards,video coding,Video compression}, + file = {/Users/niklaskorz/Zotero/storage/XSRTEPMV/Noimark und Cohen-Or - 2003 - Streaming scenes to MPEG-4 video-enabled devices.pdf;/Users/niklaskorz/Zotero/storage/IXVTJG3W/1159614.html} +} + +@inproceedings{shiScalableSupport3D2010, + title = {Scalable {{Support}} for {{3D Graphics Applications}} in {{Cloud}}}, + booktitle = {2010 {{IEEE}} 3rd {{International Conference}} on {{Cloud Computing}}}, + author = {Shi, W. and Lu, Y. and Li, Z. and Engelsma, J.}, + date = {2010-07}, + pages = {346--353}, + issn = {2159-6190}, + doi = {10.1109/CLOUD.2010.76}, + abstract = {Recent advances in virtualization technology and wide acceptance of the cloud computing model are having significant impact on the software service industry. Though cloud computing and virtualization technology has been widely applied in supporting the information processing needs of conventional enterprise and business applications, there has been little success to-date in enabling realtime 3D virtual appliances in the cloud. This paper aims to address this deficiency by presenting SHARC, a solution for enabling scalable support of realtime 3D applications in a cloud computing environment. The solution uses a scalable pipelined processing infrastructure which consists of three processing networks according to the principle of division-of-labor, a virtualization server network for running 3D virtual appliances, a graphics rendering network for processing graphics rendering workload with load balancing, and a media streaming network for transcoding rendered frames into H.264/MPEG-4 media streams and streaming the media streams to a cloud user. The paper describes a prototype implementation of SHARC and reports test results that demonstrate the viability of this approach.}, + eventtitle = {2010 {{IEEE}} 3rd {{International Conference}} on {{Cloud Computing}}}, + keywords = {3D Graphics,3D graphics applications,cloud computing,Cloud Computing,Clouds,Home appliances,Internet,Media,pipeline processing,pipelined processing infrastructure,Rendering (computer graphics),Scalability,Servers,SHARC,software engineering,software service industry,solid modelling,Three dimensional displays,virtual reality,virtualization technology}, + file = {/Users/niklaskorz/Zotero/storage/JBY7KNK2/Shi et al. - 2010 - Scalable Support for 3D Graphics Applications in C.pdf;/Users/niklaskorz/Zotero/storage/2FRQD2P3/5557973.html} +} + +@article{telerStreamingComplex3D2001, + title = {Streaming of {{Complex 3D Scenes}} for {{Remote Walkthroughs}}}, + author = {Teler, Eyal and Lischinski, Dani}, + date = {2001}, + journaltitle = {Computer Graphics Forum}, + volume = {20}, + number = {3}, + pages = {17--25}, + issn = {1467-8659}, + doi = {10.1111/1467-8659.00494}, + url = {https://onlinelibrary.wiley.com/doi/abs/10.1111/1467-8659.00494}, + urldate = {2021-03-02}, + abstract = {We describe a new 3D scene streaming approach for remote walkthroughs. In a remote walkthrough, a user on a client machine interactively navigates through a scene that resides on a remote server. Our approach allows a user to walk through a remote 3D scene, without ever having to download the entire scene from the server. Our algorithm achieves this by selectively transmitting only small parts of the scene and lower quality representations of objects, based on the user's viewing parameters and the available connection bandwidth. An online optimization algorithm selects which object representations to send, based on the integral of a benefit measure along the predicted path of movement. The rendering quality at the client depends on the available bandwidth, but practical navigation of the scene is possible even when bandwidth is low.}, + langid = {english}, + annotation = {\_eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1111/1467-8659.00494}, + file = {/Users/niklaskorz/Zotero/storage/RP5HV2IG/Teler und Lischinski - 2001 - Streaming of Complex 3D Scenes for Remote Walkthro.pdf;/Users/niklaskorz/Zotero/storage/L3AMKEJK/1467-8659.html} +} + + diff --git a/report/bibliography-mimosis.tex b/report/bibliography-mimosis.tex new file mode 100644 index 0000000..225837f --- /dev/null +++ b/report/bibliography-mimosis.tex @@ -0,0 +1,138 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Some adjustments to make the bibliography more clean +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% The subsequent commands do the following: +% - Removing the month field from the bibliography +% - Fixing the Oxford commma +% - Suppress the "in" for journal articles +% - Remove the parentheses of the year in an article +% - Delimit volume and issue of an article by a colon ":" instead of +% a dot "" +% - Use commas to separate the location of publishers from their name +% - Remove the abbreviation for technical reports +% - Display the label of bibliographic entries without brackets in the +% bibliography +% - Ensure that DOIs are followed by a non-breakable space +% - Use hair spaces between initials of authors +% - Make the font size of citations smaller +% - Fixing ordinal numbers (1st, 2nd, 3rd, and so) on by using +% superscripts + +% Remove the month field from the bibliography. It does not serve a good +% purpose, I guess. And often, it cannot be used because the journals +% have some crazy issue policies. +\AtEveryBibitem{\clearfield{month}} +\AtEveryCitekey{\clearfield{month}} + +% Fixing the Oxford comma. Not sure whether this is the proper solution. +% More information is available under [1] and [2]. +% +% [1] http://tex.stackexchange.com/questions/97712/biblatex-apa-style-is-missing-a-comma-in-the-references-why +% [2] http://tex.stackexchange.com/questions/44048/use-et-al-in-biblatex-custom-style +% +\AtBeginBibliography{% + \renewcommand*{\finalnamedelim}{% + \ifthenelse{\value{listcount} > 2}{% + \addcomma + \addspace + \bibstring{and}% + }{% + \addspace + \bibstring{and}% + } + } +} + +% Suppress "in" for journal articles. This is unnecessary in my opinion +% because the journal title is typeset in italics anyway. +\renewbibmacro{in:}{% + \ifentrytype{article} + {% + }% + % else + {% + \printtext{\bibstring{in}\intitlepunct}% + }% +} + +% Remove the parentheses for the year in an article. This removes a lot +% of undesired parentheses in the bibliography, thereby improving the +% readability. Moreover, it makes the look of the bibliography more +% consistent. +\renewbibmacro*{issue+date}{% + \setunit{\addcomma\space} + \iffieldundef{issue} + {\usebibmacro{date}} + {\printfield{issue}% + \setunit*{\addspace}% + \usebibmacro{date}}% + \newunit} + +% Delimit the volume and the number of an article by a colon instead of +% by a dot, which I consider to be more readable. +\renewbibmacro*{volume+number+eid}{% + \printfield{volume}% + \setunit*{\addcolon}% + \printfield{number}% + \setunit{\addcomma\space}% + \printfield{eid}% +} + +% Do not use a colon for the publisher location. Instead, connect +% publisher, location, and date via commas. +\renewbibmacro*{publisher+location+date}{% + \printlist{publisher}% + \setunit*{\addcomma\space}% + \printlist{location}% + \setunit*{\addcomma\space}% + \usebibmacro{date}% + \newunit% +} + +% Ditto for other entry types. +\renewbibmacro*{organization+location+date}{% + \printlist{location}% + \setunit*{\addcomma\space}% + \printlist{organization}% + \setunit*{\addcomma\space}% + \usebibmacro{date}% + \newunit% +} + +% Do not abbreviate "technical report". +\DefineBibliographyStrings{english}{% + techreport = {technical report}, +} + +% Display the label of a bibliographic entry in bare style, without any +% brackets. I like this more than the default. +% +% Note that this is *really* the proper and official way of doing this. +\DeclareFieldFormat{labelnumberwidth}{#1\adddot} + +% Ensure that DOIs are followed by a non-breakable space. +\DeclareFieldFormat{doi}{% + \mkbibacro{DOI}\addcolon\addnbspace + \ifhyperref + {\href{http://dx.doi.org/#1}{\nolinkurl{#1}}} + % + {\nolinkurl{#1}} +} + +% Use proper hair spaces between initials as suggested by Bringhurst and +% others. +\renewcommand*\bibinitdelim {\addnbthinspace} +\renewcommand*\bibnamedelima{\addnbthinspace} +\renewcommand*\bibnamedelimb{\addnbthinspace} +\renewcommand*\bibnamedelimi{\addnbthinspace} + +% Make the font size of citations smaller. Depending on your selected +% font, you might not need this. +\renewcommand*{\citesetup}{% + \biburlsetup + \small +} + +% \DeclareLanguageMapping{british}{bibliography-correct-ordinals} +% \DeclareLanguageMapping{english}{bibliography-correct-ordinals} \ No newline at end of file diff --git a/report/figures/2021-05-05.png b/report/figures/2021-05-05.png new file mode 100644 index 0000000..23c355b --- /dev/null +++ b/report/figures/2021-05-05.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5925f5f4bee2edeb3062e4b6ca8f79bea04a8a1d5688a72bbf9eb06453437d86 +size 10141 diff --git a/report/figures/2021-05-16-suzanne.png b/report/figures/2021-05-16-suzanne.png new file mode 100644 index 0000000..928c491 --- /dev/null +++ b/report/figures/2021-05-16-suzanne.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:b203ce29e92bbbd94fe580a40aadfd5c5a4fb4a72b41fd5c4a1b59824a37d7a9 +size 50998 diff --git a/report/figures/2021-05-16.png b/report/figures/2021-05-16.png new file mode 100644 index 0000000..eba2bd7 --- /dev/null +++ b/report/figures/2021-05-16.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5967a8d66ef2f842836ea90fb82e3b10f116dc2a3fc94fccbd63e241c15969e9 +size 31027 diff --git a/report/figures/2021-05-25.png b/report/figures/2021-05-25.png new file mode 100644 index 0000000..ef8c41f --- /dev/null +++ b/report/figures/2021-05-25.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:36581030608ef6ed04a97efb68109b6f46ffbfdf40cd6dde42fa4be76c25a4b2 +size 12979 diff --git a/report/figures/2021-06-20-lorenz-scene-rotation.png b/report/figures/2021-06-20-lorenz-scene-rotation.png new file mode 100644 index 0000000..bb3af5c --- /dev/null +++ b/report/figures/2021-06-20-lorenz-scene-rotation.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:82b8be2a0a74adbdce51c46c9ebb7b367c6aaae0736d1f1b23cbe70de99c9509 +size 125763 diff --git a/report/figures/2021-06-20-lorenz.png b/report/figures/2021-06-20-lorenz.png new file mode 100644 index 0000000..b35b0f1 --- /dev/null +++ b/report/figures/2021-06-20-lorenz.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5e7190474f3574ba7117e5a8cc6cda21a826035852dfb5bbfa11610765906423 +size 68579 diff --git a/report/figures/2021-06-20-p005.png b/report/figures/2021-06-20-p005.png new file mode 100644 index 0000000..f22da92 --- /dev/null +++ b/report/figures/2021-06-20-p005.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:15d75c8cfbde759a3ae802e2f325df35ecf982407f194afdba7000cc99d24e86 +size 115020 diff --git a/report/figures/2021-06-20-p100.png b/report/figures/2021-06-20-p100.png new file mode 100644 index 0000000..2980574 --- /dev/null +++ b/report/figures/2021-06-20-p100.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:fd11fc6d30fec280bbfb6d8ef69261d34e0d06236eba73f06d11261ebc8b2b4c +size 73547 diff --git a/report/figures/2021-06-20-rotation.png b/report/figures/2021-06-20-rotation.png new file mode 100644 index 0000000..ddda57c --- /dev/null +++ b/report/figures/2021-06-20-rotation.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:9f5f717848c2aad2585af9f87b4e412613b276dec5ca788e8a0536e61c2bbba6 +size 182528 diff --git a/report/figures/2021-06-20.png b/report/figures/2021-06-20.png new file mode 100644 index 0000000..22681af --- /dev/null +++ b/report/figures/2021-06-20.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:8915a4dbae36196d8a27f0bed697e7f90ab2bf362b701a6db7cf9972d28e32b6 +size 152295 diff --git a/report/figures/2021-06-30-glyphs.png b/report/figures/2021-06-30-glyphs.png new file mode 100644 index 0000000..3d67ef2 --- /dev/null +++ b/report/figures/2021-06-30-glyphs.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:438742a79c182a27ea72e7f40494e8eb31bc7ca76d96b46efedb295755d94905 +size 107514 diff --git a/report/figures/2021-06-30-lorenz.png b/report/figures/2021-06-30-lorenz.png new file mode 100644 index 0000000..aee7d1c --- /dev/null +++ b/report/figures/2021-06-30-lorenz.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:a832e0d87279b4c58bac21ee8328a922ce52ddafbbc2bcebd969cf8eb0bb1631 +size 211174 diff --git a/report/figures/2021-06-30.png b/report/figures/2021-06-30.png new file mode 100644 index 0000000..3e610bd --- /dev/null +++ b/report/figures/2021-06-30.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:f94671be11e79284b9ad0570f9719f1eebce586855b4e582b87829a37fcdd1ee +size 191846 diff --git a/report/figures/2021-07-14-roessler.png b/report/figures/2021-07-14-roessler.png new file mode 100644 index 0000000..9b36de2 --- /dev/null +++ b/report/figures/2021-07-14-roessler.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:bd248174ebaa3b9222b107737ff10c120ff0c61026aea607e1e4b295ff4c1c4f +size 157314 diff --git a/report/figures/2021-07-14-wireframe.png b/report/figures/2021-07-14-wireframe.png new file mode 100644 index 0000000..dbaec7f --- /dev/null +++ b/report/figures/2021-07-14-wireframe.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:6021da481f30eb36571beb6e61ee2fd54588f39f32003c5847152fc7c2a1d13e +size 394696 diff --git a/report/figures/2021-07-14.png b/report/figures/2021-07-14.png new file mode 100644 index 0000000..3082f78 --- /dev/null +++ b/report/figures/2021-07-14.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:055db104c789ef5f86f45e17f9febfb16d795cb54977d33e91151e0a870a772c +size 246914 diff --git a/report/figures/2021-08-04-plane.png b/report/figures/2021-08-04-plane.png new file mode 100644 index 0000000..faef460 --- /dev/null +++ b/report/figures/2021-08-04-plane.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:f93efce7fa3011ace98d50ce9bffac678ae45a859e75f55a24fcb9b7d4a203a0 +size 205043 diff --git a/report/figures/2021-08-04-spherical.png b/report/figures/2021-08-04-spherical.png new file mode 100644 index 0000000..058da70 --- /dev/null +++ b/report/figures/2021-08-04-spherical.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:677a613f45bf6022f4adcee5705bbd02e69816c9851a21c396e527acb74f6c90 +size 232391 diff --git a/report/figures/2021-08-19-smooth.png b/report/figures/2021-08-19-smooth.png new file mode 100644 index 0000000..9d4f59e --- /dev/null +++ b/report/figures/2021-08-19-smooth.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:55fc028b871ce11c385178fda27729b746522d04b0cdabea09c39d2b2d5c7e72 +size 346373 diff --git a/report/figures/2021-08-19.png b/report/figures/2021-08-19.png new file mode 100644 index 0000000..1260d5b --- /dev/null +++ b/report/figures/2021-08-19.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:e83c2ea60613f1a2dee27c1bf52bae2d706cdc8e06ecb9ad031d52335c772558 +size 411349 diff --git a/report/figures/2021-09-14-linear-high-accuracy-main.png b/report/figures/2021-09-14-linear-high-accuracy-main.png new file mode 100644 index 0000000..a9c4f35 --- /dev/null +++ b/report/figures/2021-09-14-linear-high-accuracy-main.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:35a2a17555f99b33fb399016169e8dc1780c18f20ae5c90647b64aa6fc16c9e5 +size 134366 diff --git a/report/figures/2021-09-14-linear-high-accuracy.png b/report/figures/2021-09-14-linear-high-accuracy.png new file mode 100644 index 0000000..2baa531 --- /dev/null +++ b/report/figures/2021-09-14-linear-high-accuracy.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:d421ef7c1a3e735d451ffbc7930e4082b4d9fbbebf553531abf7eb2dfdf4d03a +size 252602 diff --git a/report/figures/2021-09-14-linear-main.png b/report/figures/2021-09-14-linear-main.png new file mode 100644 index 0000000..2e3a6ac --- /dev/null +++ b/report/figures/2021-09-14-linear-main.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:eacffcf57513e4ddcf4a732a0fb6814f3fd6d474ec03c7842cedda057dd22ac9 +size 137284 diff --git a/report/figures/2021-09-14-linear.png b/report/figures/2021-09-14-linear.png new file mode 100644 index 0000000..888bae4 --- /dev/null +++ b/report/figures/2021-09-14-linear.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:39028c3211c5876926d42d3e8b11c1bc1aeed8ef59444aef675eccaf39dd7d5d +size 258595 diff --git a/report/figures/2021-09-14-sigmoid-high-accuracy.png b/report/figures/2021-09-14-sigmoid-high-accuracy.png new file mode 100644 index 0000000..bc13f44 --- /dev/null +++ b/report/figures/2021-09-14-sigmoid-high-accuracy.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:b1f69679c5aae322a6c0eb654f99d016e77fe07bb55959664e2bede5edfdc8a3 +size 249006 diff --git a/report/figures/2021-09-14-sigmoid.png b/report/figures/2021-09-14-sigmoid.png new file mode 100644 index 0000000..d0ada0e --- /dev/null +++ b/report/figures/2021-09-14-sigmoid.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:6fea4408804234392a43c1aec9427c0e05f4a02ed84a07477ae786c35d534380 +size 245642 diff --git a/report/figures/2021-10-05-plane-linear-outline.png b/report/figures/2021-10-05-plane-linear-outline.png new file mode 100644 index 0000000..4f10e43 --- /dev/null +++ b/report/figures/2021-10-05-plane-linear-outline.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:35ca3a1cebbfc658824477ab924bffab96c85651e6fe5b9f8e605bedab602589 +size 958453 diff --git a/report/figures/2021-10-05-roessler.png b/report/figures/2021-10-05-roessler.png new file mode 100644 index 0000000..8ea9361 --- /dev/null +++ b/report/figures/2021-10-05-roessler.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:6893d65046f69ec3e6e42330800928da60ac02971a3ebad947d790c67b7e0605 +size 340317 diff --git a/report/figures/2021-10-05-sigmoid-outline.png b/report/figures/2021-10-05-sigmoid-outline.png new file mode 100644 index 0000000..179c55c --- /dev/null +++ b/report/figures/2021-10-05-sigmoid-outline.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:b6e86fc67da638250abdb4788523f1ccf40d7810d2cf21ef4252404fc6a3dad8 +size 265593 diff --git a/report/figures/2021-10-05-sigmoid.png b/report/figures/2021-10-05-sigmoid.png new file mode 100644 index 0000000..304a712 --- /dev/null +++ b/report/figures/2021-10-05-sigmoid.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:3dcd6524c8da42082c7c594eb387bc27fb56d164f60b8de35eee43688f891bff +size 262898 diff --git a/report/figures/2021-10-05-spherical-linear-outline.png b/report/figures/2021-10-05-spherical-linear-outline.png new file mode 100644 index 0000000..48ea6b8 --- /dev/null +++ b/report/figures/2021-10-05-spherical-linear-outline.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:b1aaa432d92aa2ae0a609f95bc9fc09a71842474df037dd09e4661aee620a085 +size 318725 diff --git a/report/figures/2021-10-25-chrome-mac.png b/report/figures/2021-10-25-chrome-mac.png new file mode 100644 index 0000000..b407d4e --- /dev/null +++ b/report/figures/2021-10-25-chrome-mac.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:bee74fabf0ed497b14e9592ce6127520834f0fc8e314af79b85517e1f97c7815 +size 1008793 diff --git a/report/fonts/Inconsolata-Bold.ttf b/report/fonts/Inconsolata-Bold.ttf new file mode 100644 index 0000000..f38791c --- /dev/null +++ b/report/fonts/Inconsolata-Bold.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:c268fae6dbf17a27f648218fac958b86dc38e169f6315f0b02866966f56b42bf +size 109948 diff --git a/report/fonts/Inconsolata-Regular.ttf b/report/fonts/Inconsolata-Regular.ttf new file mode 100644 index 0000000..24462fb --- /dev/null +++ b/report/fonts/Inconsolata-Regular.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:e28c150b4390e5fd59aedc2c150b150086fbcba0b4dbde08ac260d6db65018d6 +size 96964 diff --git a/report/fonts/OpenSans-Bold.ttf b/report/fonts/OpenSans-Bold.ttf new file mode 100644 index 0000000..d8ed5a8 --- /dev/null +++ b/report/fonts/OpenSans-Bold.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:a7a41b04969454dfbe620bfbc7699647b2819d768374b3f0f90a714a0d80b199 +size 103616 diff --git a/report/fonts/OpenSans-BoldItalic.ttf b/report/fonts/OpenSans-BoldItalic.ttf new file mode 100644 index 0000000..24ae85a --- /dev/null +++ b/report/fonts/OpenSans-BoldItalic.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:2bcb09400d80863bc23a4c328fe0bc026780b3ab888ca43ff1f9d1a4c52b1ebf +size 92124 diff --git a/report/fonts/OpenSans-Regular.ttf b/report/fonts/OpenSans-Regular.ttf new file mode 100644 index 0000000..d030bba --- /dev/null +++ b/report/fonts/OpenSans-Regular.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:34ad67cfc362403e3baabe4ad0f4ef0b4b6b68e2f252dd703bbb1e10198188e2 +size 96428 diff --git a/report/fonts/OpenSans-RegularItalic.ttf b/report/fonts/OpenSans-RegularItalic.ttf new file mode 100644 index 0000000..5695e2f --- /dev/null +++ b/report/fonts/OpenSans-RegularItalic.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:7cf86119f86cac1c082cd2341c0dae6ebd94f9b187682e019827114ed1c3f95f +size 91736 diff --git a/report/fonts/OpenSans-SemiBold.ttf b/report/fonts/OpenSans-SemiBold.ttf new file mode 100644 index 0000000..92495c0 --- /dev/null +++ b/report/fonts/OpenSans-SemiBold.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:c729fb9e9113b95da37edd1ee95a983d22c46b646fc2427641943ecd3b86e104 +size 100256 diff --git a/report/fonts/OpenSans-SemiBoldItalic.ttf b/report/fonts/OpenSans-SemiBoldItalic.ttf new file mode 100644 index 0000000..ec59198 --- /dev/null +++ b/report/fonts/OpenSans-SemiBoldItalic.ttf @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:365bf6bd83b78a80eed6dbdeb4e4d46be558ae77debe8c34345e4509ade978a2 +size 91604 diff --git a/report/mimosis.cls b/report/mimosis.cls new file mode 100644 index 0000000..def94c9 --- /dev/null +++ b/report/mimosis.cls @@ -0,0 +1,264 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesClass{mimosis}[2017/08/01 Minimal modern thesis class] + +\DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrbook}} +\ProcessOptions\relax + +\LoadClass[paper=a4, + twoside, + pagesize, + DIV=10, % TODO: Make configurable + BCOR=10mm, % TODO: Make configurable + cleardoublepage=empty, + numbers=noenddot, + titlepage, + toc=bibliography, + toc=index, + ]{scrbook} + +\RequirePackage{ifpdf} +\RequirePackage{ifxetex} +\RequirePackage{ifluatex} + +\newif\ifxetexorluatex +\ifxetex + \xetexorluatextrue +\else + \ifluatex + \xetexorluatextrue + \else + \xetexorluatexfalse + \fi +\fi + +\RequirePackage{fontspec} + +% Makes it possible to switch between different languages in the text +% while keeping hyphenation rules correct. Should you add another one +% in the list, please ensure that `english` is the last one. The last +% language is used to control standard hyphenation. +\usepackage[ngerman,french,english]{babel} + +\RequirePackage{csquotes} % Context-sensitive quotation marks +\RequirePackage{makeidx} % For creating indices +\RequirePackage{xspace} % For automatically "eating" spaces + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Multi-line comments +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\newcommand{\comment}[1]{} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Fonts & colours +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage[usenames,dvipsnames]{xcolor} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Graphics +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage{graphicx} +\graphicspath{% + {../Figures/} + {./figures/} + {./} +} + +% Suppress warnings about page groups in PDFs. This is not justified +% in most of the cases. I am pretty sure I am including my images in +% the right manner. +\begingroup\expandafter\expandafter\expandafter\endgroup +\expandafter\ifx\csname pdfsuppresswarningpagegroup\endcsname\relax +\else + \pdfsuppresswarningpagegroup=1\relax +\fi + +\RequirePackage[labelfont=bf]{caption} +\RequirePackage[]{subcaption} +\setcapindent{0pt} + +% Make sub-references using \subref being typeset with parentheses. +% Otherwise, only the counter will be printed. +\captionsetup{subrefformat=parens} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Glossaries +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage[% + acronym, + automake, + nogroupskip, + nopostdot, + nonumberlist, + toc, + ]{glossaries} + +% New style that prevents line-breaks between the full description and +% the acronym. Furthermore, it ensures that the acronym is always +% printed in an upright font. +\newacronymstyle{long-short-mimosis} +{% + \GlsUseAcrEntryDispStyle{long-short}% +}% +{% + \GlsUseAcrStyleDefs{long-short}% + \renewcommand*{\genacrfullformat}[2]{% + \glsentrylong{##1}##2~\textup{(\firstacronymfont{\glsentryshort{##1}})}% + }% + \renewcommand*{\Genacrfullformat}[2]{% + \Glsentrylong{##1}##2~\textup{(\firstacronymfont{\glsentryshort{##1}})}% + }% + \renewcommand*{\genplacrfullformat}[2]{% + \glsentrylongpl{##1}##2~\textup{(\firstacronymfont{\glsentryshortpl{##1}})}% + }% + \renewcommand*{\Genplacrfullformat}[2]{% + \Glsentrylongpl{##1}##2~\textup{(\firstacronymfont{\Glsentryshortpl{##1}})}% + }% +} + +% A new glossary style that based on the long style of the glossaries +% package. It ensures that descriptions and entries are aligned. +\newglossarystyle{long-mimosis}{% + \setglossarystyle{long} + + \renewcommand{\glossentry}[2]{% + \glsentryitem{##1}\glstarget{##1}{\glossentryname{##1}} & + \glossentrydesc{##1}\glspostdescription\space ##2\tabularnewline + }% +} + +% Constrain the description width to enforce breaks.m +\setlength{\glsdescwidth}{10cm} + +\setacronymstyle{long-short-mimosis} +\setglossarystyle{long-mimosis} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Paragraph lists & compact enumerations +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage[% + olditem, % Do not modify itemize environments by default + oldenum % Do not modify enumerate environments by default + ]{paralist} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Spacing +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage{setspace} +\onehalfspacing + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Tables +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage{booktabs} +\RequirePackage{multirow} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Proper typesetting of units +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage[binary-units=true]{siunitx} + +\sisetup{% + detect-all = true, + detect-family = true, + detect-mode = true, + detect-shape = true, + detect-weight = true, + detect-inline-weight = math, +} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Mathematics +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\RequirePackage{amsmath} +\RequirePackage{amsthm} +\RequirePackage{dsfont} + +% Fix the spacing of \left and \right. Use these with the proper bracket +% in order to ensure that they scale automatically. +\let\originalleft\left +\let\originalright\right +\renewcommand{\left}{\mathopen{}\mathclose\bgroup\originalleft} +\renewcommand{\right}{\aftergroup\egroup\originalright} + +\DeclareMathOperator*{\argmin} {arg\,min} +\DeclareMathOperator {\dist} {dist} +\DeclareMathOperator {\im} {im} + +\newcommand{\domain}{\ensuremath{\mathds{D}}} +\newcommand{\real} {\ensuremath{\mathds{R}}} + +% Proper differential operators +\newcommand{\diff}[1]{\ensuremath{\operatorname{d}\!{#1}}} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Ordinals +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\newcommand {\st}{\textsuperscript{\textup{st}}\xspace} +\newcommand {\rd}{\textsuperscript{\textup{rd}}\xspace} +\newcommand {\nd}{\textsuperscript{\textup{nd}}\xspace} +\renewcommand{\th}{\textsuperscript{\textup{th}}\xspace} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Penalties +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\clubpenalty = 10000 +\widowpenalty = 10000 +\displaywidowpenalty = 10000 + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Headers +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% \RequirePackage{scrlayer-scrpage} +\RequirePackage[headsepline]{scrlayer-scrpage} +\pagestyle{scrheadings} +% \clearpairofpagestyles +% % \ihead{head inner} +% % \chead{head center} +% \ohead{\headmark} +% % \ifoot{foot inner} +% % \cfoot{foot center} +% \ofoot{\pagemark} + +\addtokomafont{pagehead}{\scshape} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Typefaces for parts, chapters, and sections +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\renewcommand{\partformat}{\huge\partname~\thepart\autodot} +\renewcommand{\raggedpart}{\flushleft} + +\setkomafont{part}{\normalfont\huge\scshape} +\setkomafont{chapter}{\normalfont\huge\sffamily\bfseries\color{BrickRed}} +% \setkomafont{chapter}{\normalfont\huge\bfseries\color{BrickRed}} +\setkomafont{sectioning}{\normalfont\sffamily\bfseries} +\setkomafont{descriptionlabel}{\normalfont\bfseries} + +\setkomafont{caption}{\small} +\setkomafont{captionlabel}{\usekomafont{caption}} + +% Large number for chapter +\renewcommand*{\chapterformat}{% + \fontsize{50}{55}\selectfont\thechapter\autodot\enskip +} + +\setkomafont{chapterentry}{\normalfont\large\bfseries} + + + + + + +% \DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrbook}} \ No newline at end of file diff --git a/report/notes.tex b/report/notes.tex new file mode 100644 index 0000000..15ce4f0 --- /dev/null +++ b/report/notes.tex @@ -0,0 +1,19 @@ + +\iffalse +\begin{itemize} + \item Rust ray caster from scratch (winit, wgpu, compute shader, texture and fragment shader for presentation) + \item Basic linear ray casting of cornell box with surface colors as normals (May 5) + \item Blinn-phong shading and camera controls (May 16) + \item Loading of wavefront-obj-files per drag-and-drop (May 16) + \item Nonlinear ray casting using Runge-Kutta 4th order and a gravity center (May 25) + \item User input for custom functions, selection for predefined functions (can be edited), field weight mechanism to adjust influence of field on rays, 2d reference view to visualize path of rays in form of wavefronts, option to rotate scene instead of camera in raycast view (June 20) + \item 2D wavefronts are not really suitable for chaotic fields like Lorenz attractors or rotations (June 20) + \item 3D wavefronts with arrow glyphs and camera controls in reference view are suited better for showing the path of the rays (June 30) + \item Multicolored mesh in 3D reference view for showing the outlines of the ray paths, colors combined with wireframe mode emphasize the path of an edge, also very good for showing the compressed outline in chaotic fields (July 14) + \item Mirages can be expressed as field functions, using linear heat spread of predefined distance and refraction between the previous and the current point, usage of Runge-Kutta integration makes the refraction continuous, tried with spherical and with plane heat source, also added visualisation of rays around a pixel when clicking on reference view (August 4) + \item Lyapunov exponents show the extent of the heat spread, gives a circular outline in image space for spherical heat spread, can be smoothed and scaled through user input parameters (August 19) + \item High accuracy mode reveals incorrectness of Runge-Kutta integration for spherical mirage function, fixed by changing integration parameters (look up what I did, something with which point are passed as previous and current), added sigmoid heat spread for both spherical and plane heat source to simulate smoother heat spread (September 14) + \item Visualize outline of mirages by extracting outermost points of lyapunov exponents in image space and showing ray paths for these pixels in 3D reference view; adaptive accuracy uses larger integration steps for small gradients and smaller integration steps for large gradients, reveals issue with field weight interpolation (October 5) + \item Outlook: visualize outline for rays of same-color areas on click, fix field weight interpolation (needs to be moved into Runge-Kutta integration) +\end{itemize} +\fi \ No newline at end of file