For many applications, opponent process color works better than RGB or other common graphics spaces. Opponent color encodes a greyscale channel along with two color channels that range red to green and blue to yellow. A simplified version is:

V = (R+G+B)/3

RG = R-G

BY = B - (R+G)/2

Note that the second two channels run -1 to 1.

## Monday, November 27, 2006

## Thursday, November 23, 2006

### Moore's Law and Ray Budget

Moore's Law states the number of transistors on a chip will rise exponentially, and this has happened fairly steadily. A variation relates to performance, which for CPUs has doubled every two years or so. Another variation is that CPU performance per dollar has doubled every 18 months or so. In practice, the cost law implies you can buy more and better CPUs as time goes on. Finally, screen resolution has been on its own curve that doubles the number of pixels every 10 years or so.

What does this mean for rendering? About 27 years ago Turner Whitted ray traced a 640x480 image at about 1 ray per pixel. For the same money budget we can get about 18 doubling of performance, but we have 3 doublings or so in the number of pixels. So now we should be able to do 2.5 million pixels, each with 2^15 = 32k rays.

A caveat is that we want to use more objects. Fortunately, performance in practice is related to the log of the number of objects.

What does this all mean? The rendering community should raise its intuition for how many rays per pixel we can use in practice. In academics, where it is good to think 5-10 years out, we should be looking at another 6 doublings or so, and a million rays per pixel should then be reasonable.

Another way to compute ray budget is to assume 30Hz interactive ray tracing will become practical at 1 ray per pixel. For an 8 hour batch run using the same infrastructure, you can send 30*60*60*8 = 864k samples per pixel.

Bottom line: batch rendering algorithms should assume a million samples per pixel or so are available, and this should make new algorithmic possibilities practical.

What does this mean for rendering? About 27 years ago Turner Whitted ray traced a 640x480 image at about 1 ray per pixel. For the same money budget we can get about 18 doubling of performance, but we have 3 doublings or so in the number of pixels. So now we should be able to do 2.5 million pixels, each with 2^15 = 32k rays.

A caveat is that we want to use more objects. Fortunately, performance in practice is related to the log of the number of objects.

What does this all mean? The rendering community should raise its intuition for how many rays per pixel we can use in practice. In academics, where it is good to think 5-10 years out, we should be looking at another 6 doublings or so, and a million rays per pixel should then be reasonable.

Another way to compute ray budget is to assume 30Hz interactive ray tracing will become practical at 1 ray per pixel. For an 8 hour batch run using the same infrastructure, you can send 30*60*60*8 = 864k samples per pixel.

Bottom line: batch rendering algorithms should assume a million samples per pixel or so are available, and this should make new algorithmic possibilities practical.

## Monday, November 20, 2006

### Outer product

Given two three vectors the "inner" product is:

...........|X|

[x y z]|Y| = [xX + yY + zZ]

...........|Z|

Which we use all the time (dot product). There is

also an outer product:

|x|.................|xX xY xZ|

|y|[X Y Z] = |yX yY yZ|

|z|.................|zX zY zZ|

I'm not sure this is useful for anything in graphics, or even what this thing is operationally.

...........|X|

[x y z]|Y| = [xX + yY + zZ]

...........|Z|

Which we use all the time (dot product). There is

also an outer product:

|x|.................|xX xY xZ|

|y|[X Y Z] = |yX yY yZ|

|z|.................|zX zY zZ|

I'm not sure this is useful for anything in graphics, or even what this thing is operationally.

### More on bilinear patch intersection

Because ray - BL patch involve solving a quadratic, I am concerned there will be "cracking" issues where rays sneak between adjacent patches. A cure for that would be to do four "ordered edge" tests on the ray and the patch edges. More information on such tests in in Andrew Kensler's and my recent triangle intersection paper. Note that Pluecker coordinates are not needed-- the easier to comprehend (for me) triple product test will do the job.

## Friday, November 17, 2006

### Ray tracing bilinear patches

I'm going to try to reimplement the displacement map method I did with Brian Smits and Mike Stark a few years ago. A key part of that method is intersecting bilinear patches. Given a ray o+tv and a patch with vertices p00, p01, p11, and p10 we have

o + tv = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

This is three equations (x, y, and z) and three unknowns (t, u, v). The way Brian and I solved this was to eliminate t by using 2 of the equations and then solve the uv system directly. A similar approach is used in Shaun Ramsey et al.'s jgt paper. This has always been unsatisfactory to me because it chooses an arbitrary ordering of the dimensions. Perhaps a numeric solution would be more robust?

Another possibility is to use Kajiya's old trick. Consider the ray as the intersection of two planes

(p - p0) dot N0 = 0

(p - p1) dot N1 = 0

If you substitute

p = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

into both the plane equations above then you get two equations in uv of the form:

Auv + Bu + Cv + D = 0 (1)

auv + bu + cv + d = 0 (2)

If you solve one of those for u and then plug it into the other, you get a quadratic in v. That leaves four possibilities of what to do first:

solve (1) for u

solve (1) for v

solve (2) for u

solve (2) for v

There is also a degree of freedom for which planes to use. In any case seems more stable than the three equations, 2 unknowns method above.

o + tv = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

This is three equations (x, y, and z) and three unknowns (t, u, v). The way Brian and I solved this was to eliminate t by using 2 of the equations and then solve the uv system directly. A similar approach is used in Shaun Ramsey et al.'s jgt paper. This has always been unsatisfactory to me because it chooses an arbitrary ordering of the dimensions. Perhaps a numeric solution would be more robust?

Another possibility is to use Kajiya's old trick. Consider the ray as the intersection of two planes

(p - p0) dot N0 = 0

(p - p1) dot N1 = 0

If you substitute

p = (1-u)(1-v)p00 + u(1-v)p10 + (1-u)v p01 + uv p11

into both the plane equations above then you get two equations in uv of the form:

Auv + Bu + Cv + D = 0 (1)

auv + bu + cv + d = 0 (2)

If you solve one of those for u and then plug it into the other, you get a quadratic in v. That leaves four possibilities of what to do first:

solve (1) for u

solve (1) for v

solve (2) for u

solve (2) for v

There is also a degree of freedom for which planes to use. In any case seems more stable than the three equations, 2 unknowns method above.

### Image formats for realistic rendering

It is remarkable to me that there is no accepted standard for high dynamic range images that is based on CIE standards. Such a format should support XYZ and scotopic luminance V. A big dump with four floats per pixel would work fine, although of course more compressed formats are certainly straightforward. If anyone is aware of such a format that programs such as photoshop can read out of the box, please let me know.

## Monday, November 13, 2006

### How long before interactive ray tracing is on the desktop?

Solomon Boulos and friends in our group at Utah have their ray tracer going about 1 frame per second on one core of a 2GHz Opteron 870 with one ray per pixel at a million pixels. This is with full shadows and reflections so is slower than a lot of the numbers you see in the literature. For NTSC resolution (640x480) that would be more like 3-4 frames per second. So we'd need about 8 of those cores for fluid motion. So we are right on the threshold for such low resolutions. If Intel comes through with its 60 core chip, and ray tracing maps to it, then HDTV resolution and some multisampling should be straightforward. The Cell is also a possibility as shown by Carsten Benthin and his collaborators in their recent papers. We could get ray tracing even sooner if an ASIC is built. I don't see why a game box based on ray tracing would not be feasible now.

Subscribe to:
Posts (Atom)