Thursday, February 26, 2009

Quick update on gfx progresses

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 !

zzzzzzzzzzzzz

3 comments:

  1. As usual, it's interesting reading your posts about 3D, and are also interesting the links you put in. I couldn't dive in them deeply, but I've got some ideas. The rasterization in Nicolas Capens's article seems to be a sort of tile rasterization. One evident optimization is to divide each triangle into two triangles: ordering the vertices by the vertical position and cutting the triangle on the horizontal line passing by the vertex in the middle. Now the new triangles have one horizontal edge, having to test only two edges.
    About forward rasterization, lots to read, but maybee the approach lets you to sample the triangle indipendetly by the pixel grid, so it could be possible do re-use the samples for a few frames if small tris don't vary too much in position and size.
    Maybee I've said obvious things, but I'm not so updated about the latest rasterization techniques....:)

    ReplyDelete
  2. Avtually it is a bit different on at least once piece of 'modern' hardware. It rasterizes from right to left and then changes direction at the end of each line. The triangles are also split across 64 pixel boundaries and not at the middle

    so:
    ............1..2...|
    .........5..4..3..6|.
    .....11.10..9..8..7|.18
    ..13.12.14.15.16.17|.19.20
    ..................64 pixel boundary

    ReplyDelete
  3. Claudio,
    another thing is that rendering is most likely tiled.. so the vertical split would happen at regular intervals (for 32x32 block or so).

    Also, I've heard that probably "hardware" out there uses the Olano-Greer homogeneous scan


    Paul, ...sadly, Blogger comments don't allow <code> nor <pre> tags 8(

    ..anyhow, I guess the "swizzled" order is probably due to improve texture fetching.

    ReplyDelete