anenigmaticbug / raytracer_in_a_weekend Goto Github PK

A lot of high quality sky-boxes on polyhaven use equirectangular images. It would be nice to be able to use them. Plus, dealing with a single equirectangular image is less hassle than dealing with 6 images for cubemaps.

Textures are a pretty fundamental building block and will allow us to create new types of scenes. Adding textures is also a challenge in "Ray Tracing in a Weekend".

Normal maps will allow us to render more realistic images. Plain Lambertian and metallic (with constant fuzz) materials get boring pretty fast.

We should be able to apply these materials to any object.

This will allow us to add new implementations without modifying the main code every time.

This will be needed for #14.

Not sure how this will impact runtime performance at this point. Right now, in a scene with ~150 randomly placed spheres, most of the time is spent in computing dot products for the ray-sphere intersection logic (the percentage of time will hopefully reduce with #6). So, I am optimistic that the performance hit won't be that significant.

Currently, the camera is configured by the following fields in JSON: pos, lower_left_corner, hz, and vt. Apart from pos, none of them are intuitive. This is because they are meant for quick calculations; not ease of understanding. Contrast them with the fields that are needed to create a camera in code:

Camera::with_options(CameraInitOptions {
    pos: Vec3::new(0.0, 0.0, 0.0),
    look_at: Vec3::new(0.0, 0.0, 1.0),
    vup: Vec3::new(0.0, 1.0, 0.0),
    vt_fov: 30.0,
    aspect: 2.0,
})

We should use the CameraInitOptions fields in JSON too.

For scenes with lots of objects, the raytracer will spend a good chunk of the time performing ray intersections. If we speed this up, we should see a noticeable reduction in execution times.

BVHs (wikipedia, pbrt) are a common approach for ray intersection acceleration.

Currently, we have our own Vec3 and Ray3 types. This has worked well till now. But we should also look into using a proper math library like nalgebra or glam. Why?

• Better performance: These libraries are very well optimized and support SIMD.
• Less code: Till now, we only needed basic vector operations. Once we start working on stuff like transformations, we'll need proper matrices + a lot of new functionality. Implementing it would take a lot of time and the result would not be as optimized as a proper math library anyway.
• Better docs: Using a popular library always has this benefit. It will make it easier to copy code from online resources (blogs, videos, etc).

We might not need to switch any time soon though.

Currently, the sky is just a gradient. This severely restricts the creative possibilities. Adding support for sky maps or sky domes would be pretty cool.

Currently, we generate a random scene every time we run the application. The application should read scenes from config files. This will have the following (obvious) benefits:

• Users will be able to customize scenes without any knowledge of Rust
• We won't need to compile the application for every small scene tweak
• It will be easy to share a particularly nice scene

Each item has its own unique geometry and material. Each material has its own unique textures. This has 2 problems:

1. I have to write code for creating/loading the same thing again and again
2. In case I use the same memory heavy object in multiple places (for eg: using the same 8K texture for multiple objects), memory usage sky-rockets. To confirm this issue, I:
   1. modified the gen_random_balls binary to load a 8192x4096 texture for each randomly placed lambertian ball (108 such balls)
   2. computed the peak memory usage of the binary (slightly over 6GB) via this command:

      $ /usr/bin/time -v cargo run --release --bin gen_random_balls -- --seed 1822 > inputs/random.json
      
      ...
      Maximum resident set size (kbytes): 6127440
      ...

They currently lack the code to compute UV coordinates and AABBs.

I'm thinking of splitting the code into 4 crates:

1. raytracer_core (library): defines all the necessary traits + core logic.
2. raytracer (library): contains basic impls of those traits (for eg: it will contain spheres, planes, etc as geometry impls).
3. raytracer_apps (bin): contains binaries to perform general tasks like validating scene files, rendering scene files, etc.
4. playground (bin): contains custom trait impls (if any), code to create custom scenes and render them.

The idea is that I (or anyone who wishes to dabble with my raytracer) could depend upon crates 1, 2, and 3 and create our own playground crates without bundling every new material, geometry, etc into the main crate. This would be really useful for highly unique scenes that require a ton of one-off stuff.