"Samuel B." <stb### [at] hotmailcom> wrote:

> (On a related note, I've been wondering how difficult it would be to write a
> raymarcher using POV-Ray functions.)

Pigment patterns are just functions that are evaluated based on <x, y, z>.

So, if we had "functions" like they have in Shadertoy (which are more macros or
algorithms) then I would imagine that you'd just write a simple raymarcher
(Martijn has a nice video on this, to render a sphere) and have the resulting
col be the 0-1 function result that governs the pattern color value at that
point.

The problem, is that at render time, all of our functions have been parsed and
are immutable - we have no way to loop an arbitrary number of times until we
reach an exit state and then return the final function value.  That would be a
source-code level thing.

However maybe Tor Olav has a clever trick up his sleeve....  (*)

But we can always do it the work-around way and use an orthographic camera and
box {} or a pair of triangle {} objects to appropriately color our pixels, and
then just write a "regular" scene to place colored objects in the scene - which
then get rendered by raytracing...  :D

Blackle Mori had an interesting video about some raymarching tricks that help
get some better results in complex scenes.
https://www.youtube.com/watch?v=I8fmkLK1OKg

(*) Potentially, we could use a macro to assemble a highly nested function,
where the macro nests functions until a certain macro bailout value.   Then,
although it would have to evaluate all of the nested functions every time, for
every pixel, I think that a judicious use of select () could fast-track the
nested function evaluation once the surface is "found". (just add 0 or multiply
by 1, or whatever the thing to do would wind up being...)  I'd have to puzzle
this out some more.

Definitely something I have been letting bounce around in my head for quite some
time as well.

- BW

Post a reply to this message