It's almost 4 AM but I really need to update a little !
About RibRender: I started focusing on shaders. As usual the book Production Rendering helps a lot, but I'll have to mess around with implementing the whole thing before I can really understand what's to be understood (it doesn't help that I never used RenderMan or written any shader for it).
Right now I'm less worried about compiling shaders and more about handling parameters and variables in the context of the RenderMan state machine.
At work, as usual, I'm busy with things to do (keep developing the runtime and the graphic engine and some basic GUI for the more artsy coworkers 8), but also I've been working on another engine, one meant for geometry processing (sounds fancier than it is).
I've extended it to bake light.. I want to be baking my own lighting because that way we can shift all that heavy work to the build machines and because it will be easier to integrate with the real-time portion of things (and also because I can ! 8P).
My first goal is to get occlusion precalculation.. and I got that, only it's still far too slow (exponential complexity in nature !).
I use hemicube rendering to calculate occlusion. On this alone there is much that can be said, but I'll leave that for the future.
Anyhow, I decided to render hemicubes with a software renderer, because that's where custom rendering really kicks in. Specifically, render targets are really only 128x128 or even 64x64.. and in those cases one ends up with very small polygons ! And the resulting hemicubes (lots of them) have to be downsampled to one value that has to be usd again by the CPU.
About rasterizing fast small polys, I did quite a bit of research. I started with the usual Graphics Gems' PolyScan from Paul Heckbert. Then settled for the edge equations approach (see this easy to plug code).
But while doing research I found an interesting paper (PDF) that promotes forward rasterization as more efficient than "non-foward" rasterization and with better anti-aliasing. This is somewhat close to the REYES approach, but more focused on efficient rasterization of small primitives... something that I've been wanting for a long time when thinking about hemicube rendering.
Another interesting thing that came up is an old article from Michael Abrash about the game Quake (it was a big deal at the time). Specifically towards the end it says how smaller triangles are rendered with some crude but fast approximation (notice that that, next month Michael Abrash has a lecture at 2009 GDC about Larrabee's instructions = software rendering 8)
In general the big problem with triangles is really the "setup" or rather, going from 3 vertices to placing the first pixel in the buffer... facking polygons !