hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Samuel B." <stb### [at] hotmailcom> wrote:
> ...
> > I hope a future version of POV's SDL more closely resembles GLSL or other
> > languages, and gives us more access to lower-level data. At the very least, I'd
> > like to have proper swizzles and maybe a unified approach to definitions (the
> > function/macro divide is huge sometimes).
>
> Yeah - the shaders are all compiled, so it's more coding / writing algorithms
> rather than trying to shoehorn an algorithm into daisy-chained mathematical
> functions.

slightly different angle / $0.02.  personally would like to see POV-Ray make use
of and or "converge" capability-wise in direction 'FreeWRL'.
<https://freewrl.sourceforge.io/>


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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.

I think it is possible. A while back, I made a scene in POV-Ray (possibly called
MSet+), which was an escape time fractal using functions. It involved defining
and un-defining functions in a loop. The same concept could probably be used for
a raymarcher.

> 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

I just posted something similar here:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.64d427081961efb7f8c47d526e741498%40news.povray.org%3E/

It's slow to parse, but it's an example of one way it can be done. (It's not
ideal... It replies on parsing before rendering, whereas a purer functional
solution would not have much parsing overhead at all, wouldn't require a
resolution to be defined, and would have less of a memory requirement.)

> [...]
> (*) 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.

Yeah, I figured select() would be involved somehow.

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

It's possible, I know it is :D

Sam

Post a reply to this message