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

> >> A trick I find useful when working with maps is to hard code a value as
> >> follows using function{} :
> >>
> >> // pigment_pattern {NR_wood_grain}
> >>      function { 0.91 }
> >>      texture_map {...}

Ah, I see this clearly now.   Very clever  :)

Presumably one can do function {Val1, Val2, Val3}

to specify any "x, y, z" coordinate to evaluate the map at.

I'll see what I can work out using that method.

I also had some issues getting the text object to work well as a pigment pattern
- is there a trick for getting a text object with infinite thickness - or would
that not be necessary?

Post a reply to this message

On 04/13/2018 09:03 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>>>> A trick I find useful when working with maps is to hard code a value as
>>>> follows using function{} :
>>>>
>>>> // pigment_pattern {NR_wood_grain}
>>>>       function { 0.91 }
>>>>       texture_map {...}
> 
> Ah, I see this clearly now.   Very clever  :)
> 
> Presumably one can do function {Val1, Val2, Val3}
> 
> to specify any "x, y, z" coordinate to evaluate the map at.
> 
> I'll see what I can work out using that method.
> 
> I also had some issues getting the text object to work well as a pigment pattern
> - is there a trick for getting a text object with infinite thickness - or would
> that not be necessary?
> 
> 
> 
> 

If you want infinite thickness with an object pattern, you can wrap the 
pattern in a function after having centerer the object with thickness 
about some plane in space. Say the x-y plane at z=0. Then call your 
FnWrapObjectPattern as FnWrapObjectPattern(x,y,0.0) making the pattern 
effectively a 2D, infinite in z, x,y pattern.

Bill P.

Post a reply to this message

> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>>>> A trick I find useful when working with maps is to hard code a value as
>>>> follows using function{} :
>>>>
>>>> // pigment_pattern {NR_wood_grain}
>>>>       function { 0.91 }
>>>>       texture_map {...}
> 
> Ah, I see this clearly now.   Very clever  :)
> 
> Presumably one can do function {Val1, Val2, Val3}
> 
> to specify any "x, y, z" coordinate to evaluate the map at.
> 
> I'll see what I can work out using that method.
> 
> I also had some issues getting the text object to work well as a pigment pattern
> - is there a trick for getting a text object with infinite thickness - or would
> that not be necessary?
> 
> 
> 
> 

While Willian method is good, if you don't need it to be infinite but 
having it just be extremely thick, you can give it a large value for the 
thickness, and then scale it very large. If the actual thickness get in 
the 1e6 erange, or more, it will effectively /look/ infinite.

Extreeme thickness sample :
text{ttf Fon_Name, Yourtext, 2e6, 0 translate -1e6*z scale<1,1,1e6>}

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> While Willian method is good, if you don't need it to be infinite but
> having it just be extremely thick, you can give it a large value for the
> thickness, and then scale it very large. If the actual thickness get in
> the 1e6 erange, or more, it will effectively /look/ infinite.
>
> Extreeme thickness sample :
> text{ttf Fon_Name, Yourtext, 2e6, 0 translate -1e6*z scale<1,1,1e6>}


Indeed  :)
I had something like your method in mind,
Extreeeeeeeeeeeeeeme thickness! :D
and of course in hindsight, I should have somehow been able to puzzle out The
Pokorny Method, given all of the breadcrumbs left throughout my raytracing
journey.

I haven't yet had a chance to play with this yet and even see where the
fundamental problem lies - I had to fix an OpenOffice Calc thing first....  :|

Post a reply to this message

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

> and doing this in your scene tells me the problem (two value issue) is
> with the NR_wood_grain pigment though nothing pops out at me...

Well, I finally had some time to sit down and play with this for a while.

The problem seems to actually be in some of the patterns POV-Ray uses.
I'm not sure why that is.

Check this out and see if this is a "bug" (I honestly can't see how it could be
at this stage) or just some weird thing I'd doing, though I can't see what that
is either.

I get the same results in Version 3.7.0.msvc10.win64 and
Version 3.7.1-beta.98+msvc14.win64

Post a reply to this message

Attachments:
Download 'woodlabel.pov.txt' (4 KB)

result:

Post a reply to this message

Attachments:
Download 'woodlabel.png' (534 KB)

Preview of image 'woodlabel.png'

And, despite the fog of fatigue, I managed to work it out bit by bit today.

The issue is that POV-Ray defines a default pigment_map for certain patterns,
and in order to get a normal "full-spectrum" pigment_map, you have to define one
to override the default.

I guess I _thought_ I was doing this when assigning a texture_map, but of
course, that's a texture_map for the pattern, not a pigment_map for the pigment.

The first clue was that WP's function trick was throwing an error.
So I simplified the pigment to just pigment {wood} and I got the same result.

It should have somehow clicked then, but - foggy brain.
So I decided: lemme write my own pigment function for wood.  Which reminded me
that there's an f_wood function.

So I rendered two radius 3 cylinders with:

#declare Wood = texture {
 pigment {function{f_wood(x,y,z)}}
 }

#declare Hyp = function {sqrt(pow(x,2)+pow(y,2))}
#declare Rings = pigment {function {1-(2*abs(mod(Hyp(x,y,0),1)-0.5))}}

#declare Wood2 = texture {
 pigment {Rings}}

and that seemed to go pretty well, and then I added just a plain pigment {wood}
cylinder, and got the characteristic rings - just the TWO default colors.  At
some point, the meaning of the pattern description in the documentation became
clear, and I tried:

pigment {
        wood
 pigment_map {
  [0.00 rgb 0]
  [1.00 rgb 1]
}

Which neatly solved the problem.

{Whew.}

And now, for your enjoyment and edification:

Post a reply to this message

Attachments:
Download 'woodlabel.png' (238 KB)

Preview of image 'woodlabel.png'

On 04/17/2018 06:50 PM, Bald Eagle wrote:
> And, despite the fog of fatigue, I managed to work it out bit by bit today.
> 
> The issue is that POV-Ray defines a default pigment_map for certain patterns,
> and in order to get a normal "full-spectrum" pigment_map, you have to define one
> to override the default.
> 
...
> 
> pigment {
>          wood
>   pigment_map {
>    [0.00 rgb 0]
>    [1.00 rgb 1]
> }
> 
> Which neatly solved the problem.
> 
> {Whew.}
> 
> And now, for your enjoyment and edification:
> 
Thanks for digging through the details here. I was traveling and I'm 
just seeing your recent posts. Could I get a copy of your SDL for the 
'all/most' patterns post prior to this last one? The one with the 
pattern names to the left and the patterns shown to the right.

What you say about POV-Ray often defining a default color/pigment 0-1 
map is true. At the moment I am a little surprised wood's default map 
isn't what you defined. Some patterns, like agate(1), are other than 
above - but why would wood's be?

I'll put this on my to look at list and let it rattle around in my head 
meanwhile.

Bill P.

(1) WAY down my list is another question whether the agate map 
needs/needed a tweak due the 3.7 assumed_gamma default change... I know 
brick's color_map defaults for example did not get adjusted and the 
default colors don't look that good running at an assumed_gamma of 1.0. 
Not many folks use the in-built defaults in practice I suppose, and they 
can always override with their own maps; Excepting maybe agate where to 
my recollection something extra was going on I didn't understand in a 
quick look.

Post a reply to this message

> Thanks for digging through the details here. I was traveling and I'm 
> just seeing your recent posts. Could I get a copy of your SDL for the 
> 'all/most' patterns post prior to this last one? The one with the 
> pattern names to the left and the patterns shown to the right.
> 
> What you say about POV-Ray often defining a default color/pigment 0-1 
> map is true. At the moment I am a little surprised wood's default map 
> isn't what you defined. Some patterns, like agate(1), are other than 
> above - but why would wood's be?
> 

The wood pattern have a default colour map that use "wood" like tones to 
make it slightly more usefull as is.

Post a reply to this message

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

> Thanks for digging through the details here. I was traveling and I'm
> just seeing your recent posts.

No problem - I was wanting to understand what the fundamental problem was, and
was only able to attack it piecemeal in the odd little spurts of free time.

> Could I get a copy of your SDL for the
> 'all/most' patterns post prior to this last one? The one with the
> pattern names to the left and the patterns shown to the right.

I believe that's in the .pov file immediately preceding the image post.

> What you say about POV-Ray often defining a default color/pigment 0-1
> map is true. At the moment I am a little surprised wood's default map
> isn't what you defined. Some patterns, like agate(1), are other than
> above - but why would wood's be?

I think maybe it's just an old hold-over from the earlier versions, where the
basic wood pigment's default mapping was 2 colors.
I'll have to think some on if/how that can be undone and still be prior-version
friendly.

> I'll put this on my to look at list and let it rattle around in my head
> meanwhile.
>
> Bill P.
>
> (1) WAY down my list is another question whether the agate map
> needs/needed a tweak due the 3.7 assumed_gamma default change... I know
> brick's color_map defaults for example did not get adjusted and the
> default colors don't look that good running at an assumed_gamma of 1.0.
> Not many folks use the in-built defaults in practice I suppose, and they
> can always override with their own maps; Excepting maybe agate where to
> my recollection something extra was going on I didn't understand in a
> quick look.

Well, now that you mention it, I actually was thinking a bit about why the wood
pigment map was the way it was, and how that was done, and that led me to
tangentially go a step further from the SDL that I posted to give:

#declare Hyp = function {sqrt(pow(x,2)+pow(y,2))}
#declare Freq = 1;
#declare Gamma = 1;
#declare Rings = pigment {function
{pow(1-((2*Freq)*abs(mod(Hyp(x,y,0),(1/Freq))-(1/(Freq*2))) ), Gamma)} }

So now the "spread" of the pigment map can be changed.

I'd love to be able to read the source code better than I can at the present,
and look more closely at how the pigments and functions are implemented.

I think it would be a nice collection of patterns, perhaps as an include, to
rewrite all of the internal POV-Ray patterns as SDL versions, so that people can
see how they work, better understand how to use them, and have the code right
there for the user to modify, play with, and come up with their own variations.



I'm presently wondering if there's a way to implement a reaction-diffusion type
/ cellular automata pattern using parameters.   That can apparently give leopard
spots, zebra stripes, giraffe crackle-type patterns, and the usual chemical
petri dish looking pattern.

https://people.maths.ox.ac.uk/~maini/PKM%20publications/212.pdf
https://phys.org/news/2015-12-mathematical-animal-stripes.html
https://plus.maths.org/content/how-leopard-got-its-spots



ALSO,
A while back, when I was fixated on working out the Dupin cyclide, I eventually
dug out the source for the internal function, and discovered that it generates
the shape by doing a geometric inversion of a torus!  :O

I think it ought to be possible to write an f_inversion function that others can
be processed by - which would give people a powerful tool to explore different
shapes in away that's vastly more difficult to do at the present.

Post a reply to this message