> You are free to implement such a thing but be warned: there will hardly
> anyone be interested in a POV-Ray feature for scanline rendering that only
> supports certain specific geometry definitions that are not compatible to
> raytracing and therefore are not usable in a 'real' POV-Ray render.

I didn't plan on supporting any scanline-only
primitives, if that's what you meant. My prototype
will support a subset of existing POV primitives,
so that whatever the scanline system can render,
the raytracer can render.

In that spirit, however, I agree that there
will be those who will not use a renderer that
cannot reproduce all of POV-Ray's existing
effects (i.e., true drop-in renderer substitution).
This is understandable for those who have
existing scene files and are looking to improve
render times on them in their final rendered sense.
Improving the existing raytracer provides more
return for that audience.

The first benefit, I think, will be in previewing.
Unlike VOP, my previews will be integrated directly
into WinPOV's render window and be available
by simply choosing a menu command. The preview
will render during parsing, so best case, a scene
could render in as much time as it takes to parse.
A camera object will, however, need to be
defined ahead of all other objects. I could preflight
the .pov file looking for the last camera statement,
but that would lengthen parsing times.

Shaders for the scanline system pose a greater
raytracer-compatability challenge (although BMRT
proves it can be met). I'm personally interested
in deploying shaders as DLLs, for performance
reasons, but that would understandably be a
philosophical departure for POV-Ray.

Ray

Post a reply to this message