I changed the scope of the ribparser project and actually replaced it with a new, more ambitious one, called RibTools.. ..only slightly more ambitious.
The age of parsing is past for now, and it's finally time for some "action". Following the Production Rendering book, I've implemented a basic state machine for a RenderMan scene and started rendering out some very basic primitives: cylinder and cone. I'm forwarding the rendering to OpenGL, using uv values for coloring.
OpenGL is used for convenience and only as a 2D renderer with Z-Buffer, because all the transformations are done following the RenderMan state machine that I've implemented.
The output is currently very crude, but it's nice to see pixels more or less in place.
It feels a bit like reverse engineering into the first outputs of a console emulator, only that I haven't really done that much work so far. In fact, there would be a huge work ahead just to get all the geometry to render properly, and then another indefinite amount of work to get some shaders going and then more to actually get performance, and texturing properly with the necessary quality... Basically, to write a proper renderer there would be just too much work for one person in his spare time !
Reading Production Rendering, one thing that bothers me as a real-time graphics developer, is the slow pace at which the REYES approach seems to deal with geometry.
For one thing, much effort is spent towards getting very finely tessellated quadric primitives: spheres, cones, cylinders.. all primitives that in their perfect form are hardly useful for photo-realism.
Perhaps subdivision surfaces, bicubic patches and NURBS are more common. But it all really comes down to what's in input: which CG studios use what and to which extent.
Ultimately, if I find a bicubic patch in input, I really have to deal with it, but if I dive into the REYES system from the start, then I may end up with something that works but that it's not very efficient.
The REYES approach is all about estimating the area that a certain primitive covers and to tessellate appropriately. Tessellation can't be avoided, but doing that every frame seems like a waste of CPU cycles (though it may turn out that it's not so heavy when compared to hiding and shading). A different framework instead would allow for caching tessellation at least for a few frames, while some cached tessellated data is still sufficient.. rather than working out the best fit at every frame.
I guess that for now I'll be happy to get all the geometry for the test image out with a fixed subdivision level, and then I'll see about the next step.
Also the winter holidays are almost over and I'm not sure how much free time I'll have once I get back in the office... I must say that holidays are addictive !