|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 12 Mar 2023 12:29:11
Message: <640dfdd7$1@news.povray.org>
|
|
|
| |
| |
|
|
Hi Bill,
In some height_field thread I mentioned image_pattern was a 'different
beast'.
This morning I looked at it again - and you're right - it fits with the
height_field discussion in that it looks like an image_map alternative
which converts a color pixels to grey on the fly. I'll have to play with
the option.
Aside: I found only two uses in the sample stuff shipped with POV-Ray,
One each in the portfolio allnormals.pov and allpatterns.pov code. The
first has:
#declare Image_pattern = normal {
pigment_pattern{image_pattern { png "mtmandj.png" }}
2}
which has me curious as to why both pigment_pattern and image_pattern
are getting used as I think that will run the color to grey conversion
twice. Maybe the image_pattern code creates a smaller internal image
format? Hmm, but then what three channels does pigment_pattern use...
The second allpatterns use is:
#declare Image_pattern = pigment {image_pattern { png "mtmandj.png" }}
which looks useful.
Anyhow. I wonder if I was remembering some functionality other than
image_pattern from 20 years back. There is too material_map, maybe I was
wrongly thinking of that when I first blabbered about image_pattern. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think you're right, and wrong again at the same time.
> In some height_field thread I mentioned image_pattern was a 'different
> beast'.
You did, and now you've provided some more interesting data, but IIRC, you were
bringing that up in a conversation with Kenneth Walker, not me. :D
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 12 Mar 2023 15:52:31
Message: <640e2d7f$1@news.povray.org>
|
|
|
| |
| |
|
|
On 3/12/23 13:43, Bald Eagle wrote:
> I think you're right, and wrong again at the same time.
Ah, usual my state of affairs then... :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I think you're right, and wrong again at the same time.
>
> > In some height_field thread I mentioned image_pattern was a 'different
> > beast'.
>
> You did, and now you've provided some more interesting data, but IIRC, you were
> bringing that up in a conversation with Kenneth Walker, not me. :D
(sorry if this is mistakenly wandering off-topic:)
There is also something in the link below that proved useful to *me* in 2020
(near the end of the thread), about pigment_pattern vs image_pattern, with the
former actually being more 'user-friendly' when coding complex textures. Near
the middle of the thread, IVE mentioned the reason, in response to a question I
had (not about height_fields though.)
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5f73b631268cd3c2d98418910%40news.povray.org%3E/?mtop=43184
8
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 14 Mar 2023 19:11:47
Message: <6410ff33$1@news.povray.org>
|
|
|
| |
| |
|
|
On 3/14/23 04:17, Kenneth wrote:
> There is also something in the link below that proved useful to*me* in 2020
> (near the end of the thread), about pigment_pattern vs image_pattern, with the
> former actually being more 'user-friendly' when coding complex textures. Near
> the middle of the thread, IVE mentioned the reason, in response to a question I
> had (not about height_fields though.)
Thanks for the pointer! I vaguely remember the thread and I gave it a
re-read. I've been playing with image_pattern vs image_map.
It certainly pays to defined a pigment containing either the image_map
or image_pattern once and to thereafter reference that pigment. If your
eventual use is 'grey' via pigment_pattern or a function's .gray I think
the two image inputs are mostly interchangeable. I see little
difference for storage. There looks to be a slight performance advantage
to using image_pattern in the once defined pigment especially with the
function's reference being then .red. The function wrapper itself
slightly slower the pigment_pattern.
FWIW. My test code is at the core roughly:
//---
#declare Pim = pigment { image_map { "as789.png" } }
#declare Pip = pigment { image_pattern { "as789.png" gamma srgb } }
#declare FPim = function { pigment {Pim} }
#declare FPip = function { pigment {Pip} }
#declare P000 = pigment {
// color Red
// image_map { "as789.png" }
// image_pattern { "as789.png" }
// Pim
Pip
//---
// pigment_pattern { Pim }
// pigment_pattern { Pip }
// function { FPim(x,y,z).gray }
// function { FPip(x,y,z).red }
// color_map { [0 red 0] [1 red 1] }
}
//---
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|