For an explanation of rendering concepts, please click here.   July 29, 2003 I've started a new open source renderer called Synthesia, which will contain the rendering technologies currently inside Leveller. The Leveller shader plug-ins will be phased out and moved to Synthesia as well. June 7, 2003 OpenGL patch source code released. Just click here to access. June 5, 2003 Got sphere objects wireframing in the OpenGL preview, and the FOV error is much reduced. The picture shows what a render looks like when it's partially complete: the final version overwrites the wireframe. June 4, 2003 So far, so good. I've got the render window setting up an OpenGL render context and wireframing the bounding boxes of the scene's objects. Here's how it looks while parsing, and then after raytracing: The OpenGL view angle is a little off (the FOV looks a little wider), and the ground (an infinite plane) didn't show up (for pretty obvious reasons), but the proof of concept is off to a good start. The wireframing, as one would expect, appears fast. For a test, I tried rendering a scene with 2,000 objects, and their bounding boxes just rip into the window in about two seconds or so. June 3, 2003 Time to customize POV-Ray. I started yesterday by making a new build configuration that defines a preprocessor directive DAYLON so that I can build both official and unofficial versions. When I need the custom functionality, it just goes into an #ifdef DAYLON ... #endif wrapper. Spent about an hour mapping out the call stacks for the render loop and understanding the functions. Fortunately I remembered some of the earlier work when hacking in a custom heightfield shader last year. POV is multithreaded, so it helps to build a clear picture of how the render thread and the main thread work, and which functions each of them calls. When you hit Alt-G, for example, the app's main window proc calls a function that creates the render thread, and then that thread's entry point starts off a bunch of nested calls: render_thread() WIN_Povray() povray_render() FrameLoop() FrameRender() Parse() ParseFrame() --> Loads up the scene geometry WIN_Display_Init() Got POV-Ray's render window to appear before it starts parsing (normally it appears after that stage, which by then the scanline renderer will have finished). For a test, I had each parsed object's bounding box printf'd to the render window. Hooked into POV's Link_To_Frame routine to determine which objects are actually placed scene geometry as opposed to components for other objects. For scanlining, we want to immediately render/discard the former and persist the latter. POV is a lot of code. It's big. You gotta respect it. When in doubt, stop and study the code some more. If nothing else, I'm probably going to wind up as some kind of expert on this program's internals. I'm taking notes, oh yeah. My next goal is to project the bounding boxes of placed scene objects into the render window and draw them in wireframe. This will let me know if I'm actually getting the right objects and if they're being projected correctly. Can this mad scheme actually work? In theory, sure. In practice, only a handful of primitive types will be supported. June 2, 2003 Today sort of culminates a lengthy discussion on the povray.org "general" newsgroup about adding scanline rendering features to POV-Ray, the popular free raytracer. One of the important upshots is that I'm going to prototype these features over the next few weeks to see how well they perform and what benefits they provide. I've added this page to the website to document the process. This is easier than trying to sort it out from the worklog, which documents any event. Before I continue, I'll show some images from Leveller's experimental scanline renderer, to familiarize you with what the software is doing. The above was one of the test renders from my latest benchmarking of deferred texturing. It took 1 min 7 seconds to draw on a 633Mhz Celeron (no antialiasing). It creates the textures using two Z-buffered displacement shaders: a fractal subdivider for each heightfield cell, similar to Terragen and WCS, and a fractal "cubeflake" to simulate rocky debris. The detail setting is 4, meaning that the cubeflake won't draw any cubes smaller than four screen pixels. If you look closely at the picture, you'll see the cubes. They are each randomly rotated, so it might not be too easy. The color comes from the heightfield's existing colormap. Relighting is near-instant thanks to the Z-buffer. After the first render, this image below took only one second: This is what the regular OpenGL version of the scene looks like, before rendering: This is what the renderer looks like while it's working. I have it maintain the projected bounding box of whatever triangles have been drawn within a heightfield row, and then blit that to the window. Sometimes, the rows are very curvy and their bounding extents large, so the window gets cleared early. I used to blit smaller boxes containing each heightfield cell, but it was slowing things down too much. One advantage of scanline rendering over raytracing is that objects draw along their form, so even early on you can get a feel for what the image will be like. It's also fun to watch, until the novelty wears off. You can get an idea of how the drawing process works because objects are emitted in drawing order. So what's the deal with POV-Ray? While a renderer might be useful inside Leveller, it's even better outside of it, because then people can use it for other projects. A renderer is also a complicated piece of technology that is better if numerous other people develop and maintain. Since POV-Ray already has powerful scripting facilities and is popular, I thought it would be neat if POV-Ray could do scanline rendering. At the very least, one could preview scenes while they parse, and in only a little more time than it takes them to parse.