So, I'm mixing the chipboard, Bill P's advice on warp repeat, and a Sam Benge
post to do a little thing I've wanted to do for a while now - mapping out the
values that crackle uses so you can see it in the rendered pattern.

I still have to code up the text pattern so the text face is visible along the x
and y axes as well, but the solution struck me, and I got it coded pretty quick
after a few false starts.  (Thank goodness POV-Ray has a long undo memory)

Post a reply to this message

Attachments:
Download 'cracklelabel.png' (165 KB)

Preview of image 'cracklelabel.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I still have to code up the text pattern so the text face is visible along the x
> and y axes as well, but the solution struck me, and I got it coded pretty quick
> after a few false starts.

Hope this is a bit better after some further insights and fixing some errors.

Post a reply to this message

Attachments:
Download '3dtextpattern.png' (517 KB)

Preview of image '3dtextpattern.png'

An extension of this little project, which is something that Sven and others
might find useful, is numerically mapping a wood texture, so that you can see
which map entry it is you want to modify.

But, I need a little help here.

I've had to edit the code from the crackle experiment to even get the full
texture map to show up, to get rid of the "suspicious expression after rgb"
warning, and then get the numbers to show up, and now for whatever reason I can
only get two map entries to display.

AND, I can't seem to get the normal and finish blocks to play well in the
texture definition.

I have always had some difficulty understanding the structure and syntax of the
texture definition, so perhaps someone with vastly more experience and skill can
explain where things are going wrong, and give me a better framework for
understanding how to properly construct and assemble the subsections so that
they play well together.

Post a reply to this message

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

On 12-4-2018 0:58, Bald Eagle wrote:
> An extension of this little project, which is something that Sven and others
> might find useful, is numerically mapping a wood texture, so that you can see
> which map entry it is you want to modify.
> 
> But, I need a little help here.
> 
> I've had to edit the code from the crackle experiment to even get the full
> texture map to show up, to get rid of the "suspicious expression after rgb"
> warning, and then get the numbers to show up, and now for whatever reason I can
> only get two map entries to display.
> 
> AND, I can't seem to get the normal and finish blocks to play well in the
> texture definition.
> 
> I have always had some difficulty understanding the structure and syntax of the
> texture definition, so perhaps someone with vastly more experience and skill can
> explain where things are going wrong, and give me a better framework for
> understanding how to properly construct and assemble the subsections so that
> they play well together.
> 

It would seem to me at first view, that the finish and normal blocks 
cannot be used in the wrapping texture, because there  a texture_map is 
used. So, they should be defined somehow within the textures used in the 
texture_map instead. I have not yet found out /how/, within the context 
of the array though, but this will give you an indication.

-- 
Thomas

Post a reply to this message

On 04/11/2018 06:58 PM, Bald Eagle wrote:
....now for whatever reason I can
> only get two map entries to display.
> 
> AND, I can't seem to get the normal and finish blocks to play well in the
> texture definition.
> 
> 

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 {...}

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

You can use differing normals and finishes in your texture_map, but you 
have to have added those to the original texture definitions as Thomas 
suggested or make your texture_map entries each something like:

[0.9 pigment {} normal {} finish {}]

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 {...}

I'm not quite following what you're doing with the function{} here.

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

I did have a bit of trouble getting the NR_wood_grain to work as a pigment
pattern, but now I'm in a weird intermediate limbo-state where it SORT OF
works...   :|

> You can use differing normals and finishes in your texture_map, but you
> have to have added those to the original texture definitions as Thomas
> suggested or make your texture_map entries each something like:
>
> [0.9 pigment {} normal {} finish {}]

Yes, that makes sense - I had sort of suspected something like that when I got
the "can't do that with a layered texture" message.   Thanks for clearly
confirming.

Post a reply to this message

On 04/12/2018 01:05 PM, 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 {...}
> 
> I'm not quite following what you're doing with the function{} here.
> 
> 

It's a debug aid. Normally a <whatever>_map responds to a pattern or 
function generating a 0 to 1 value based upon the x,y,z position of a 
point.

When something is amiss, it's sometimes hard to know whether the issue 
is the construction of the map or if the pattern/function generating the 
0 - 1 values is incorrect.

Coding 'function { 0.91 }' fixes the value the *_map uses at 0.91 no 
matter the x,y,z position of the point. It is a way to verify the *_map 
gives you exactly what you expect for color, pigment, texture or density 
for any given value. If you wanted to see what the interpolated texture 
at 0.25 looks like between 0.2 and 0.3 texture entries in a texture_map, 
you'd code 'function { 0.25 }' and render to see.

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?

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