Friday, November 27, 2009

One bone at the time

Some decent progress with RibTools.. the light shaders seem to work. See the nice specular highlights on the airplane model in the picture.

I had a couple of silly problems that threw me off for a few days.
One was the specular highlight. The formula was right, but the specular lobe wasn't right. It turns out, that the standard RenderMan specular power function is actually being multiplied by a factor of 8 or so in PRMan and by some other free renderer that I'm using to check the results (mostly Aqsis).

Another, bigger, problem was getting the light direction right. The "from" and "to" standard shader parameters passed to the light shader as such:

LightSource "distantlight" 2 "from" [ 5 10 -10 ] "to" [ 0 0 0 ] "intensity" [ 0.7 ]

..need to be transformed into the space where the shader is being computed. This is apparently usually the "camera" space and so is that for me, too.

As usual, with these things there are ambiguities. But this time around there was one more potential flaw: the shader compiler 8)
The register allocation was broken. And in a case something like:

a = b - c

..was converted to the VM instruction..

sub.vvv $v6 $v7 $v7

..therefore always producing and "nice" lean 0 value into the destination register ($v6).

Register allocation (or, "register coloring") is a topic on its own which I can't spend time on right now.
Luckily there are no actual hardware limitations, since it's all software. It's my VM and registers are virtual. The limit is in the memory usage not the instruction set.
However, each register can use quite a bit of memory. Varying registers represent all samples being shaded for a certain grid. Practically, this means that a single register could represent 1000 float values.
1K floats (4K bytes) isn't a lot of memory, but with a few of those around, the L1 data cache starts to get trashed for no good reason.
Keeping the number of registers to a minimum is therefore actually critical for performance.

Next, however, I really have to get this micro-polygons sampling going. The term micro-polygon is where the hype is. It's kind of like saying "ray-tracing". Are you doing Ray Tracing or are you doing Micro Polygons ?  ...emmm.
In this case really, it's the REYES pipeline that I'm trying out, shading system included.
It seems to me that those are much more complex and broad topics. While the micro-polygons business is really just about the final steps, where shaded samples are discretized into a grid of pixels.

..still, it will be nice to finally get some anti-aliasing ! ;)
And that should also open the door to motion blur and depth of field (whichever is easier to implement first).

After that, I plan on implementing texture mapping.. wooo !

A running joke has it that I'm travelling through time with my "advances". Apparently I'm still stuck in the 80s !!  ..but as far as I'm concerned, I'm in the 80s in a parallel universe.. not the one about compromising quality for speed (real-time universe) but that about compromising time for quality (the production rendering universe).

..this reminds me of the General Relativity book I've been reading on my Kindle.. ahh !! (BTW, the Kindle 2/International now supports PDF.. too bad I have no time to read gfx papers (^^;)).