A new 'pattern_modifiers' keyword continuing work started in the threads:

http://news.povray.org/povray.beta-test.binaries/thread/%3C5da21410%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5dab3f55%241%40news.povray.org%3E/

We have since v3.5 a vturbulence parse time function. We have too the 
existing pattern { } wrapper - though as a function wrapper, especially, 
its usefulness is limited. The former handles only turbulence the latter 
only returns the resulting pattern value at points in space.

What's missing is a way to access the x,y,z vector result of all the 
modifiers a pigment / pattern might employ. So adding: function { 
pattern_modifiers {} }. As something function enabled, it's usable at 
parse and render time.

The general idea is to set up a real - or dummy - pattern/pigment 
defining a collection of modifiers. A collection of warps, turbulence 
and transforms. Then pattern_modifier {} grabs just the result of those 
operations for a given point returning the function/pattern space 
adjusted x,y,z values. The usage is something like:

#declare FnHelix1_5p = function {
     pattern_modifiers { Pigment00 }
}
#declare FnHelix1_5 = function (x,y,z) {
     FnHelix1_5c(FnHelix1_5p(x,y,z).x,
         FnHelix1_5p(x,y,z).y,
         FnHelix1_5p(x,y,z).z)
}

for functions. Use in user space requires 'opposite' internal to POV-Ray 
values be flipped before use.

See attached example scene and image. The image's left side shows 
spheres placed in a vertical column and collected in a union; as well as 
a helix1 based isosurface. On the right both the placement of the 
spheres and the isosurface are perturbed by the pattern modifiers (here 
gentle turbulence and a rotate x*33) both defined with the pigment used 
for both final objects.

Bill P.

Post a reply to this message

Attachments:
Download 'pattern_modifiersstory.pov.txt' (5 KB) Download 'pattern_modifiersstory.png' (69 KB)

Preview of image 'pattern_modifiersstory.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

> What's missing is a way to access the x,y,z vector result of all the
> modifiers a pigment / pattern might employ.

> Then pattern_modifier {} grabs just the result of those
> operations for a given point returning the function/pattern space
> adjusted x,y,z values. The usage is something like:

Yes, this will be very nice indeed.



Just curious:
Being eyeballs-deep in the function code, what do you think the odds are that
there will be functions that can return <x, y, z> vectors for user use, say in
the next year or so?

Post a reply to this message

On 11/1/19 1:53 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> What's missing is a way to access the x,y,z vector result of all the
>> modifiers a pigment / pattern might employ.
> 
>> Then pattern_modifier {} grabs just the result of those
>> operations for a given point returning the function/pattern space
>> adjusted x,y,z values. The usage is something like:
> 
> Yes, this will be very nice indeed. 
> 
> Just curious:
> Being eyeballs-deep in the function code, what do you think the odds are that
> there will be functions that can return <x, y, z> vectors for user use, say in
> the next year or so?
> 

If talking about a branch someone could compile themselves, good. I plan 
to assemble publish such a branch(1).

If talking about in POV-Ray proper, I have no idea. The only person 
actually updating POV-Ray in the past years has been quiet since April 
or so. My pull requests, no matter how trivial, had not been getting 
merged in any form since a minor build related one in November 2017. 
Nothing substantially picked up and merged of mine since early 2017. I 
think that reality unlikely to change no matter core development 
starting up again.

Bill P.

(1) - Thinking that branch will include additional new functions / 
function / pattern updates. I have a list of potential new functions and 
am playing with several not yet posted about now. I'll probably pick up 
Jerome's rotate warp too in some form. Might merge in / refine my 
additional black hole warps as part of this branch too as they are 
really part of the same idea push. I'd like to work out an efficient 
back_hole encapsulated turbulence capability so it can more easily be 
applied locally in a feathered-in-strength way.

I'm likely to hack at the current implementation of the new potential 
pattern too... I find myself not sure how to really make use of the 
potential pattern capability with most shapes. It works well only with 
blobs today(1a). I've thought a fair bit about how to extend the 
potential pattern to other shapes, but I've got no idea how to normalize 
the values in the ray-surface equation values space. These equations 
vary wildly in absolute magnitude and polarity - neither of which matter 
to a first order to the majority of the root solvers. This means the 
potential pattern extended to all inbuilt shapes amounts to implementing 
it as some inside/outside switching - and we already have that 
capability with the object (inside test based) pattern.

(1a) - Our blob has always had continuity issues at the boundaries of an 
individual blob element's influence. Others have suggested updates over 
the years to address this - and down somewhere on my list I want to look 
at it given my solver branch addressed many base accuracy issues with 
the blob shape. The point here, even with blobs where the value domain 
is somewhat normalized, their usefulness as complicated multi-blob 
potential patterns is constrained due the long-standing continuity 
issues with the blob shape itself. I see the blob-potential pattern as 
useful for noisy results with complicated structures - like how blobs 
get used for snow and the like today - but not for real detail. The 
surface continuity necessary just isn't there for the latter use except 
with stand alone blob elements. In other words - except with non-blobbed 
blobs... ;-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> If talking about a branch someone could compile themselves, good. I plan
> to assemble publish such a branch(1).

I think that would be a nice tool to have, for a number of reasons.

1. It simply doesn't make a lot of sense to work on things that no one will be
using.  So publishing it for use allows people to, obviously, use it - but also
their use of the branch advertises it in some way and encourages further use.
(IMHO, POV-Ray proper (PRP) could use more of this [a] )

2. It provides a means of accomplishing something that may be impossible using
the current release, vastly simpler, or just far more accessible to folks with
limited time or just not enough time to concoct a scheme to code a clever
work-around

3. Using such a branch allows people (like me ;) ) to break it and find the
bugs, thus driving its iteratively increasing stability, and providing usage
statistics supporting it suitability for inclusion in PRP.


> (1) - Thinking that branch will include additional new functions /
> function / pattern updates. I have a list of potential new functions and
> am playing with several not yet posted about now. I'll probably pick up
> Jerome's rotate warp too in some form.

IIRC, at least 3 people have expressed explicit interest in the vortex
pattern/function.  [jr, TdG, Yadgar, ...] I don't know what you'd need in order
to roll that in as well.

> I'm likely to hack at the current implementation of the new potential
> pattern too... I find myself not sure how to really make use of the
> potential pattern capability with most shapes. It works well only with
> blobs today(1a). I've thought a fair bit about how to extend the
> potential pattern to other shapes, but I've got no idea how to normalize
> the values in the ray-surface equation values space.

I found it extremely useful to look at what loads of people have done with the
ray-marching technique.  Some very interesting and simple-looking functions to
perform a wide variety of clever operations.  It made me thing about a few
things in completely different ways.


[a]
Grant Sanderson of 3 Blue 1 Brown uses python and "manim" - a math animation
package for use with Adobe AfterEffects to make his excellent videos.

Folks say it's rather hard to use with not much documentation - I'm wondering if
they might begin using POV-Ray if they knew about it and could see what it can
do. (I don't have a YT account)
Perhaps Khan Academy, and certain other channels dealing with math and physics
would be drawn to experimenting with POV-Ray's built-in capabilities for
vectors, isosurfaces, parametrics, polynomials, matrices, arrays, and animation.

https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab

Post a reply to this message