<yaz### [at] gmxde> wrote:

> While playing around with procedurally generated countries' flags, I
> tried to use them in patterns... and to make it simple in the beginning,
> I started with a checker pattern containing the flags of Palau and
> Trinidad and Tobago:

Here are some procedurally-generated flags I was experimenting with a year  
and a half ago.  The first 3 are:
   - U.S. Virgins Islands, where I live;
   - United States of America, my country of citizenship;
   - Maryland, USA, where I was staying when I made these flags.

I didn't make a Trinidad and Tobago; not enough of a challenge, I guess.   
Instead I submit nearby countries Barbados and St. Vincent and the  
Grenadines.  (I have flags languishing of even closer countries, Venezuela  
(which is a good swim from Trinidad) and Grenada, as well as T&T itself.  
However, they are from my pre-POV-Ray days.)

The colors may seem a bit coolish; the monitor I was using at the time was  
damaged and didn't illuminate properly.

-- 
<Insert witty .sig here>

Post a reply to this message

Attachments:
Download 'usvi-flag.png' (22 KB) Download 'usa-flag.png' (11 KB) Download 'maryland-flag.png' (4 KB) Download 'barbados-flag.png' (2 KB) Download 'st_vincent-flag.png' (3 KB)

Preview of image 'usvi-flag.png'

Preview of image 'usa-flag.png'

Preview of image 'maryland-flag.png'

Preview of image 'barbados-flag.png'

Preview of image 'st_vincent-flag.png'

"clipka" <nomail@nomail> wrote:

> In this case, another one would be to use the pattern as a function image (see
> 3.5.11.16) without the "once" keyword ;) (didn't test it, but I guess it should
> tile like any proper image would)

Yes indeed; I use that technique quite a bit.

The only problem with a function image is the really odd 'upside-down mirror
image' behavior of the resulting pattern 'slice' (at least when it's used to
make a HF, anyway.) Try making a function image from an image_map to see what I
mean.  This behavior seems to be intrinsic to using a function with *any*
pattern (although, since POV patterns like bozo and such are
random-looking anyway, it's difficult to see this effect.) Awhile ago, I posted
something about all this, with a fix (and I've since found a slightly simpler
fix, but the posted one will do it)...

http://news.povray.org/povray.advanced-users/thread/%3Cweb.47f304325a8bc21378dcad930%40news.povray.org%3E/

KW

Post a reply to this message

news:49c98018$1@news.povray.org...
> High!
>
> I started with a checker pattern containing the flags of Palau and
> Trinidad and Tobago:
>

Hi Yadgar and CR,

If you code these in a way that's compatible with the 23 already in the 
Object Collection at 
http://lib.povray.org/searchcollection/index2.php?objectName=Flags&contributorTag=chrisb
then we could build a pretty comprehensive set (each is simply defined in 
it's own macro which sets the Flags_Texture identifier using a texture 
scaled to fit a unit square.

It currently contains procedural textures for "Olympic", "UnionJack", 
"UnionFlag1606", "StGeorgesCross", "StAndrewsCross", 
"StPatricksCross","Wales", "Canada", "USA", "Australia", "New Zealand", 
"Ireland", "France", "Belgium", "Italy", "Germany", "Austria", "Luxembourg", 
"Netherlands", "Hungary", "Armenia", "Peru", "Nigeria".

I'd be happy to help put that together if that's something you'd like to do.

Regards,
then Chris B.

Post a reply to this message

Since we're on pbi:

Chris B.

Post a reply to this message

Attachments:
Download 'flags.jpg' (100 KB)

Preview of image 'flags.jpg'

"Kenneth" <kdw### [at] earthlinknet> wrote:
> The only problem with a function image is the really odd 'upside-down mirror
> image' behavior of the resulting pattern 'slice' (at least when it's used to
> make a HF, anyway.) Try making a function image from an image_map to see what I
> mean.

Ah, so *that's* why I found myself in need of a scale <1,1,-1> when I migrated a
particular scene from an auto-generated mesh to an auto-generated-df3-based
height field these days...

I actually have an Idea how this came to be so:

Where's <0,0> in an image?

In a POV context, for some reason I'd be quite quick to claim that it must be
the bottom left corner.

In an image editing context, however, (0;0) classically designates the top left
corner.

So height field code, normally dealing with images, might have to swap around
the image's y co-ordinate for proper operation. And it might do just the same
for function images - but the function images may fail to do a similar
re-normalization for the input pattern.

So the issue may actually be in function images in general, not patterns in
height fields (after all, if I'm not mistaken, function images are the only way
to create a height field from a pattern in the first place).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> > The only problem with a function image is the really odd 'upside-down mirror
> > image' behavior of the resulting pattern 'slice' (at least when it's used to
> > make a HF, anyway.) Try making a function image from an image_map to see
> > what I mean.
>
> Ah, so *that's* why I found myself in need of a scale <1,1,-1> when I
> migrated a particular scene from an auto-generated mesh to an
> auto-generated-df3-based height field these days...
>
> I actually have an Idea how this came to be so:
>
> Where's <0,0> in an image?
>
> In a POV context, for some reason I'd be quite quick to claim that it must be
> the bottom left corner.
>
> In an image editing context, however, (0,0) classically designates the top
> left corner.

YES, you've hit the nail squarely on the head. The x/z 'origin' of an image_map
function in POV_Ray is, strangely enough, at <0,1>, not <0,0>. That took me a
bit of experimenting to find. And your explanation of how it possibly came to
be is the final piece of info that solves the puzzle. Yet *at the moment* I'm
not so sure now that the same thing applies to POV pigments or patterns (see
below.)
>
> So height field code, normally dealing with images, might have to swap around
> the image's y co-ordinate for proper operation. And it might do just the same
> for function images - but the function images may fail to do a similar
> re-normalization for the input pattern.

> So the issue may actually be in function images in general, not patterns in
> height fields...

Since posting my reply, I've gone back for yet *another* round of experimenting
with function images and HFs (this time using the HF_Square macro in
shapes.inc), and I've seen some odd behavior.  Part of that is due to a problem
in that macro itself (which I just found a fix for); but my 'fix'--to reorient
how the macro 'sees' an image_map function--does not seem to operate the same
way on functions made from POV-Ray pigments or patterns. I'm getting
conflicting results, in several different ways, so--whether dealing with this
HF macro or a regular HF-- I'm not so sure now that pigments/patterns and
image_maps are even operating the 'same' way when 'functionalized.' Using the
HEXAGON and RADIAL patterns--which have a definite 'direction' or
orientation--they come out looking *exactly* the way they should when used in
the HF_Square macro--no 'mirror image' stuff to contend with, no altered x/z
origin point. Yet an image_map function there DOES need my fix (as a
similar-but-different 'mirror-image' fix was required in a regular HF.) I need
to go back to a 'regular' HF and see if those two specific patterns show up
correctly there as well.

It's all quite weird, and I continue to experiment. I think I *can* say this: A
regular HF and the HF_Square macro seem to operate differently when presented
with functions. (Not so weird in itself; they probably have different code
paradigms.) But nailing down that difference--and the image_map vs.
pigment/pattern discrepancies--is taking some time and thought.
>
> ...(after all, if I'm not mistaken, function images are the only
> way to create a height field from a pattern in the first place).

Yes, that's the only way I know of too.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> Since posting my reply, I've gone back for yet *another* round of
> experimenting with function images and HFs (this time using the HF_Square
> macro in shapes.inc), and I've seen some odd behavior.  Part of that is due
> to a problem in that macro itself (which I just found a fix for); but my
> 'fix'--to reorient how the macro 'sees' an image_map function--does not seem
> to operate the same way on functions made from POV-Ray pigments or patterns.

After more work, I decided against using that macro fix, as it really wasn't
needed (the problem was better solved outside the macro.) Instead, there seems
to be *something* basically weird, having to do with how functions 'see'
image_maps (as opposed to how they deal with pigments/patterns); I even have
questions now about functions supposedly "evaluating the pattern on the X/Y
plane". Trying to sort it all out is rather complex and mind-numbing--but I'm
getting *closer* to an answer!

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
>...but my 'fix'--to reorient
> how the macro 'sees' an image_map function--does not seem to operate the same
> way on functions made from POV-Ray pigments or patterns. I'm getting
> conflicting results, in several different ways...

I know I'm getting further and further off-topic with this little discussion,
but I just found out something interesting (and definitely weird):

When a function is used in the HF_Square macro in shapes.inc--supposedly the
'equivalent' of POV's regular HF--the function (whether of a pigment/pattern OR
an image_map) actually evaluates the pattern 'slice' on the X/Z plane(!) rather
than the X/Y plane as it is supposed to. That explains lots of things!


OK, enough. :-) I'll continue with this in its own post.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "clipka" <nomail@nomail> wrote:
> > ...(after all, if I'm not mistaken, function images are the only
> > way to create a height field from a pattern in the first place).
>
> Yes, that's the only way I know of too.

Just an aside to your discussion, obviously, but...

What about using a regular pigment function in the height field? Or a pigment
function called at <x,0,z> in an isosurface? (Not strictly a heightfield but
you get the same effect.) Or, of course, you could always write your own
heightfield macro...

As always, plenty of ways to skin a cat... :)

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> After more work, I decided against using that macro fix, as it really wasn't
> needed (the problem was better solved outside the macro.) Instead, there seems
> to be *something* basically weird, having to do with how functions 'see'
> image_maps (as opposed to how they deal with pigments/patterns); I even have
> questions now about functions supposedly "evaluating the pattern on the X/Y
> plane". Trying to sort it all out is rather complex and mind-numbing--but I'm
> getting *closer* to an answer!

Make sure you're not messing up these two in your experiments:

    function { pattern { MyPattern } }
    function 20, 20 { pattern { MyPattern } }

They do totally different things. The former lets you use patterns where POV
would expect a function, by merely providing a wrapper; the latter lets you use
patterns where POV would expect an image, by actually sampling a slice of the
pattern in advance.

The former is officially called a "pattern function"; the latter is called a
"function image" or "internal bitmap"

Post a reply to this message