POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. New f_repeat(). Server Time13 Sep 2024 13:40:13 EDT (-0400)
 Function / pattern issues. New f_repeat(). (Message 1 to 5 of 5)
 From: William F Pokorny Subject: Function / pattern issues. New f_repeat(). Date: 2 May 2020 11:22:15 Message: <5ead9027@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"headline": "Function \/ pattern issues. New f_repeat().",
"dateCreated": "2020-05-02T15:22:15+00:00",
"datePublished": "2020-05-02T15:22:15+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
<---------------------- References. Six previous posts

and

---
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.
```

Attachments:

Preview of image 'story_f_repeat.png'

 From: Alain Martel Subject: Re: Function / pattern issues. New f_repeat(). Date: 3 May 2020 12:14:43 Message: <5eaeedf3\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5eaeedf3%241%40news.povray.org",
"headline": "Re: Function \/ pattern issues. New f_repeat().",
"dateCreated": "2020-05-03T16:14:43+00:00",
"datePublished": "2020-05-03T16:14:43+00:00",
"author": {
"@type": "Person",
"name": "Alain Martel"
}
}
Le 2020-05-02 à 11:22, William F Pokorny a écrit :
> <---------------------- References. Six previous posts
>
>

>
>
> and
>
>

>
>
> ---
> 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.
```
 From: William F Pokorny Subject: Re: Function / pattern issues. New f_repeat(). Date: 3 May 2020 14:16:45 Message: <5eaf0a8d\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5eaf0a8d%241%40news.povray.org",
"headline": "Re: Function \/ pattern issues. New f_repeat().",
"dateCreated": "2020-05-03T18:16:45+00:00",
"datePublished": "2020-05-03T18:16:45+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
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)
```
 From: William F Pokorny Subject: Re: Function / pattern issues. New f_repeat(). Date: 4 May 2020 03:35:45 Message: <5eafc5d1\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5eafc5d1%241%40news.povray.org",
"headline": "Re: Function \/ pattern issues. New f_repeat().",
"dateCreated": "2020-05-04T07:35:45+00:00",
"datePublished": "2020-05-04T07:35:45+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 à 11:22, William F Pokorny a écrit :
...
>
> Why not use :
...

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.
```
 From: Bald Eagle Subject: Re: Function / pattern issues. New f_repeat(). Date: 4 May 2020 07:05:00 Message:
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"headline": "Re: Function \/ pattern issues. New f_repeat().",
"dateCreated": "2020-05-04T11:05:00+00:00",
"datePublished": "2020-05-04T11:05:00+00:00",
"author": {
"@type": "Person",
"name": "Bald Eagle"
}
}
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???

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...  ;)
```