Lab 3: Using a Pinhole Camera Solution

$30.00 $24.00

Introduction The purpose of this lab is to continue building our ray tracer by adding a pinhole camera as discussed in the lectures. We will also discuss the way the code will be designed, as well as setup the basic interfaces that future classes will be based on. Since we are going to be ray…

5/5 – (2 votes)

You’ll get a: zip file solution

 

Description

5/5 – (2 votes)

Introduction

The purpose of this lab is to continue building our ray tracer by adding a

pinhole camera as discussed in the lectures. We will also discuss the way the

code will be designed, as well as setup the basic interfaces that future classes

will be based on. Since we are going to be ray tracing more complex scenes, we

will also discuss an implementation for random sampling.

We will first discuss the `Random` class contained in Atlas as it will be the

backbone of the random sampling system. Then we will discuss the design for our

code moving forward, and finally we will implement the pinhole camera.

The `Random` Class

Atlas provides a random number generator, which is located in the header

`atlas/math/Random.hpp`. To declare a random generator, we will use the

following:

“`c++

atlas::math::Random<float> engine;

“`

Random sampling relies on generating random numbers in the range [0, 1]. We will

therefore use the corresponding function:

“`c++

float sample = engine.getRandomOne();

“`

Ray Tracer Design

In order to simplify coding, we will define a common interface that all objects

must implement in our code. In particular, we will define the following

interfaces and entities:

* `Shape`: this will be the interface that all of our primitives will use. It

must contain a function to intersect with a ray, as well as have a way of

setting and retrieving the colour of the object. All classes inheriting from

`Shape` must define two functions `hit` and `intersectRay`. `hit` has the

same definition from Lab 2. `intersectRay` is a helper function to `hit`,

which is used to determine if the ray intersects the entity. The `ShadeRec&`

given to `hit` must only change the data (both `t` and `color`) if the ray

intersects and the computed `t` is less than the `t` in the `ShadeRec&`.

* `Camera`: this will be used by the different types of cameras we may want to

use. The main special function for this camera will be a function to render

the scene, as it is more convenient to move the dual loops into it so that all

computations can be done in camera space. In addition, we will add a function

to set all the relevant parameters as well as to compute the UVW-space.

* `Sampler`: this will be the interface that all multi-sampling technique

implementations will use. A class inheriting from `Sampler` must call

`generateSamples` which will create data used to sample a pixel. It will also

provide a function used during rendering to `sampleUnitSquare`, which will

return sample data to offset the pixel.

* `Sphere`: this class is a derived class from `Shape` and it fully implements

`hit` and `intersectRay`. Read those two functions to prove to your self that

the closest `Sphere` to the `Camera` will have its color used by the sample.

* `World`: this struct wraps a number of core pieces of data including the scene

objects, `Sampler` used, image vector, background color, and image height/width.

With these interfaces defined, we can begin implementing the ray tracer. First, however,

some C++ information you’ll need for this lab.

C++ Object Oriented Programming

C++ is an object oriented programming language, and as such supports OOP features

like inheritance, polymorphism, and abstract classes. We will leverage OOP

features in our ray tracer to extend support to multiple shapes, cameras, and

sampling techniques. The following is a basic example of OOP in C++ for reference

cribbed from [CSC116 Lab 8](https://github.com/billbird/116f19_Labs/tree/master/Lab08/solution_code):

“`c++

#include <cmath>

class Shape2D

{

public:

Shape2D() = default;

virtual ~Shape2D() = default;

virtual float area() const = 0;

};

class Rectangle : public Shape2D

{

public:

Rectangle(float height, float width) :

height_{ height }, width_{ width }

{}

float area() const

{

return height_ * width_;

}

protected:

float height_, width_;

};

class Square : protected Rectangle

{

public:

Square(float side_length) :

Rectangle{ side_length, side_length }

{}

float diagonal_length() const

{

return height_ * sqrt_2;

}

private:

float sqrt_2{ std::sqrt(2.0f) };

};

“`

Inheritance

Inheritance is the concept that classes, _derived_ classes, can be extended

from another class, the _base_ class. The derived class will have the functionality

of the base class along with functionality unique to the derived class.

In C++, there are three inheritance modes `public`, `protected`, and `private` which

correspond with the three access specifiers, [discussed in Lab 2](https://github.com/marovira/csc305_spring2020_labs/tree/master/labs/lab02_sphere#c-classes-and-structs).

The inheritance mode a class derives a base class from defines the level of access

the derived class has to the members of the base class. In the example `Square` has

`protected` inheritance of `Rectangle`, so it has access to the data member `height_`

(see `diagonal_length`). The syntax for inheritance in C++ is:

`class <derived class> : <access specifier> <base class0>, … , <access specifier> <base classN>`

The `<access specifier>` may be omitted in which case the default inheritance mode

is `public`. As you can see in the syntax, C++ supports multiple inheritance allowing

a derived class to have multiple base classes.

Polymorphism

Polymorphism is the behavior in which a derived class may be used as in instance of its

base class(es). The following code example shows how polymorphism and the _is a_ relation

can be used:

“`c++

#include <iostream>

#include <memory>

#include <vector>

// more on std::shared_ptr in a following section (conceptually treat it as a pointer)

std::vector<std::shared_ptr<Shape2D>> shape_vec{};

for (size_t i{ 0 }; i < 4; ++i) {

for (size_t j{ 0 }; j < 4; ++j) {

if (i == j) {

shape_vec.push_back(std::make_shared<Square>(Square{ i }));

} else {

shape_vec.push_back(std::make_shared<Square>(Rectangle{ i , j}));

}

}

}

for (auto const& s : shape_vec) {

std::cout << s.area() << ‘\n’;

}

“`

In the example because both `Rectangle` and `Square` are derived from

`Shape2D`, both can be pushed into the `std::vector<std::shared_ptr<Shape2D>>`.

However, the usable functionality of the objects in the vector are restricted

to the functionality of `Shape2D`. Due to C++ symantics, use of polymorphism

must be performed through pointers rather than the concrete objects. Polymorphism

is not just theoretical flourish, it is critical to designing extensible systems.

Abstract Classes

Not all classes defined in a C++ program may be instantiated into a concrete object.

Some classes exist for the purpose of defining a set of functionality which deriving

classes must implement, these are called _abstract classes_. By definition, an

abstract class is any class with one or more pure virtual function members. A

_pure virtual_ function member is a function member which is only a function

declaration with no associated definition. Pure virtual function members take the form:

`virtual <return type> <function name>(<params>) <cv-specifier> = 0;`

The `Shape2D` class is an example of an abstract class, because the `area` function

member is pure virtual. A consequence of this is that `Shape2D` may not be constructed

in a program. Instead, classes, like `Rectangle`, may inherit from `Shape2D`. All

deriving classes may be accumulated and used regardless of the type of the base

class (see the polymorphism example).

Alongside pure virtual function members, there are also _virtual_ function members.

The difference between the two is that a virtual function member has an associated

definition, which may be overridden by deriving classes (where non-virtual function

members can not).

Memory Management with `std::shared_ptr`

How memory is managed in C++ is one of the primary differences between the C++ and

a language like C. In modern C++, raw pointers should _never_ be used. Instead,

[_smart pointers_](https://en.cppreference.com/w/cpp/memory) and [_RAII_ techniques](https://en.cppreference.com/w/cpp/language/raii) should be used to guarantee leak free programs

while having the benefit of no runtime garbage collection all while running on the

bare metal CPU.

A smart pointer is a class which is responsible for managing the lifetime and access

to some resource, called the _managed object_. For the purposes of this lab we’re

concerned with [`std::shared_ptr`](https://en.cppreference.com/w/cpp/memory/shared_ptr),

which maintains shared ownership to its managed object. A `std::shared_ptr` allows a

programmer to share ownership of an object across a system with the guarantee that the

managed object will not be destructed until no more references to the object exist.

The following code example show the basic usage of `std::shared_ptr`.

“`c++

#include <memory>

int main()

{

// constructs std::shared_ptr<int> object which has no managed object

std::shared_ptr<int> sp0{};

// std::make_shared allocates and constructs a managed object of type int

// sp0 is then provided the managed object

sp0 = std::make_shared<int>{ 1985 };

{

// creates a new std::shared_ptr with the same managed object as sp0

std::shared_ptr<int> sp1 = sp0;

// the managed object’s value is change (this change is visible in sp0)

*sp1 = 2020;

// on exit of this scope sp1 is destructed, but the managed object is not

}

// sp0 is destructed, as well as the managed object

return 0;

}

“`

For more information on `std::shared_ptr`, other smart pointers, and memory

management differences between C++ and C, have a read of the [CSC116 Lab 9](https://github.com/billbird/116f19_Labs/tree/master/Lab09) writeup.

Implementation

With the exception of the Pinhole camera itself, much of the other code should

be very familiar from assignment 1. Primitives like `Sphere` must be converted

to inherit from the interface `Shape`, and then must be used in a polymorphic

way (`std::shared_ptr` will be needed for this).

The `Sampler` interface is defined in a way to be easy to use in the rendering

step. Within the rendering loop over the image, it simply requires calling

`sampleUnitSquare` which returns a `Point` which will be added to offset the

pixel. Afterward offsetting the pixel and creating a ray from the sample point,

you’ll check for hits on the scene objects.

The `hit` function defined by the `Shape` interface should be passed a `ShadeRec&`.

This object is updated only if the `ray` hits and the computed `t` is less than

existing `t` in the `ShadeRec&`. The update step replaces the `t` and `Colour`.

At the end of each sampling, the `Colour` should be aggregated, such that after

sampling is finished the `Colour` of the pixel can be taken from the average color.

You may find the interfaces initially tedious to get working, but these structures

will simplify future assignments and labs and allow you to create a more extensible

ray tracer supporting many primitives, samplers, and cameras.

Note: for faster render times, in Visual Studio change from “Debug” mode to “Release” mode.

On completion of this lab, you’ll be able to move around the scene rendering different

perspectives like the following pictures:

![Initial Position](images/raytrace0.bmp)

![Moved Camera](images/raytrace1.bmp)

Lab 3: Using a Pinhole Camera Solution
$30.00 $24.00