Ray Tracing from an arbitrary view point

[asimes]

I realize this is not directly fractal related, but I figured a number of people here probably do this all the time.

I wrote a Ray Tracer for the first time recently and it works fine but it is set up to always look down the z-axis (VPN is always looking down positive z-axis in a left handed system regardless of where the VRP or PRP are). I was trying to think of a good way to generalize this so that the "virtual pixel grid" always faces the viewer but am somewhat stuck. How do people normally go about doing this?

[willvarfar]

(Presuming you are using perspective)

You have a viewing frustum:


You can use an unproject function to generate a ray for any screen coordinate.

Because unproject needs to use an inverse matrix, which is expensive to compute, you likely want to write your own unproject code that re-uses the inverse matrix.  Here's some code you can base it on.  (Warning - it is normal if you are using openGL for matrices to be stored and handled transposed; if everything is not working when copying other's code, simply transpose you matrices and see if that was all it was)

You can speed it up further by unprojecting just four points in screen space - say the four corners - you can then interpolate between them for all remaining points.  (It is normal for the near and far end of the viewing frustum to be flat; if you model the camera differently, and the near and far are curved, then you can still interpolate but spherically).

You will find you get best results by firing multiple rays per screen pixel (look at the supersampling patterns)

[asimes]

Yes, I'm doing perspective. Also, I'm not using OpenGL, I'm just writing it in a Java environment that gives me control over pixels (Processing).

I understand what you mean by interpolating between four points, but the problem I'm having is before that step. Given a point in space and a direction vector, I think I should be able to define the plane that the "virtual pixel grid" is on. Given some VPN (Viewing Plane Normal, which is a vector), how can I make a grid that is perpendicular to that vector?

Also, if the terms I'm using are unfamiliar, here is a diagram I found on Google:


I didn't understand the explanation with inverse matrices, but I think I will need some kind of matrix to rotate a grid in the xy-plane to face the viewer.

Edit: I was planning on using a VRP (A point that is on the plane to define it) and a VPN (The surface normal of the plane) to define the "virtual pixel grid". I'm having trouble making a grid (or four points) that is always perpendicular to the VPN. The viewer would be easily defined by the VPN, it would just be some distance along that vector.

[eiffie]

In the diagram you need to know n (VPN) and either u or v. Calculate the other with a cross product.
You already have something like pr=(dx,dy,dz) - your perspective ray along the z-axis so the new ray would be:
ndx=dot(pr,u)
ndy=dot(pr,v)
ndz=dot(pr,n)

probably

[asimes]

Eiffie, I don't understand (pr, dx, dy, dz?)

Are ndx, ndy, ndz something to plug into a matrix that I would multiply the points of the grid by? A matrix like this?

ndx.x  ndx.y  ndx.z  0.0
ndy.x  ndy.y  ndy.z  0.0
ndz.x  ndz.y  ndz.z  0.0
0.0     0.0     0.0     1.0

Sorry if I'm way off but I've tried a lot of different things and am getting mixed up

[subblue]

To get the direction vector for a pixel on the screen I use something like this (in pseudo code):

Code:

pixelRayDirection(pixelX, pixelY) {
    x = (pixelX - 0.5 * width) / width
    y = (pixelY - 0.5 * height) / height
    x *= width/height

    dir = [x, y, -focalLength]
    
    return normalize(dir * cameraRotation)
}

where cameraRotation is a 3x3 matrix. This is a little trickier to setup. I use this approach whereby I create a rotation matrix for each of the roll, pitch and yaw rotations along the z, y, and x axes and then multiply them all together to get the final rotation matrix.

There are quite a few books on maths for graphics and games developers that are worth reading that will explain various approaches either from an OpenGL view frustum or the more classic ray tracing approach like the above.

[asimes]

Could you explain the rotation matrix part please? I'm working with square pixel grids for now (makes everything easier) and the way I'm making a grid is basically just (pseudocode):

Code:

float left = uMin;
for (numberOfPixels) {
    float bottom = vMin;
    for (numberOfPixels) {
        pixelCoordinates = (left, bottom, 0);
        pixelCoordinates * someKindOfRotationMatrix;
        pixelCoordinates * translateMatrixToVRP;
        bottom += someDelta;
    }
    left += someDelta;
}

The red part is what I don't understand how to do. uMin and vMin are the leftmost and bottommost points of the "virtual pixel grid" before it has been rotated (the grid is in the xy-plane).

Edit: I can't make text in code red :p

This is the line I don't understand how to implement:

Code:

pixelCoordinates * someKindOfRotationMatrix;

[asimes]

Finally got it to work and it doesn't use sine, cosine, or arccosine so hopefully it is fast

There is a small problem that if VPN is the same as VUP it doesn't work. Not sure how to get around this condition but otherwise it works well. I'll explain it incase it is helpful for someone else in the future (I would be happy to hear other methods, this one just works for me).

VRC explanation:
I was thinking in terms of the VRC (Viewing-Reference Coordinate system) which is the diagram I posted above. VPN (View-Plane Normal) is the surface normal of the view plane (which I was calling the "virtual pixel grid" above). VRP (View Reference Point) is a point on the view plane that is needed for reference later. VUP (View Up Vector) is a required vector that is also needed for reference. The axes u, v, and n correspond to the equivalent of x, y, and z but relative to the VRC. Not in the diagram is the PRP (Projection Reference Point) which is where the "viewer" is.

I am assuming VRP is the center of the view plane but this is not always the case for VRCs in general. In implementation I would place VRP where the "object of attention" is. VPN is the direction vector to the "viewer" or PRP. The PRP is some distance along this vector where the distance is user specified (for zooming in / out).

Implementation:
Define VPN as a direction vector and VRP as a vector that is the point where the "object of attention" is. I set VUP as the y-axis (0, 1, 0) but this could be set otherwise.

Define uMin, uMax, vMin, and vMax as the width and height of the view plane from the VRP.

Calculate the u vector as the cross product of VUP and VPN (normalize vectors if necessary).

Calculate the v vector as the cross product of VPN and u (normalize if necessary).

Set a rotation matrix using u, v, and VPN like this:

u.x  v.x  vpn.x  0
u.y  v.y  vpn.y  0
u.z  v.z  vpn.z  0
0    0     0        1

Using a double for loop, create a grid of points centered on the xy-plane with z = 0 (or whatever plane you consider to be the "default" view) using uMin, uMax, vMin, and vMax. As Willvarfar mentioned, just corners could be calculated instead but I haven't implemented this myself yet. His suggestion should be faster. Multiply each point by the rotation matrix and then by a translation matrix that uses VRP's coordinates.

Hopefully this is helpful to someone

[hobold]

There is a small problem that if VPN is the same as VUP it doesn't work.

Don't worry about that too much. In a theoretical sense this cannot be solved (the result is undefined); but for all practical purposes one can always find a workaround.

[eiffie]

For this reason one should NEVER look directly up. If we are living in the virtual reality of some far more intelligent being we may crash.

[asimes]

Ha ha ha, at least it is difficult to ever look up that accurately. What would you see anyway? Everything would be a singularity (I think)