Semester 1, Week 04‐05 Development - 62firelight/manimRT-490 GitHub Wiki

Depicting a Camera

A key component of illustrating ray-tracing concepts is the ability to depict a camera.

How this camera is depicted can vary. One example of how a camera might be depicted can be seen in Figure 1, which shows the default scene that is generated at run-time by Blender, a 3D modelling program (insert reference to something here?).

Figure 1: The default scene in Blender 4.0 that consists of a camera, light source and cube (looking clockwise from the left side).

There are 4 parts to this Blender camera -- the projection point, the frustum, the image plane, and an arrow. This version of a camera is fairly simple and can be recreated fairly easily in Manim using its built-in objects (reference?). Figure 2 shows a breakdown of the camera. Note that the arrow from the Blender camera has been omitted for the sake of simplicity, and may be added later in the future.

Figure 2: A simple camera broken down into its 3 components, along with a corresponding Manim object that could be used to represent the component in parentheses.

Camera Implementation

Camera.py has a function, drawCamera that takes in two optional parameters -- a list representing the coordinates of the projection point and a boolean value dictating whether a number plane will be used for the image plane. These parameters default to [0, 0, 5] and True, respectively. The location of the resulting camera ultimately depends on the coordinates of the projection point, as the two other components will be created based on those coordinates. If the number plane is not used, then a rectangle will be used rather than an image plane grid (similar to the Blender example in Figure 1).

The drawCamera function returns a Group object, a Manim object made up of different Manim objects, which consists of the three components discussed in Figure 2. This Group object can be easily translated and rotated using the relevant Manim functions as if it were its own Manim object.

Animations and Discussion

Figure 3: An animation produced using the default parameters of the drawCamera function that shows three rays shooting out from the projection point into the center of the camera's first three grid cells (i.e., pixels).

Figure 3 showcases an animation created with the drawCamera function. The rays point towards specific coordinates in the grid that were derived from trial-and-error, and so it would be ideal if those coordinates could be generalized. For example, this generalization could come in the form of a drawRay function for the camera that would automatically know the coordinates of the grid cell (or pixel) for the ray to shoot through.

Another aspect to consider is the size of the grid and whether it should be dynamic (i.e., the grid width and height can differ based on parameters that are passed in). The current camera implementation uses a fixed 6x6 grid, the size of which would not be very practical for an actual ray-tracer as rendering an image using that camera would produce an image that is too low-quality. It may be better to have a bigger grid that is more representative of a typical screen resolution. It does not necessarily have to be as big as 1920x1080 for example, but it should at least be big enough to look like it belongs to a ray-tracer that can produce a sufficiently detailed image. It would also be easier to have a fixed grid for now, as having this fixed grid would make the aforementioned drawRay function considerably easier to implement.

Figure 4: An animation produced that shows the camera as it is first translated along the Y axis and then rotated along the X, Y, and Z axes.

An interesting result was witnessed during the creation of Figure 4. The rotation of the camera (i.e., a Group object) seemed to vary slightly based on the frame-rate that the animation was rendered at. For example, the camera would not rotate a full 360 degrees or could potentially over-rotate. However, this indeterminate behaviour does not seem to occur if the run_time parameter of the animation is set high enough. It would be preferable if the camera rotated consistently every time, as inconsistent rotations could lead to potential frustration when rendering animations in the future. Camera transformations are not necessarily required when illustrating ray-tracing concepts, so this inconsistency could be overlooked in the future.