"scott" <sco### [at] scottcom> wrote:
> MCPov allows you to do exactly that, using a simple "mc_reflect" keyword in
> the finish block.  It takes parameters for the number of rays to spawn and
> the "burriness" of the reflection:

Neat!
I usually resort to micro-normals. This method gives a high degree of control,
but results are not perfect: it's computationally expensive to smooth out the
roughness, and surfaces always appear 'bitty' with adaptive anti-aliasing, the
only workaround being to force more rays with focal blur, or to render a larger
image size than is finally needed, then re-sample down.

When thinking about prospective extensions to POV-Ray, I always think "How would
this 'exception branching' affect the speed of the core renderer for all the
other functions?"  The decision of whether to implement a specific feature has
to rely on the answer to the questions:
a) "Will scene rendering time improve for most users for most scenes?" and
b) "Will the quality of the render be better than it can currently be?"

If the answer to both is "yes", then there's a fairly good case for inclusion.

As an extension to the above questions, I also wonder how fast a stripped-down
POV-Ray would be, if all the conditional branches (that are not relevant to a
scene) are removed from the code. The natural end-point of this line of thought
it 'JIT compilation', which would allow more 'specialisations' to be included
without affecting generic performance - and this is where the seemingly opposed
approaches (generic outsourcing to implicit shaders, and optimising for
specialised needs) need not be opposed! :o)

p.s. I speak as if I have contributed to POV-Ray code; I haven't. This is just
my 'developer brain' applying to POV-Ray.

Post a reply to this message