santi-7 / render_engine Goto Github PK

The overloaded operator == for the class Matrix cannot be used to compare a Matrix object and a TransformationMatrix object. Since TransformationMatrix extends Matrix, shouldn't this be possible?

Since color is integrated in retVal (adding new values for each light source) it can easily overflow a byte. This could be checked and fixed to the maximum value 255, but then any scene with many light sources could easily end up as a white blob.

In the ray tracer algorithm, if a shadow ray intersects with any shape in the scene, then the light is blocked. But, what happens if that intersected shape is transparent? It shouldn't block the light, but the algorithm doesn't take it into account.

In our current implementation, a plane is representated by a point and the normal vector to the plane. A plane costs 6 floats, three for the point and other three for the normal.

A plane m can be represented with only 4 floats: the normal vector n, and the distance d from the origin, as shown in the following image.

This is the normalized representation of a plane.

A rotation R ∈ SO(3) together with a translation t ∈ R^3 is called a pose. Such pose transformations are of the following form:

Let us assume we have two such reference frames a and b. The transformation Rba Xa + tba transforms a point Xa in frame a to a point Xb in reference frame b. Elements of SE(3) can be written in terms of 4 × 4 matrices:

Given a transformation Tba, the inverse transformation Tab is calculated using the inverse matrix:

Reference: the doctoral thesis Local Accuracy and Global Consistency for Efficient Visual SLAM [Hauke Strasdat, 2012].

How can we calculate this intersection point?

I guess that this intersection point is the nearest intersection of the light of ray with the three edges of the triangle.

And the same question than in Issue #6 : should we draw the triangle in this scenario?

What happens when a ray of light goes directly to a point light? Should we draw this light?

Working with floats (with doubles will also happen), we miss an important precision. When tracing the rays, the pixels calculated are not the exact points. It may be not important, but it makes fail a specific scenario: when a light of ray should lie entirely in a plane.

For example with a default Pinhole Camera and a Plane p with mPoint(0,0,0) and mNormal(1,0,0). The light of ray that crosses the central pixel (0,0,1) should lie in the plane p. But due to this lack of precision, this ray of light has a direction vector (0.00..78, 0.00..123, 0.99..43). This makes the algorithm fail.

Values used in the Intersect methods can be cached, because they don't depend on the light of ray. For example the plane where a triangle lies, and many more.

Suppose we have a Pinhole in (0,0,0), a Plane in (0,0,3) with normal (0,0,1) and a Point light in (0,0,6). The light illuminates the back side of a plane (seen from the camera), but with the current implementation, the light illuminates entirely the two sides of the plane.

If we short-circuit the comparisons, do you think the method would be faster? When a false is found, it automatically will end. But against, we have an extra check condition for each ==.

bool operator==(const Matrix &m) const
{
    return mA == m.mA & mB == m.mB & mC == m.mC & mD == m.mD &
           mE == m.mE & mF == m.mF & mG == m.mG & mH == m.mH &
           mI == m.mI & mJ == m.mJ & mK == m.mK & mL == m.mL &
           mM == m.mM & mN == m.mN & mO == m.mO & mP == m.mP;
}

Should we draw the plane, when rays of light lies entirely in it? This is, the focal point of the camera is a point of this plane.