<---------------------- References. Six previous posts

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

and

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

---
In povr have implemented a new f_repeat() function which is like the 
existing repeat warp in some respects, but mostly implements some 
SDL/TCL functionality I've had in my toolbox for a while as an inbuilt 
function with the significant improvement of embedding the cells like 
pattern mapping so it need not be calculated and maintained apart.

My toolbox has a bunch of other half done stuff too, but thinking to 
pile it all in one function likely to get sluggish, so leaving that for 
probably another version - f_repeatMoreAndSlower() - or something. :-)

Parameters: x, y, z
Thirteen extra parameter required:
1.  If 0, return new x.
     If 1, return new y.
     If 2, return new z.
     If 3, return matched cells pattern value  0 to 1 interval.
     If 4, return matched cells pattern value -1 to 1 interval.
2.  Count in x.
3.  Count in y.
4.  Count in z.
5.  Delta in x.
6.  Delta in y.
7.  Delta in z.

Direction. If 0, count applied +-. If <0, count applied - only. If >0, count
applied + only.

8.  Direction in x.
9.  Direction in y.
10. Direction in z.
11. Cells pattern offset in x.
12. Cells pattern offset in y.
13. Cells pattern offset in z.

Notes. The base function should be centered at zero and small enough to 
fit in the repeated 'cells.'  The counts too are in both directions 
about the particular axis. So a y count of two means two on each side of 
y. The deltas represent the size of each cell in x,y or z. The 
directions are used to prune counts in particular directions. Lastly, 
the cells offset exists, so if you have multiple instances of the 
isosurface you can make them all look different with respect to textures.

#declare R = 0.070;
#declare cntV   = <+4.0,+1.0,+4.0>;
#declare deltaV = <+0.3,+0.3,+0.3>;
#declare dirV   = <+1.0,+1.0,+0.0>;
#declare coffV  = <+9.0,+9.0,+9.0>;
...

#declare Fn00 = function (x,y,z,r,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz) {
     f_sphere(
         f_repeat(x,y,z,0,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         f_repeat(x,y,z,1,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         f_repeat(x,y,z,2,ax,ay,az,bx,by,bz,cx,cy,cz,dz,dy,dz),
         r
     )
}

#declare Iso98 = isosurface {
     function {
         Fn00(x,y,z,R,
             cntx,cnty,cntz,
             dltx,dlty,dltz,
             dirx,diry,dirz,
             coffx,coffy,coffz
         )
     }
...

#declare Pgm00 = pigment {
     function {
         f_repeat(x,y,z,3,
             cntx,cnty,cntz,
             dltx,dlty,dltz,
             dirx,diry,dirz,
             coffx,coffy,coffz
         )
     }
     raw_wave
     color_map { ColorMap00 }
}

Image attached two isosurfaces though could have been one. Using the 
same pigment for both.

Bill P.

Post a reply to this message

Attachments:
Download 'story_f_repeat.png' (494 KB)

Preview of image 'story_f_repeat.png'

Le 2020-05-02 à 11:22, William F Pokorny a écrit :
> <---------------------- References. Six previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5e9cce19%40news.povray.org%3E/

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

> 
> 
> ---
> In povr have implemented a new f_repeat() function which is like the 
> existing repeat warp in some respects, but mostly implements some 
> SDL/TCL functionality I've had in my toolbox for a while as an inbuilt 
> function with the significant improvement of embedding the cells like 
> pattern mapping so it need not be calculated and maintained apart.
> 
> My toolbox has a bunch of other half done stuff too, but thinking to 
> pile it all in one function likely to get sluggish, so leaving that for 
> probably another version - f_repeatMoreAndSlower() - or something. :-)
> 
> Parameters: x, y, z
> Thirteen extra parameter required:
> 1.  If 0, return new x.
>      If 1, return new y.
>      If 2, return new z.
>      If 3, return matched cells pattern value  0 to 1 interval.
>      If 4, return matched cells pattern value -1 to 1 interval.
> 2.  Count in x.
> 3.  Count in y.
> 4.  Count in z.
> 5.  Delta in x.
> 6.  Delta in y.
> 7.  Delta in z.
> 
> Direction. If 0, count applied +-. If <0, count applied - only. If >0, 
> count
> applied + only.
> 
> 8.  Direction in x.
> 9.  Direction in y.
> 10. Direction in z.
> 11. Cells pattern offset in x.
> 12. Cells pattern offset in y.
> 13. Cells pattern offset in z.
> 

Why not use :
2 Count in X, Y, Z as a vector <X, Y, Z>
3 Delta as vector <X, Y, Z>
4, 5, 6 Individual directions. Allow for non-orthogonal patterns.
7 Cell pattern offset vector <X, Y, Z>

The later one may also be split in 3 to allow for more variation.

Post a reply to this message

On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 à 11:22, William F Pokorny a écrit :
...
> 
> Why not use :
> 2 Count in X, Y, Z as a vector <X, Y, Z>
> 3 Delta as vector <X, Y, Z>
> 4, 5, 6 Individual directions. Allow for non-orthogonal patterns.
> 7 Cell pattern offset vector <X, Y, Z>
> 
> The later one may also be split in 3 to allow for more variation.

In use folks would define things with a vector, but you cannot pass 
vectors to functions - even with the v.x like syntax. Which is kinda a 
pain.

This latter behavior is I expect related to noticing recently the parser 
does not fix parameter constants on calls even when everything is known 
to the parser when a function call is defined(1).

It might be the parser is allowing for re-definitions before actually 
rendering given the parser generally allows this. But a guess. I don't 
really know why the interface is set up as it is(2).

Bill P.

(1) In other words it saves render time to do

#declare actualParam2 = ABC+XYZ*2.345;

function { FN00(x,y,z,actualParam2) }

if ABC and XYZ are known, rather than to calculated it on call in the 
parameter position. Doing it this later, more concise, way gets 
calculated on every call (at least where I've noticed and looked).

(2) - Might take a look at the parser interface handling at some point, 
but for now just trying to get a bunch of fixes and functionality in 
place with patterns/functions and the interplay between them. Once 
enough is there I can better test the form for how I think the whole of 
it should work by trying to do more complex isosurfaces. (All, perhaps, 
how things were intended to work given the code architecture in place)

Post a reply to this message

On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 à 11:22, William F Pokorny a écrit :
...
> 
> Why not use :
...

Something else your question has me again thinking about; I'd really 
like to get to where we can pass a set/collection of user defined 
function pointers to inbuilt functions.

Would allow delayed evaluations, but as important, very rapid 
re-evaluations of functions to do whatever larger task. Density 
functions (AKA proximtiy), for example, on functions used in isosurfaces 
or functions acting as stand-ins for equivalent shapes.

On some level these are just double values acting as pointers, but 
letting users (me...) twiddle with such pointer values at all directly 
is asking for boom, crash, bang!

Been thinking about some new, SDL exposed, mechanism which lets users 
register functions / objects by name for later in inbuilt function use. 
A very rough idea at this point.

Perhaps such a mechanism could be extended to vector handling too as a 
way to pass (return?) vectors directly. Large sets of origin and 
direction vectors for use in cameras or whatever???

Thinking about 'bank' as a SDL name for it, but...?

Underneath expect a global C++ map of some sort. un-def/re-def mechanism 
would need to be updated to check whether the existing name is in the 
bank - and fail during parsing if so. We'd want what goes in the bank to 
be a defined once thing even if we perhaps allow value updates.

Yeah, how to handle function parameters not just x,y,z... Don't know, 
and guess I'm thinking aloud and should stop.

Bill P.

Post a reply to this message

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

> Perhaps such a mechanism could be extended to vector handling too as a
> way to pass (return?) vectors directly. Large sets of origin and
> direction vectors for use in cameras or whatever???

I was thinking about this, and we already have the internal pigment patterns
defined by functions.   You input a color_map, and presumably output a color
vector (rgbft?), but then have to choose a dot notation scalar component to pass
the result into another normal function. .r .g. b. f. t. .gray .hf

So maybe most of the mechanism is already lurking in there somewhere.

(It would also be SO much nicer to not need the (x,y,z) for plain-vanilla
functions - have it be optional/assumed.   It would save a lot of screen space
and redundant typing.)

Again, I haven't looked at the code, but if .gray and .hf are computed
internally, presumably without much extra code, then if a function can
"internally" output an rgb vector that can be operated upon to get a scalar
grayscale value, why then can we not say that .temp = .x, .x = .y, .y =. z. and
..z = .temp in order to swizzle on the fly in the compiled code?

Really just curious.  I conceived how to do it in SDL, but at that point I'm
probably using for something that may already be slow...  ;)

Post a reply to this message